Arvados

In the container.json log of e51c5-xvhdp-ctxc9vlsbq7ae3x you can see:

                "api_key_per_sample": {
                    "$include": "/secrets/s0" 
                }

In the container.json log of e51c5-xvhdp-mkzv6lz6mnphv7b, you can see the api_key_per_sample in plaintext.

For reference, the way secrets are handled in arvados-cwl-runner:

1. the submitter process takes the secret string and adds a "text" type mount at /secrets/s0 (s1, s2, etc) to the container request
2. In the input object, the parameter is replaced with "$include": "/secrets/s0"
3. The workflow runner process (inside the container) loads the input object and processes the $input directive, which reads /secrets/s0 and replaces it with the contents of the file
4. The workflow runner internally swaps the secret for a placeholder to avoid printing it in logging (including debug logging)
5. The command line tool uses InitialWorkDir to define the credential files
6. It observes that the file contains the placeholder for the secret
7. The file is moved to secret_mounts and the placeholder is replaced by the real secret
8. secret_mounts are hidden from all API responses except when crunch-run requests the "self" container. Secrets are wiped from the database when the container is finished

Implementation¶

The part that workbench 2 needs to handle is:

1. Recognizing which inputs are secrets (requires looking for cwltool:Secrets in the workflow's hints or requirements sections).
2. Obscuring the secret with a "password" type text box
3. When constructing the container request, moving secrets into the "secret_mounts" part, and replacing them in the input object with the $include reference.