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

Environment Variables Considered Harmful for Your Secrets

movingfast.io

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Environment Variables Considered Harmful for Your Secrets

#51

Post by tezza »

mreinsch wrote: post #46
tezza wrote: post #45

Earlier quoted context omitted.

Cloud servers ============= Xen supports virtual TPM. I'm no Amazon EC2 expert, but a quick google exposed a few keen souls who tried to use vTPM and failed. This would suggest that Amazon does not yet support vTPM. Re-entering passphrases ======================== Well, unless the machine is permissioned by default you will need to give a fresh instance new authorization. Permissioning by default is the same security…

sniffing isn't the main issue I'm trying to avoid, it's accidental exposure. I.e. minimising the risk that during normal operations the secrets get exposed somehow.

Okay... sniffed accidentally then ( putting them in the wrong directory, not using fs permissions properly etc )

I would say that you should consider malicious sniffing too

Re: Environment Variables Considered Harmful for Your Secrets

#52

Post by rbanffy »

riobard wrote: post #49
RubyPinch wrote: post #42

Assuming you arn't trying to go for top security, and just want a way to keep things safe from leaking due to errors and the such why not just make use of the OS's secrets store? for example, like how https://pypi.python.org/pypi/keyring operates

I would love to know more about this, but AFAIK OS secret stores are mostly a desktop-concept that requires a logged-in user (whose login password is used to decrypt the secret store). On a deployment server, you don't have those.

It should be easy to set up such a key store on server setup or startup. The downside is that, as always, if anyone has access to the user, they can decrypt the keys.

Re: Environment Variables Considered Harmful for Your Secrets

#53

Post by grhmc »

Clearing your environment variables after reading them, and only passing the ENVs required to perform the new task are pretty basic security measures. This was pretty common practice in the 90's, and then I was hoping that would be one of the lessons out of ShellShock.

Re: Environment Variables Considered Harmful for Your Secrets

#54

Post by Rapzid »

klalle wrote: post #9

while i agree that storing api keys in the code repository is not the best idea, i am curious about the suggestion of moving it into chef configs. wouldnt that, in turn, also be stored in a code repository, likely accessible in the same way as the main coe repo? then, this feels like a non-solution to me.

Its a trap thinking you have to store all the config info in Chef(recipes, data bags, etc). Its easy to call out to other services for config info to render templates with.

Mreinsch's s3 reco is a good example. I use this method for storing extra role secrets for AWS.

It's good to keep in mind the words Morpheus when dealing with Chef(and all this stuff really). Free your mind.

Re: Environment Variables Considered Harmful for Your Secrets

#55

Post by kgilpin »

Installing secrets on disk exposes them to potential leakage through backups. This is a major issue, since much less attention is typically paid to access management for backups than to production servers. Therefore I support the approach of providing secrets through the environment.

Once an application has been written to get its secrets from the environment, there is a question of how the secrets are obtained. They can be sourced from a file in an init script, but today we are seeing a lot of momentum towards containerized architecture, and the use of service discovery and configuration systems like etcd, zookeeper and consul.

However, secrets require much more attention to security concerns than the data that these tools are designed to handle. Least privilege, separation of duties, encryption, and comprehensive audit are all necessary when dealing with secrets material. To this end, we have written a dedicated product which provides management and access for secrets and other infrastructure resources (e.g. SSH, LDAP, HTTP web services). The deployment model is similar to the HA systems provided by etcd, consul, SaltStack, etc. It's called Conjur (conjur.net).

Re: Environment Variables Considered Harmful for Your Secrets

#56

Post by marcosdumay »

jheriko wrote: post #38
bodyfour wrote: post #11

Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there. Most (all?) of the current brand of UNIX variants have locked this down quite a while ago, which is a good thing. There are still a few old boxes kicking around though so if you're writing code that is meant to be widely deployed please don't pu…

This is the best argument for not doing this imo. "Classic UNIX behavior was that environment variables were public (any user could see them with the right flags to "ps") so it was well-known not to put anything secret there." The same logic applies to Windows environments and modern *nix too... Storing private data in a public location is obviously a bad idea.

Ok, but that's classical behaviour. Modern *nix behaviour is treating the environment as private data.

I don't get the reason for all that disagreement. Both methos have clear practival advantages and problems, and both are nearly as secure as the other. Use whatever fits better your problem.

Re: Environment Variables Considered Harmful for Your Secrets

#57

Post by kgilpin »

klalle wrote: post #9

while i agree that storing api keys in the code repository is not the best idea, i am curious about the suggestion of moving it into chef configs. wouldnt that, in turn, also be stored in a code repository, likely accessible in the same way as the main coe repo? then, this feels like a non-solution to me.

Yes you're right. Operations teams then find that they have to lock down their Chef / Puppet master much more tightly than before. In so doing, they make these systems harder for developers to work with, and they introduce additional work and overhead for themselves (servicing secrets-related tickets).

Re: Environment Variables Considered Harmful for Your Secrets

#58

Post by kgilpin »

jph wrote: post #23

We've had good success with distributing our secrets using a GPG-encrypted file that we put in /etc, not in the source code tree. We then use an ENV setting to point the app to the file. This gives us good flexibility (because one server can have multiple GPG files if we want, such as alpha/beta/gamma) and good encryption.

How do you manage the decryption key?

Re: Environment Variables Considered Harmful for Your Secrets

#59

Post by hawleyal »

jmnicolas wrote: post #48

You could still store your secret keys in ENV but encrypt them. Only your program has the method to decrypt them so in the case of an ImageMagick sub process it would access only your encrypted secret key with no knowledge to decrypt it. Same thing while debugging : only the encrypted key is printed.

You would need the key to decrypt somewhere also not in your code.

Re: Environment Variables Considered Harmful for Your Secrets

#60

Post by louwrentius »

Please don't use environment variables to store secrets. There are to many angles - as stated by others - where this data may leak into files or processes.

I would propose to use just one folder like /secret and put your config files in there. Exclude this folder from backup on all relevant hosts.

Then spend your time on security of your hosts, applications (OWASP) and monitoring / alerting. Something that you have to do anyway.

Post reply on HN