Feature #14260
Updated by Peter Amstutz over 5 years ago
When creating a container request, a client can specify an API token to be used in a container. When running a container on a cluster other than the requesting user's home cluster, this allows the container to read collections on other clusters. runtime_token: * if provided, must be a valid v2 API token * is not provided in API responses (similar to secret_mounts) * can be retrieved by the dispatcher that has the lock using the @/arvados/v1/containers/$uuid/auth@ API (as usual) * can be set to a valid token when creating a container request * is validated by the API server before creating the container request * -is is provided instead of a real api_client_authorization record by @.../$uuid/auth@ endpoint- endpoint * -causes causes Container#assign_auth to be a no-op- * provide the cached remote token from @.../$uuid/auth@ endpoint * Container#assign_auth assigns the cached remote token no-op * is ignored when considering containers for reuse * is scrubbed when the container is final The given token's user_uuid and scopes are stored in two additional new container fields, @runtime_user_uuid@ (string) and @runtime_auth_scopes@ (jsonb). These *are* considered significant in container reuse decisions. If runtime_token is not provided: * user_uuid and scopes (["all"]) are stored in the container record * existing containers qualify for reuse if their user_uuid and scopes are equal, *or* both are null *Not included here:* To preserve the current level of locking safety (avoiding having two containers fighting over container record state after a slurm/network failure causes a container to be requeued), the auth token needs to change each time the container changes from Queued to Locked state. This should be done (e.g., by adding a field to the token that doesn't change its validity, and checking for equality when updating lock-protected container fields), but will not be addressed in the present issue.