Project

General

Profile

Actions

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.

Status:
Resolved
Priority:
Normal
Assigned To:
-
Category:
API
Target version:
-
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 rootResolvedLucas Di Pentima03/29/2018Actions
Actions #1

Updated by Tom Clegg over 7 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
Actions #2

Updated by Peter Amstutz over 7 years ago

  • Description updated (diff)
Actions #3

Updated by Peter Amstutz over 7 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.

Actions #4

Updated by Tom Morris over 6 years ago

  • Target version set to Arvados Future Sprints
Actions #5

Updated by Peter Amstutz about 6 years ago

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

Updated by Peter Amstutz about 6 years ago

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

Updated by Peter Amstutz about 6 years ago

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

Updated by Peter Amstutz about 6 years 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)
Actions #9

Updated by Peter Amstutz about 6 years ago

  • Description updated (diff)
Actions #10

Updated by Tom Clegg about 6 years ago

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

Updated by Tom Clegg about 6 years 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.

Actions #12

Updated by Peter Amstutz about 6 years 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.)

Actions #13

Updated by Tom Clegg about 6 years 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.

Actions #14

Updated by Tom Clegg about 6 years 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
Actions #15

Updated by Tom Morris almost 6 years ago

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

Updated by Peter Amstutz over 4 years ago

  • Status changed from New to Resolved
Actions #17

Updated by Ward Vandewege over 3 years ago

  • Target version deleted (Arvados Future Sprints)
Actions

Also available in: Atom PDF