Credentials exposed in environment variables and command-line arguments

[dholbach]

Brought up by Ada Logics

Flux-CLI uses credentials to bootstrap many commands. These are often placed in the
command line or environment variables. This means the credentials are exposed to a wider
audience than intended, namely any internal attacker with a host position if they have
sufficient position to see command line arguments (such as via ps).
For example, if someone has access to the host at which the command line was entered but
not the access to the token of a given Github, then the details can be leaked.

Make it possible to write sensitive data in way that it won't be exposed, such as: ***** or not
showing any characters when being typed.

[makkes]

This has been discussed among the team and there's agreement that this is not an issue particular to Flux nor something that couldn't be addressed by security-conscious users:

• kubectl --token does the same
• Terraform consumes tokens from the environment
• securing the local machine against bad actors that can dump a user's environment is not a Flux concern
• as for args where Flux asks for sensitive information, people can do --token=$(cat my-token.txt)
• there is already protection in the shell against this, if users understand what their shell is doing. Only exported variables are available to programs that are executed in the shell. If you don't want further programs to gain access to exported variables, you can either unset them or close the shell...

However, one workflow that could be improved is to prompt the user for a token if it cannot be retrieved from the environment. This is what Terraform does.

[johngmyers]

• securing the local machine against bad actors that can dump a user's environment is not a Flux concern

Providing a mechanism to provide credentials without leaking them is a Flux concern.

• as for args where Flux asks for sensitive information, people can do --token=$(cat my-token.txt)

That does not help against ps (or reading directly from /proc/PID/cmdline)

• there is already protection in the shell against this, if users understand what their shell is doing. Only exported variables are available to programs that are executed in the shell. If you don't want further programs to gain access to exported variables, you can either unset them or close the shell...

That does not help against ps (or reading direclty from /proc/PID/environ)

[makkes]

• securing the local machine against bad actors that can dump a user's environment is not a Flux concern

Providing a mechanism to provide credentials without leaking them is a Flux concern.

How far would you believe a tool consuming credentials should go trying to not leak them? I'd be interested to understand how tools like kubectl do it (e.g. when creating Secrets using kubectl create secret generic --from-literal.

• as for args where Flux asks for sensitive information, people can do --token=$(cat my-token.txt)

That does not help against ps (or reading directly from /proc/PID/cmdline)

Probably not. But shouldn't hiding other user's processes be taken care of by the OS?

[makkes]

@johngmyers there's one more thing that might've sneaked by your attention: We're working on providing an interactive prompt for tokens as part of #2038

[johngmyers]

How far would you believe a tool consuming credentials should go trying to not leak them? I'd be interested to understand how tools like kubectl do it (e.g. when creating Secrets using kubectl create secret generic --from-literal.

Such a tool should permit a way to pass the credentials other than through the environment and/or argv. For example, by providing a way to pass the credentials through a file, such as kubectl create -f.

And any manifest referencing such a tool should pass credentials using such other mechanisms. (I have not found any such problems in Flux.)

Probably not. But shouldn't hiding other user's processes be taken care of by the OS?

Perhaps theoretically, but Linux doesn't do such hiding by default. Projects supporting Linux need to deal with Linux shortcomings.

We're working on providing an interactive prompt for tokens as part of #2038

This is good for interactive use, but not for things that are used in automation. On the other hand, it seems that flux bootstrap is not suitable for production automation for other reasons.

[makkes]

This is good for interactive use, but not for things that are used in automation

@johngmyers I beg to differ as this new way of providing a token allows you to pass it in from stdin so you can e.g. tunnel the token through SSH without it being exposed anywhere on the receiving end.