Bug #15814
Updated by Peter Amstutz over 2 years ago
In the container.json log of e51c5-xvhdp-ctxc9vlsbq7ae3x you can see: <pre> "api_key_per_sample": { "$include": "/secrets/s0" } </pre> In the container.json log of e51c5-xvhdp-mkzv6lz6mnphv7b, you can see the api_key_per_sample in plaintext. For reference, the h2. Implementation The way secrets are handled in arvados-cwl-runner: # the submitter process takes the secret string and adds a "text" type mount at /secrets/s0 (s1, s2, etc) to the container request # In the input object, the parameter is replaced with "$include": "/secrets/s0" # 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 # The workflow runner internally swaps the secret for a placeholder to avoid printing it in logging (including debug logging) # The command line tool uses InitialWorkDir to define the credential files # It observes that the file contains the placeholder for the secret # The file is moved to secret_mounts and the placeholder is replaced by the real secret # 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 h2. Implementation The part that workbench 2 needs to handle is: # Recognizing which inputs are secrets (requires looking for cwltool:Secrets in the workflow's hints or requirements sections). # Obscuring the secret with a "password" type text box # When constructing the container request, moving secrets into the "secret_mounts" part, and replacing them in the input object with the $include reference.