Idea #10511
closed
[Crunch2] [API] Specify which user's credentials should be used by a container
Added by Peter Amstutz over 7 years ago.
Updated over 3 years ago.
Description
Currently, the user permission for the container created to satisfy a container request is determined by modified_by_uuid. If a user submits a container request, which is then touched by an admin user, the container may run as admin and not the intended user. In addition, this complicates auditing, if modified_by_uuid is changed for any other reason, we lose a record of who submitted the container.
In addition, it is difficult to determine what user was used to run the underlying container records. This information technically exists by following auth_uuid to the token record, and then getting the user associated with the token, however this information is not available to non-admin users, and expired tokens may be deleted at any time by the system.
- Introduce a
created_by_uuid field to the container request that is set when the record is created and used to determine what user to run the container as.
- Introduce a
user_uuid field to the container that records the user uuid that the container ran as.
- Subject changed from [Crunch2] Add run_as_user_uuid to container request to [Crunch2] [API] Add run_as_user_uuid to container request
- Description updated (diff)
- Category set to API
- Description updated (diff)
Being able to have a different "run as" user but produce output in a shared project will be useful for federated computing where you may wish to run a job on data you can't directly access.
- Target version set to Arvados Future Sprints
- Target version changed from Arvados Future Sprints to To Be Groomed
- Description updated (diff)
- Target version changed from To Be Groomed to Arvados Future Sprints
- Target version changed from Arvados Future Sprints to To Be Groomed
- Subject changed from [Crunch2] [API] Add run_as_user_uuid to container request to [Crunch2] [API] Better record of who submitted & ran containers
- Description updated (diff)
- Release deleted (
11)
- Description updated (diff)
- Related to Bug #13168: [API] state/priority-change triggers should not change container request modified_by_user_uuid to root added
It might be useful to elaborate on why/when it's important to know who ran the container.
A container with API access enabled can list, create, and modify arbitrary Arvados objects, which means results and side effects depend on which user's permissions are in effect. But in this case, a more appropriate solution might be to set the acting user UUID explicitly as a runtime constraint. This would enable a few things:
- The acting user would be explicit in both the container request and the container
- We wouldn't reuse containers that ran with totally different permissions than a new container would use
- A user with sufficient permissions could request containers that run with another user's permissions (this could be a useful "service account" pattern)
A container without API access should produce the same result regardless of which user's permissions were in effect at the time, so it's less clear where/when this information would be desired.
Tom Clegg wrote:
It might be useful to elaborate on why/when it's important to know who ran the container.
A container with API access enabled can list, create, and modify arbitrary Arvados objects, which means results and side effects depend on which user's permissions are in effect. But in this case, a more appropriate solution might be to set the acting user UUID explicitly as a runtime constraint. This would enable a few things:
- The acting user would be explicit in both the container request and the container
- We wouldn't reuse containers that ran with totally different permissions than a new container would use
- A user with sufficient permissions could request containers that run with another user's permissions (this could be a useful "service account" pattern)
A container without API access should produce the same result regardless of which user's permissions were in effect at the time, so it's less clear where/when this information would be desired.
The original title of this ticket was "[Crunch2] [API] Add run_as_user_uuid to container request" so I think that is a fine solution. (with the one nitpick that it should be its own column and not part of runtime constraints.)
Peter Amstutz wrote:
The original title of this ticket was "[Crunch2] [API] Add run_as_user_uuid to container request" so I think that is a fine solution. (with the one nitpick that it should be its own column and not part of runtime constraints.)
Is there a use case for "determine which user ran the container" when the submitter did not specify a user (implying that API access is not enabled in runtime constraints)?
When API access is not enabled, it seems to me that a container should be able to satisfy two different (non-admin) users' container requests. But in such cases, in principle, "who ran the container?" is not a thing: if the system were to invent a new user for the duration of the container, the effect should be exactly the same. Does this sound right?
In that case, I suppose "run_as_user_uuid" would be null.
- Subject changed from [Crunch2] [API] Better record of who submitted & ran containers to [Crunch2] [API] Specify which user's credentials should be used by a container
- Target version changed from To Be Groomed to Arvados Future Sprints
- Status changed from New to Resolved
- Target version deleted (
Arvados Future Sprints)
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by Tom Morris 
Updated by