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

If a secret_mount target is below output_path in the filesystem, it is omitted from the output collection (but this is not an error).

It is an error to use the same mount target in a container request's mounts and secret_mounts.

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

"secret_mounts" api response:

{
  "secret_mounts": {
    "/secrets/foo": {
      "kind": "text",
      "content": "foobar\n" 
    }
  },
  "_response_time_or_other_api_metadata": "..." 
}

Secret environment¶

Add a "secret_environment" serialized field to containers and container requests.

"secret_environment" has the same form and behavior as "environment", except:

• 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_environment) which must be authenticated by the container's own runtime token
  

  {
    "secret_environment": {
      "ACCESS_KEY": "1234" 
     },
    "_response_time_or_other_api_metadata": "..." 
  }

• 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 to use the same environment variable in a container request's environment and secret_environment.

For clarity, some ways in which secret_environment behaves like environment are:

• Non-identical secret_environment disqualifies a container for reuse. The mere existence of secret_environment does not disqualify.
• secret_environment can be set via container_requests#create and container_requests#update APIs
• secret_environment cannot be null, but can be an empty hash
• keys of secret_environment are names of environment variables

There is no support for secret command line arguments.

Documentation note: Anyone who can modify a container request can access its secrets by changing the command, docker image, etc., and committing it. So be careful.