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

Don't use ENV variables for secret data (2017)

diogomonica.com

Post reply on HN
Print view View original

51–60 of 147 posts

Re: Don't use ENV variables for secret data (2017)

#51

Post by time0ut »

willis936 wrote: post #6
_wldu wrote: post #4

Earlier quoted context omitted.

It's way better than hard coding them into the code.

Why is that? Also, as an aside: The very premise of plaintext credentials for computer-computer database connections always seemed strange to me. Maybe I'm just not knowledgeable enough here, but I wish the standard for database credentials was key-based.

It is pretty well supported on many common databases.

A few years ago, I added short lived, auto-rotated certificates (signed by our internal CA) to all of our applications. We used these for mTLS for internal app to app calls.

I also wanted to use them to authenticate to the databases. MySQL and Oracle support this sort of authentication just fine. The obstacle I ran into was trying to explain to the DBAs what a certificate was and why it'd be a good idea to use it instead of having them manage user names and passwords for us. They decided it was too much work and stone walled. I eventually gave up and moved on.

Re: Don't use ENV variables for secret data (2017)

#52

Post by djsumdog »

xiwenc wrote: post #30

From experience, it's good to support multiple ways of configuring an app. Depending on your case, this could become hard or requires naming conventions. This way you can move secret data to files if needed depending on the deployment choice. My own rule of thumb is: 1) sensible default value 2) read from file 3) read from env Examples: - https://github.com/spf13/viper - https://docs.spring.io/spring-boot/docs/curren…

When I was doing Scala development, we went the same route using TypeSafe Config. Default/file in the src/resources which could be overridden by ENV.

It seems like secrets aren't orchestration agnostic. You can't seem to use Docker secrets without being in swarm mode, and k8s has its own secrets management system (or if you're running on AWS, you can use pod2iam and ssm to store/get encrypted parameters). I've been at places that use k8s+vault as well.

Re: Don't use ENV variables for secret data (2017)

#56

Post by linkdd »

cimnine wrote: post #37
kwhitefoot wrote: post #11

Great :-( Had to read to the end of the description of why environment variables are bad to discover that it is effectively an advertisement for Docker. I don't use Docker so the article told me pretty much nothing that wasn't fairly obvious already, although it is a valuable reminder.

This is not Docker related. If an application spawns a sub-process, that sub-process will inherit all environment variables. Which might be fine or might not be, e.g. if the spawned application is user controlled. Also tools such as Airbrake or Sentry often send all your ENV variables to the error collection server, effectively exposing your secret values. Most such tools offer to filter variables, but that's in my e…

I wonder why you would run a user supplied application without sandboxing it (reset env, user with almost no permissions, ...)

Re: Don't use ENV variables for secret data (2017)

#57

Post by kevmo314 »

stanmancan wrote: post #43
thesimon wrote: post #38

Earlier quoted context omitted.

> not checked into the source code repository Or checked-in, for easy distribution, just encrypted: https://github.com/sobolevn/git-secret

I mean anything encrypted needs to be decrypted, meaning you have to... have the key stored in an environment variable on the server?

This would at least alleviate having to know n different env secrets that need to be set.

Re: Don't use ENV variables for secret data (2017)

#58

Post by linkdd »

gpmcadam wrote: post #50
gchamonlive wrote: post #31

I am progressively adopting Hashicorp Vault as the secrets manager of choice. It can be used by a variety of different scenarios -- directly into the application using AppRole, with Terraform using it's secrets provider, by developers, during vault authentication when they get their secrets and access regenerated. This way I am not bound to docker swarm, or keywhiz, or god forbid AWS Secrets Manager. As of now, I am…

How do you share the token to access Vault to your code?

Using AppRoles and consul-template. And if you're on Kubernetes, you can use https://github.com/sethvargo/vault-kubernetes-authenticator in an init container.

Re: Don't use ENV variables for secret data (2017)

#59

Post by stanmancan »

kevmo314 wrote: post #57
stanmancan wrote: post #43

Earlier quoted context omitted.

I mean anything encrypted needs to be decrypted, meaning you have to... have the key stored in an environment variable on the server?

This would at least alleviate having to know n different env secrets that need to be set.

Yeah, it’s convenient but it doesn’t solve the topic of the post, which is “you shouldn’t use environment variables for secret data”

Re: Don't use ENV variables for secret data (2017)

#60

Post by alchemism »

ravenstine wrote: post #42
hobbescotch wrote: post #9

The way I got around this was to store secrets in Google KMS encrypted files in Google Cloud Storage. The KMS key and encrypted files share the same name and can be accessed by that name programmatically. This secret storage method works really well for me and lets you easily access & manage secrets across all environments. It's so convenient, I sometimes even use this system as a simple key/value store.

That seems nice, but won't you be pwned the day that GCS accidentally loses your files, or your entire Google account gets locked because its algorithm mistakes it as a bot? The danger of that sounds greater than the possibility that your environment variables get leaked.

Neither of those scenarios quite applies to the cloud side of Google.
Post reply on HN