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

21–30 of 147 posts

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

#21

Post by giberti »

hankchinaski wrote: post #5

We have recently started removing credentials in env vars and started using google secret manager (previously berglas) and its been amazing so far. AWS and azure should have the same. More challenging when you don’t have all the infrastructure and services in place (ie. when working on plain VPS or other systems without those tools)

Amazon has a similar offering called Secrets Manager which can be used for sensitive secrets as well as configuration values. https://aws.amazon.com/secrets-manager/

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

#22

Post by axegon_ »

hellofunk wrote: post #3

Every production product I’ve ever worked on, the entire team put database credentials in the environment variables.

This is commonplace for most people when they start working on a new project, including myself. And sometimes when you are rushing through to meet some deadline it slips through and you end up realizing a lot later. In order to tackle this, I've developed the habit of adding a middle layer in the code between the configuration (whether it be ENV variables or config files) and the actual application. So when you eventually have time or realize that you forgot about it, swapping/fixing it isn't an issue.

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

#23

Post by cameronbrown »

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.

Why not use KMS for storing keys directly?

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

#24

Post by Minor49er »

hellofunk wrote: post #3

Every production product I’ve ever worked on, the entire team put database credentials in the environment variables.

The author's arguments aren't compelling. Most of his points can be solved by properly configuring any logging processes to grab only what's necessary and not letting newbies commit unreviewed code.

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

#25

Post by cholmon »

quotemstr wrote: post #12

The advice is good. But why is ENV capitalized? The term is just "environment variable". One heuristic I use for evaluating technical material is orthography: if you spell or capitalize or spell something improperly, it's likely you'll get a lot else wrong too. As for secret storage: didn't we solve this problem with keyrings? If I must put a secret in long-term plaintext storage, I might as well put it in a file, wh…

Maybe he's got a history of working with PHP? $_ENV is an autoglobal array that gets filled with environment variables.

https://www.php.net/manual/en/reserved.variables.environment...

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

#26

Post by tnorthcutt »

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.

If you put secrets in your codebase, they're now on x machines, where x is the number of developers on your team, plus their old laptops they gave away to family members and forgot to wipe, plus Backblaze because one developer doesn't have git repositories excluded from their backup settings, plus GitHub because that's where your repo is hosted.

If you don't store secrets in your codebase, they're just on ~one machine: the server hosting your application.

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

#29

Post by mightypirate »

quotemstr wrote: post #12

The advice is good. But why is ENV capitalized? The term is just "environment variable". One heuristic I use for evaluating technical material is orthography: if you spell or capitalize or spell something improperly, it's likely you'll get a lot else wrong too. As for secret storage: didn't we solve this problem with keyrings? If I must put a secret in long-term plaintext storage, I might as well put it in a file, wh…

because traditionally envs are all caps. I think it conveys that extremelly well

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

#30

Post by xiwenc »

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/current/reference/ht...

Post reply on HN