Container secret mounts » History » Version 4
Peter Amstutz, 03/01/2018 03:57 PM
| 1 | 1 | Tom Clegg | h1. Container secret mounts |
|---|---|---|---|
| 2 | |||
| 3 | 2 | Tom Clegg | This is a proposed modification to [[Containers API]]. |
| 4 | |||
| 5 | Add a "secret_mounts" serialized field to containers and container requests. |
||
| 6 | |||
| 7 | "secret_mounts" has the same form and behavior as "mounts", except: |
||
| 8 | * Only literal content is allowed (kind=text or kind=json) |
||
| 9 | * Current value is never returned in a container request or container API response |
||
| 10 | * 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 |
||
| 11 | 1 | Tom Clegg | * Never appears in container logs |
| 12 | * Never appears in the Arvados logs table |
||
| 13 | * Never appears in websocket updates |
||
| 14 | * Never appears in API server request logs |
||
| 15 | |||
| 16 | 2 | Tom Clegg | 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._ |
| 17 | |||
| 18 | A secret_mounts key (path) cannot be |
||
| 19 | * equal to the container's output path, |
||
| 20 | * a descendant of the container's output path, or |
||
| 21 | * an ancestor of the container's output path (currently, this is a moot point because secret mounts are not directories) |
||
| 22 | |||
| 23 | 4 | Peter Amstutz | (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 (only works if you are using containers, which is an ok assumption for Arvados but not for CWL generally). |
| 24 | 3 | Peter Amstutz | |
| 25 | 2 | Tom Clegg | For clarity, some ways in which secret_mounts behaves like mounts are: |
| 26 | * Non-identical secret_mounts disqualifies a container for reuse. The mere existence of secret_mounts does not disqualify. |
||
| 27 | * secret_mounts can be set via container_requests#create and container_requests#update APIs |
||
| 28 | * secret_mounts cannot be null, but can be an empty hash |
||
| 29 | * keys of secret_mounts are paths in the container's filesystem, and always begin with "/" |