Hacker News Reader

Comment by politelemon | Hacker News Reader

> It’s a good practice to have your objects use a secret in an environment variable since other parts of your system can access environment variables.

Was this generated by ML?

View on HN

It sounds confusing but is correct. Passing secret environment variables in a way that protects from someone gaining either RCE or another information disclosure avenue (e.g. a Symfony debug toolbar exposing PHP's $_SERVER) is hard. Using k8s-managed secret files (that are technically done as a Docker bind-mount) helps against unintentional information disclosure avenues, but still are vulnerable against an attacker who has achieved RCE (as they can simply execute a cat /var/run/secrets/...)

I think it's confusing because it was really poorly phrased:

    1. DON'T keep secrets in an environment variable

    It's a GOOD PRACTICE to have your objects use a secret in an environment variable

So which one is it? Don't keep secrets in env vars, or it's good practice to keep secrets in env vars?

Personal opinion: the second. If the container is popped so you can read environment variables, you can read files too.

Not always. Stuff like exposed debug toolbars or over-exposing stacktraces can leak environment variables, but (usually not) files.

It's not correct because he states "That’s why it’s best to use secrets as files", this is event worse than store in on ENV because in this case you just need read access to the file system instead of needing code execution, if you have RCE with the same privilege level of the application you will have access to the secret anyway.

RCE is game over, no matter what you do, but leaking environment variables can easily happen via stacktraces or debug settings.

They didn't even mention the alternative to this statement. I've only ran applications with environment variables. And since they're allowed everywhere (lambdas, docker images, heroku and whatnot), It's hard to imagine how passing credentials into code, could've been done otherwise.

The two other ways I’ve seen is a direct dependency on the secrets manager or injecting files.

Environment variables seem to be the standard.

Direct dependency is usually bad and injecting files violates the immutable nature of a container.

I wouldn't consider binding files to be a violation of container immutability, which is how K8S secrets work.

We're using Vault to create ephemeral database credentials for our services that are rotated every other hour, for that use case envs are not even viable because they're injected at startup and then never again.

So how do you get the pods to read the new credentials?

The pods would have to either read directly from Vault, or a k8s controller which has vault access. In big brain fashion, one could also hard fail on a db auth failure so new pods - with the new secrets - can be spun up.

Reply on news.ycombinator.com