Project

General

Profile

Container secret mounts » History » Revision 3

Revision 2 (Tom Clegg, 03/01/2018 02:41 PM) → Revision 3/11 (Peter Amstutz, 03/01/2018 03:50 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", except: 
 * Only literal content is allowed (kind=text or kind=json) 
 * Current value is never returned in a container request or container API response 
 * Current value can be retrieved from a new 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) 

 (PA) I would modify this restriction.    Secret file mounts should be allowed to appear under the output directory, but must be _excluded_ when capturing output.    The reasoning is that this aligns better with the CWL InitialWorkDir feature which pre-populates the output directory.    Pre-populating other directories is technically legal but less portable. 

 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 "/"