Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: What tools should I use to manage secrets from env files?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 83 posts

Re: Ask HN: What tools should I use to manage secrets from env files?

#71

Post by withinboredom »

I would suggest NOT using env files. They are a hack. The environment belongs in the environment, not a file on disk; and if it is on a file on the disk, it belongs outside your repository.

There is a script in the repository that will bootstrap your local env by storing encrypted secrets into ~/.config/ by asking some questions that you get from the shared passwords manager for development credentials. The key to decrypt them is password protected and requested at application boot.

Re: Ask HN: What tools should I use to manage secrets from env files?

#72

Post by natch »

Refalm wrote: post #67
starwatch wrote: post #52

Earlier quoted context omitted.

True on all counts. I never got the GPG approach working - though admittedly I didn't put too much effort into figuring it out.

Implementation is easy. Getting people to understand GPG is another thing entirely.

Because they have trouble wrapping their head around public / private keys? Or something else?

Re: Ask HN: What tools should I use to manage secrets from env files?

#73

Post by nbbaier »

withinboredom wrote: post #71

I would suggest NOT using env files. They are a hack. The environment belongs in the environment, not a file on disk; and if it is on a file on the disk, it belongs outside your repository. There is a script in the repository that will bootstrap your local env by storing encrypted secrets into ~/.config/ by asking some questions that you get from the shared passwords manager for development credentials. The key to de…

Do you have an example of such a script?

Re: Ask HN: What tools should I use to manage secrets from env files?

#74

Post by withinboredom »

nbbaier wrote: post #73
withinboredom wrote: post #71

I would suggest NOT using env files. They are a hack. The environment belongs in the environment, not a file on disk; and if it is on a file on the disk, it belongs outside your repository. There is a script in the repository that will bootstrap your local env by storing encrypted secrets into ~/.config/ by asking some questions that you get from the shared passwords manager for development credentials. The key to de…

Do you have an example of such a script?

I will see if I can open source it.

Re: Ask HN: What tools should I use to manage secrets from env files?

#75

Post by hiAndrewQuinn »

proaralyst wrote: post #37

If you're already using systemd, you can use its built-in credentials manager[0] which uses a combination of an on-disk key and the TPM2 to encrypt secrets at rest. Probably annoying if you have more than one machine though [0]: https://man.archlinux.org/man/systemd-creds.1

Hey, this is real cool. Is encryption at rest the only benefit over, for example, injecting the secrets as environment variables into a running systemd service?

I ask because my research suggests that there's a class of security vulnerabilities where attackers can read arbitrary files - but since /etc/system/systemd can be limited to be only readable by root, and the services it runs started by other less privileged users, I wonder how bad it would be to store a plaintext secret right in the .service file would be in practice. Especially since it seems this credentials management thing seems to just create a directory for the process with the decrypted passwords readable anyway (although maybe that's still not readable by an attacker? Still trying to figure this all out myself).

Re: Ask HN: What tools should I use to manage secrets from env files?

#76

Post by hiAndrewQuinn »

hiAndrewQuinn wrote: post #75
proaralyst wrote: post #37

If you're already using systemd, you can use its built-in credentials manager[0] which uses a combination of an on-disk key and the TPM2 to encrypt secrets at rest. Probably annoying if you have more than one machine though [0]: https://man.archlinux.org/man/systemd-creds.1

Hey, this is real cool. Is encryption at rest the only benefit over, for example, injecting the secrets as environment variables into a running systemd service? I ask because my research suggests that there's a class of security vulnerabilities where attackers can read arbitrary files - but since /etc/system/systemd can be limited to be only readable by root, and the services it runs started by other less privileged…

Gonna answer my own question here: No, actually systemd-creds is much better than just putting the plaintext secret into the .service (although that's still probably better than leaving it in a .env file if you have good user permissions set up).

Among other things, TPM and TPM2 are physical chips, which means even someone who steals your actual hard drive couldn't actually decrypt your stuff unless they also somehow got access to the rest of the computer containing that TPM chip. Huge improvement, although I'm not sure if your run of the mill cloud VM has (or even could have) such a chip permanently and uniquely bound to them.

Re: Ask HN: What tools should I use to manage secrets from env files?

#78

Post by gchamonlive »

I usually have .env files in the repositories with the structure and examples. It's a kind of documentation. But I have a template file that gets filled by the CD pipeline with the necessary set of secrets that the deployment need.

I advise against dynamic secrets. In my opinion deployment should be immutable. If you need to change secrets, you need another deployment. The usual exception is where the deployment is too costly or you can't do zero-downtime blue-green/canary deployments.

The template file can be something like a .env.j2 and the secrets can be pulled from something like hashicorp vault, which enables you granular permission for the pipeline runners to read just the necessary kinds of secret that particular deployment needs.

You need however to put a little effort into creating these pipelines, but the benefits are huge.

Post reply on HN