Container secret mounts » History » Revision 2
Revision 1 (Tom Clegg, 02/27/2018 08:17 PM) → Revision 2/11 (Tom Clegg, 03/01/2018 02:41 PM)
h1. Container secret mounts This is a proposed modification to [[Containers API]]. Add a "secret_mounts" serialized field to containers and container requests. "secret_mounts" has the same form and behavior as "mounts", (?) behave just like mounts, except: * Only literal content is allowed (kind=text or kind=json) (text, json) * Current value Value of secret_mounts is never returned in a container request or container API response * Current value can be retrieved from response, except a new "containers#secrets" API (@/arvados/v1/containers/$uuid/secret_mounts@) which must be authenticated by the container's own runtime token * Never appears in container logs * Never appears in the Arvados logs table * Never appears in websocket updates * Never appears in API server request logs It is an error for the same key (mount path) to appear in both mounts and secret_mounts. It should not be possible to _commit_ a container request with this error condition, although it might be possible to _save._ A secret_mounts key (path) cannot be * equal to the container's output path, * a descendant of the container's output path, or * an ancestor of the container's output path (currently, this is a moot point because secret mounts are not directories) For clarity, some ways in which secret_mounts behaves like mounts are: * Non-identical secret_mounts disqualifies a container for reuse. The mere existence of secret_mounts does not disqualify. * secret_mounts can be set via container_requests#create and container_requests#update APIs * secret_mounts cannot be null, but can be an empty hash * keys of secret_mounts are paths in the container's filesystem, and always begin with "/"