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

31–40 of 147 posts

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

#31

Post by gchamonlive »

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 still exposing secrets with Env Vars, but the next step is to use Vault directly. Vault has been pretty reliable so far. It is using AWS KMS for managing the master key and a scalable DynamoDB table for high availability backend.

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

#32

Post by seer »

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)

Hm not sure I understand how google secret manager relates to berglas to be honest, thought those two were separate apis...

As for berglas itself, we also use it and have been very happy with it. Since you put just the names of your secrets into the ENV files, not the secrets themselves, they can be easily stored in version control, passed around in chat and you can just do whatever you want with them. Instead of:

    ENV_PASS=my-secret-pass
You do:

    ENV_PASS=berglas://bucket/secret-id
And it will be decrypted at the last possible moment - e.g. when the system starts. Or even later if you need to, if you use the apis provided.

Funny enough we had implemented the almost the same approach with AWS SSM apis ourselves (https://github.com/ovotech/ssm-env-secrets). But I think it should be possible to use berglas in AWS directly without issue.

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

#34

Post by hobbescotch »

cameronbrown wrote: post #23
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?

Not sure if it's still like this, but I got in on KMS early on and I think you could only store Google generated keys. However, I needed to be able to store API keys, passwords, etc... So I used the KMS generated keys to encrypt GCS files who themselves contained the API key, passwords, etc... that needed storing.

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

#35

Post by irjustin »

cholmon wrote: post #25
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...

It's also accessed that way in Ruby. ENV['MY_VAR']

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

#36

Post by [deleted] »

cholmon wrote: post #25
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...

[deleted]

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

#37

Post by cimnine »

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 experience almost always not done pro-actively.

The only thing that's Docker related in that post is that it does offer a turn-key solution for Docker-based projects. The solution's principle can be applied to other projects though, i.e. secrets should be read from a config file (or something like Vault).

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

#38

Post by thesimon »

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...

> not checked into the source code repository

Or checked-in, for easy distribution, just encrypted:

https://github.com/sobolevn/git-secret

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

#40

Post by jeffbee »

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…

Perhaps the author wrote the article on their MAC.
Post reply on HN