Project

General

Profile

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. 

Back