Story #10511

[Crunch2] [API] Specify which user's credentials should be used by a container

Added by Peter Amstutz about 2 years ago. Updated 6 months ago.

Status:
New
Priority:
Normal
Assigned To:
-
Category:
API
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Story points:
-

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.

Related issues

Related to Arvados - Bug #13168: [API] state/priority-change triggers should not change container request modified_by_user_uuid to rootResolved2018-03-29

History

#1 Updated by Tom Clegg about 2 years ago

  • 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

#2 Updated by Peter Amstutz about 2 years ago

  • Description updated (diff)

#3 Updated by Peter Amstutz about 2 years ago

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.

#4 Updated by Tom Morris over 1 year ago

  • Target version set to Arvados Future Sprints

#5 Updated by Peter Amstutz 10 months ago

  • Target version changed from Arvados Future Sprints to To Be Groomed

#6 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)
  • Target version changed from To Be Groomed to Arvados Future Sprints

#7 Updated by Peter Amstutz 10 months ago

  • Target version changed from Arvados Future Sprints to To Be Groomed

#8 Updated by Peter Amstutz 10 months ago

  • 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)

#9 Updated by Peter Amstutz 10 months ago

  • Description updated (diff)

#10 Updated by Tom Clegg 9 months ago

  • Related to Bug #13168: [API] state/priority-change triggers should not change container request modified_by_user_uuid to root added

#11 Updated by Tom Clegg 9 months ago

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.

#12 Updated by Peter Amstutz 9 months ago

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.)

#13 Updated by Tom Clegg 9 months ago

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.

#14 Updated by Tom Clegg 9 months ago

  • 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

#15 Updated by Tom Morris 6 months ago

  • Target version changed from To Be Groomed to Arvados Future Sprints

Also available in: Atom PDF