81–90 of 147 posts
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.g. a 'ps waux' or 'cat /proc/12345/cmdline')
Is transferring them to memory in your startup routine, then doing unsetenv() a reasonable mitigation? It seems like it addresses several of the listed concerns. It's not perfect, of course, but perhaps better, and straightforward.
I don't understand why we have to put them into the environment in the first place (and then make sure we scrub it). Isn't it just as easy to read the secret from a file?
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.…
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…
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.
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…
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…
Also, application secrets for development environments probably shouldn't be super sensitive in the first place, right? For example, for a third party API key for a service like Auth0, we would have a dev tenant within Auth0 so even if a developer's environment is compromised, it can't jeopardize production.
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…
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.
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.…
Aren't these equivalent, given that the /proc/x/environ file exists?
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.…
Earlier quoted context omitted.
> not checked into the source code repository Or checked-in, for easy distribution, just encrypted: https://github.com/sobolevn/git-secret
I mean anything encrypted needs to be decrypted, meaning you have to... have the key stored in an environment variable on the server?