Make credentials available as cheetah variables?

[bernt-matthias]

Unfortunately credentials are not available as cheetah variables!

Originally posted by @RZ9082 in galaxyproject/tools-iuc#7605 (comment)

[jmchilton]

We very explicitly don't do that because we don't want it to end up in CLIs (so people don't see it when they run "ps" on a shared system) and so it doesn't end up in the command line Galaxy saves for the job. I think the linked wrapper really should find another way to inject this directly from the environment variable - probably a wrapper script?

[nsoranzo]

Agreed, this is by design.

[bernt-matthias]

Actually I would like to have credentials in cheetah variables in order to avoid to use them in the CLI. For tools that take credentials in files, config files would be the best solution.

Otherwise workarounds like this one will be used galaxyproject/tools-iuc#7606 (a python script that writes the env variables to a file). This could be solved much more elegant with cheetah variables.

Having credentials in a file should also be perfectly fine, since we have the credentials exposed in a file anyway: they are included in the job script as export statement....

Also the argument has a flaw; using \$env_var as well as $cheetah_var will both expose the credentials in the process list. The only solution is to document how this must /must not be used and alert admins that check tools (maybe admins should actively need to put tools on an allow list).

I hope it's fine to reopen.

[mvdbeek]

will both expose the credentials in the process list.

yes, that is true but if it appears in the command line it will be stored in the job metadata. you could change the scope of injected variables for config files potentially, but ...

we have the credentials exposed in a file anyway

that is the implementation today, but you could implement transfering the secret at runtime without changing anything about the tool language. that is not the case if we unconditionally inject secrets in cheetah.

[bernt-matthias]

it will be stored in the job metadata

that's a good point. thanks for the clarification. would it be possible to hide the credentials in the metadata (by x-ing it out), like we do with admin-credentials in the logs?

you could change the scope of injected variables for config files potentially, but ...

could you give me a hint where this is done. I may have a look.

I think many tools actually accept credentials in files (e.g. the aws example that we use in the xsd-docs which seems outdated or made up).

I will propose a few changes in the xsd docs to increase awareness.

[bernt-matthias]

I'm happy with #21654 for now :)