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

91–100 of 147 posts

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

#91

Post by gchamonlive »

oceanfloor wrote: post #87
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…

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.

Cloud lock-in (not being able for example to manage cross-platform credentials) and cost.

By itself AWS Secrets Manager is fine, but as with everything AWS, billing is pretty opaque. If you couple this with a poorly planed Lambda setup, costs can potentially uncontrollably scale.

For what you are paying, AWS Secrets Manager seems too barebones/rigid.

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

#92

Post by IshKebab »

Minor49er wrote: post #24
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.

But the author's argument is that people don't do that. You're pretty much saying "The argument for seatbelts is not compelling. The problem can be solved by driving carefully."

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

#93

Post by joosters »

IshKebab wrote: post #89
joosters wrote: post #81

If you think that putting secrets in ENV is bad, you probably shouldn't take the advice of running ' docker service create --secret="secure-secret" redis:alpine ' either! Putting secrets in a command line makes them just as visible, in fact more so, to other processes. It also makes the secrets available to anyone regardless of permissions, since everyone can monitor the currently running processes and their args (e.…

`secure-secret` is not the secret itself. It is the name of the secret.

Oops, my bad. I saw the '--secret="secure-secret"' part of the command and assumed that was the secret itself! Thanks for the correction.

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

#94

Post by gchamonlive »

jen20 wrote: post #84
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…

> This way I am not bound to [...] keywhiz No, but you’re bound to Vault? I agree that Vault is likely the best solution to this (dynamic secrets are super useful), but “not being coupled to something” is not a benefit you get from it.

You are right, I think that was a little harsh on my part. I can't really say much about keywhiz, I should have left it out of my comment.

Yes, you are tied to Hashicorp Vault once you adopt it, but it isn't much of a problem because you can easily redeploy it in a different cloud.

It might be true to keywhiz, so my comment wouldn't be valid to this point.

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

#95

Post by photon12 »

joosters wrote: post #88
photon12 wrote: post #83

Earlier quoted context omitted.

Aren't these equivalent, given that the /proc/x/environ file exists?

/proc/x/environ is similar, but has more restrictive permissions: user-readable only, whereas /proc/x/cmdline is world-readable.

Fair point.

Though I feel like in any modern app deployment scenario that isn't going to be a meaningful defensible boundary.

The answer is to use neither, especially given the number of times I've used a path traversal vulnerability to expose /proc/self/environ on a pentest, and the one time I was frustrated on a pentest when every app in the environment used a dedicated API for secret retrieval and the path traversal vulnerability I had access to was worthless.

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

#96

Post by R0b0t1 »

michaelt wrote: post #71
ablanco wrote: post #7

I don't agree at all. The reasons in the article all seem like "envs are bad because if you make a mistake you can expose them". This is not exclusive to envs, it applies to all secrets, independent of the medium used to make it available to the process using it. In my experience, if you prevent using envs for secrets (as docker swarm does) all you get is a disgruntled programmer reading the contents of a secret file…

I think what the author means is environment variables are particularly vulnerable to being logged by accident, because: 1. They're stored right next to variables like PATH, JAVA_HOME, LC_ALL and PYTHONPATH which people might plausibly decide to log out every time 2. They'll get printed any time someone writes a shell script with set -x then uses the environment variable. 3. They'll probably end up in your developers…

It's really the latter half of your fourth point. Many programs log envvars for either debugging or intrusion detection purposes just like they run command invocations. In a multiuser environment this can be problematic, especially in a business with multiple security areas. E.g. you don't want IT (that can read the logs) getting access to production resources in a hard to track way (by reusing a production key instead of their more closely monitored access system).

I tend to stick to files, it's just more convenient and reusable. But if you're on a single user system don't worry about passing things via the command line or via envvars.

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

#97

Post by falcolas »

laumars wrote: post #67
ablanco wrote: post #7

I don't agree at all. The reasons in the article all seem like "envs are bad because if you make a mistake you can expose them". This is not exclusive to envs, it applies to all secrets, independent of the medium used to make it available to the process using it. In my experience, if you prevent using envs for secrets (as docker swarm does) all you get is a disgruntled programmer reading the contents of a secret file…

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.

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

#98

Post by gchamonlive »

carlosf wrote: post #66
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…

Vault looks cool, but looking at the reference architecture [1] my guts tell me it's much easier to fuck up setting up a Vault cluster than environment variables. [1] https://learn.hashicorp.com/vault/operations/ops-reference-a...

You can always use their official Terraform module for AWS if you are not comfortable with setting it all up by yourself: https://registry.terraform.io/modules/hashicorp/vault/aws/0....

But if you cut Consul for backend, if you are not using consul for other service discovery and Nomad etc..., you can simplify that deployment a whole lot. You make sure you open the cluster communication port, setup a Application Load Balancer in front of the cluster to balance traffic and serve SSL, configure auto-unseal using AWS KMS (since you are not using it too often, 1$ is OK to have AWS manage your master key), deploy Vault on every cluster instance, and use something managed like DynamoDB as your backend. I think this is a pretty simple yet scalable setup. The amount of cloud lock-in is pretty minimal and can easily be replaced with HAProxy setup.

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

#99

Post by laumars »

gregoriol wrote: post #79
laumars wrote: post #48

Earlier quoted context omitted.

Lots of reasons: - passwords would end up in version control repositories. A whole article could be written on this point alone but to summarise: those credentials will then be in your projects history forever more (or until nuking the history becomes more important than keeping the history) - you can’t then change the credentials easily without having to push a new version of the application - you expose the passwor…

Well, 2/ you probably can't change the credentials just by changing the ENV anyway: there will likely be some kind of restart/reload to perform on one or many components (and such actions better be well logged and tracked, which happens with a redeploy) 3/ your production DB shouldn't be accessible directly with the password, otherwise you have a bigger problem 4/ it's not harder, it's just an if/switch away from you…

2. A service restart is always going to be less risky than shipping a new application (which would also require a restart as well).

3. In an ideal world I’d agree with you. However in many places it is and even in places where it’s not, not hardcoding passwords helps provide defence in depth.

4. Harder to do it securely. Your solution leaks all passwords to all environments and is possibly the worst workaround to the problem (I’ve seen CI/CD inject the correct passwords, which seems the best approach but if you’re going to those lengths then you might as well use a secrets management service)

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

#100

Post by laumars »

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.

> The problem with Hashicorp Vault (and their peers): Your application still need a secret to access values made available to your application's role.

True but those credentials can be decoupled from the application (like env vars are) so you satisfy the developer problem I was addressing.

Post reply on HN