Always read mnemonic from env to allow automation (e.g.: Cloud Native)

[emanuelconunaemme]

Motivation

We want to scale and automate the deployments of nodes, miners and validators. This will require removing all the user prompts in favor of reading the input from the environment.

Have you read the Contributing Guidelines on pull requests?

Yes

Test Plan

Tested running tower, ol and onboarding with and without MNEM set. Verified that:

• If the var is not set there is no change in the behavior
• If the var is set all the commands work as if the mnemonic was manually entered

Related PRs

(If this PR adds or changes functionality, please take some time to update or suggest changes to the docs at https://developers.diem.com, and link to your PR here.)

If targeting a release branch, please fill the below out as well

• Justification and breaking nature (who does it affect? validators, full nodes, tooling, operators, AOS, etc.)
• Comprehensive test results that demonstrate the fix working and not breaking existing workflows.
• Why we must have it for V1 launch.
• What workarounds and alternative we have if we do not push the PR.

[CLAassistant]

All committers have signed the CLA.

[0o-de-lally]

Hi there thanks for the work on this.
We see mnemonics in the ENV as a very dangerous anti-pattern. There are several ways which you can pass this information into the 0L tools. We are not going to recommend this. Happy to look at other ideas for automation.

[emanuelconunaemme]

@0o-de-lally I don't think it's an anti-pattern. This is how most cloud solutions do it. Security comes from how you save those (e.g.: encrypted k8s secrets with tight rbac policies). Although, I understand the concern.

QUESTIONS:

1. What are the other ways to do it with 0L tools? Would it be possible to reach High Availability and run towers/validators in automation without needing to type the mnemonic?
2. Another problem is that the mnemonic is the key to the "operator" and to the "wallet". Correct me if I'm wrong. This could be a problem cause, even keeping it as it is, it won't allow you to just save the key and store it offline. Wouldn't it be possible to adopt an hybrid approach? E.g.: Cartesi, where you have a "runner" (like the miner) and the "owner" that hires it. The "owner" needs the keys only to access the funds or to hire a "runner". In this way those can be offline. If you leak the miner key, the attacker will have access to the miner, but not to the funds. And the owner will be able to fire the runner and run another one with a new mnemonic.

[0o-de-lally]

Validators have separate keys for Operators and Owners. And Operators can send tower transactions.

Fullnodes will have to enter the mnemonic in tts. There's no plan to have automation for towers which are not being run for validators.

[drawks]

I'm gonna jump in and agree that the intent of this PR is good and passing secrets via env variable is not an anti-pattern any more than having the private key in live memory. Both provide the same level of controls around access to the key material.

Most modern tooling allows for multiple access methods for passing necessary secrets, see for example hashicorp vault which has methods for passing even the highest value keys via environment variable, file on disk, interactive session, cmdline flag, or piped to stdin.

[bogdan-alexandrescu]

I agree as well with Emanuel's proposal and @drawks comment above. I believe we need a more modern way to support passing secrets to miners in order to support automatic recovery and increased operational reliability. Supporting secrets via environment variables, using hashicorp vaults or other secret management solutions like AWS secrets should be supported if we are planning to provide a modern stack. One can also justify that this is not less safe than passing mnemonics via tty in interactive mode. It might actually be more secure as typing credentials in a terminal is more error prone and a lot harder to audit from a security stand point than managed secrets for example.

[0o-de-lally]

defer to @zmanian and @dboreham

[nourspace]

I agree with most of the comments above. I still see a need to allow passing secrets as env vars. As even with database containers for example, on can pass root password as env var.
While it is possible for validators to use their operator accounts, I believe miners could also utilise this feature to run their tower instances inside docker/k8s where they have a way to pass the mnemonic phrase.

[gdoteof]

+1 there needs to be a better option than tts. whether passed in by env or stdin it really makes no difference; the vector of attack is the storage of the secret. i understand that disallowing reading from env discourages some true anti-patterns like, writing a secret to a local file and then using that file to build the env.

however a separate process that, with credentials, reads from a secret service (extremely common pattern) and then passes via env (or simulates tts input which is possible but obnoxious) is about as good as we can get.

an acceptable compromise might be to allow config to read the secret from one of the common places they might be? (e.g. aws secret manager, etcd, google kms, hashicorp vault)

[emanuelconunaemme]

That would be ideal @gdoteof, but EVN variables are the standard cause they are platform independent and will move the security concerns on how you feed those secrets. If you are smart enough to need automation you should be smart enough to secure those secrets. If you don't know how to secure them, probably you don't need it and would be ok typing them at every restart.

Also, do we think people who type them have them on paper and manually insert them all the time? Or do we think those folks store them unsafely and copy/paste them?

[emanuelconunaemme]

Friendly ping to @zmanian and @dboreham to give us a feedback.