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

121–130 of 147 posts

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

#121

Post by joshspankit »

photon12 wrote: post #115
joshspankit wrote: post #109

Earlier quoted context omitted.

Any chance they documented that setup publicly? Would be interested to dive in to how all that works and gain any new insights

It's a large company that built their own bespoke internal credentials service running over a TCP port to the application with another proprietary protocol to push key material to hosts. Can't say much more due to NDAs. Edit: this service handles credentials and rotation for hundreds of thousands to millions of hosts.

!

Wild.

I guess with custom protocols there’s not much that can be learned from that setup. Presumably wrap the request in security, handshake to verify authority, use the custom protocol to deliver the secret which is also wrapped in security.

Too bad they keep it close to the vest, but I certainly don’t begrudge them for it.

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

#122

Post by andrewnicolalde »

falcolas wrote: post #97
laumars wrote: post #67

Earlier quoted context omitted.

There are actually key/value stores that solve this securely, such as Hashicorp Vault. The issue isn’t that it can’t be done but more that most people either don’t already know it can be done or don’t want to invest in the infrastructure to do it. Regarding the latter point, for self hosted solutions I can sympathise a little and it’s really a question of risk analysis. But most cloud computing services do offer thei…

The problem with Hashicorp Vault (and their peers): Your application still need a secret to access values made available to your application's role. The values might not be in the immediate container space (well, aside from being in program memory), but they're only one (likely well documented internally to the container) hop away.

I've constantly tried to figure out the answer to this. Is there literally any solution to this that doesn't involve the access key for the secrets vault being supplied by human input / secure hardware? But even in the case of secure hardware, if the hardware trusts the requesting application and that application becomes compromised, doesn't that defeat the purpose? Where is trust anchored?

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

#123

Post by quotemstr »

coldtea wrote: post #119
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…

> 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. And while the program env is lowercase, the environment is commonly referred to as ENV in technical literature, APIs and so on. If you didn't know that, it's likely you are getting a lot else wrong too... Plus, the "heuristic" is bogus anyway. T…

> the environment is commonly referred to as ENV in technical literature

No, it isn't.

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

#124

Post by quotemstr »

coldtea wrote: post #120
Izkata wrote: post #44

Earlier quoted context omitted.

The example they use at the top of the article is in bash/shell, and seeing it written as in the article (as "ENV variables") is kinda like a code smell, indicating the author isn't really familiar with what they're criticizing. I think that's what GP is getting at, and it threw me as well - the article really only makes sense when looking at it from the perspective of the author not knowing how env vars are scoped.

It's very common to write ENV in all caps. You can be a bona fide master in UNIX and write it that way (just like some people write UNIX and others Unix). Sorry, but technical knowledge/experience is not about particular spelling conventions and word proofing, anymore than they are about wearing "business" clothes...

> Sorry, but technical knowledge/experience is not about particular spelling conventions and word proofing

Yes, actually, it is. Sloppy language indicates a sloppy mind. I absolutely crank down my estimate of someone's technical competence when I see him writing badly and will continue to do so. Once in a while, you do see bad writing coupled with good technical insight --- especially in infosec for some reason --- but it's the exception, not the rule.

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

#125

Post by wolco »

jimktrains2 wrote: post #116
linkdd wrote: post #69

Earlier quoted context omitted.

The plain config file must live in memory (tmpfs). The encrypted config file on a hard drive that is accessed only to decrypt the file to memory.

No, I mean management of the secrets. Though it is a rather moot point as the same problems apply to most systems anyway.

Wiki protected pages by role. When roles change so do passwords.

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

#126

Post by wst_ »

Ebanix wrote: post #41
y7 wrote: post #13

So the author offers two alternatives: 1. Using docker-secret inside of a Docker swarm 2. Using Keywhiz [1], a Java server together with a FUSE client. This seems overkill for a lot of cases. If environment variables are such a security problem, why not just use a config file (not checked into the source code repository) with proper permissions set? [1] https://developer.squareup.com/blog/protecting-infrastructur...

https://12factor.net/ Config is the third commandment. IMO it also makes it super easy to swap configs for different environments.

Did you read the article? Author knows about, mentions it in first sentence and still is against putting secrets there.

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

#127

Post by timmytokyo »

falcolas wrote: post #110
oceanfloor wrote: post #87

Earlier quoted context omitted.

What's wrong with AWS Secrets Manager? If I'm already working 100% in Amazon, I'm tempted to use Secrets Manager rather than justify the cost in hours to deploy and maintain a Vault cluster. Interested in your opinion.

IMO, it gets expensive quickly, and it was designed around AWS' use case, which involves credentials that roll on a regular basis. Outside of RDS, its value for the price goes downhill quickly. To a sister comment who mentions parameter store - that UI is the biggest leaking bag of horse manure I've ever had the displeasure of using. We made the mistake of using it, and moved over to Vault at the first available oppo…

I assume you mean Parameter Store's web console UI? I've never really used it; we use only API endpoints and command-line tools, and it works great.

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

#128

Post by remmargorp64 »

Someone1234 wrote: post #76
y7 wrote: post #13

So the author offers two alternatives: 1. Using docker-secret inside of a Docker swarm 2. Using Keywhiz [1], a Java server together with a FUSE client. This seems overkill for a lot of cases. If environment variables are such a security problem, why not just use a config file (not checked into the source code repository) with proper permissions set? [1] https://developer.squareup.com/blog/protecting-infrastructur...

It reminds me a lot of .Net Core's newish "Secret Manager." They created a user profile storage vault that's outside the deployment/source code path (like ENV variables), and then for some inexplicable reason tell you not to use it in production without good justification anywhere and to use their paid service instead ("Azure Key Vault" $3/100K requests) which is multiple extra points of failure (even ignoring Azure'…

If I understand correctly, the primary advantage of using a secrets manager is that you can log all of the requests.

If your security is compromised, it's compromised, but having at least some kind of auditing can be hugely beneficial from a security standpoint.

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

#129

Post by [deleted] »

wst_ wrote: post #126
Ebanix wrote: post #41

Earlier quoted context omitted.

https://12factor.net/ Config is the third commandment. IMO it also makes it super easy to swap configs for different environments.

Did you read the article? Author knows about, mentions it in first sentence and still is against putting secrets there.

[deleted]

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

#130

Post by photon12 »

joshspankit wrote: post #121
photon12 wrote: post #115

Earlier quoted context omitted.

It's a large company that built their own bespoke internal credentials service running over a TCP port to the application with another proprietary protocol to push key material to hosts. Can't say much more due to NDAs. Edit: this service handles credentials and rotation for hundreds of thousands to millions of hosts.

! Wild. I guess with custom protocols there’s not much that can be learned from that setup. Presumably wrap the request in security, handshake to verify authority, use the custom protocol to deliver the secret which is also wrapped in security. Too bad they keep it close to the vest, but I certainly don’t begrudge them for it.

I mean the same company built a service with better architecture that they sell as part of their managed computing environment options.

Some people complain about not wanting to use it due to "lock-in."

Post reply on HN