3 ms·
> 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
by politelemon 4y ago
> 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?
- haloboy777 4y agoThey 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.
- auspex 4y agoThe 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.
- XorNot 4y agoI wouldn't consider binding files to be a violation of container immutability, which is how K8S secrets work.
- mschuster91 4y agoIt 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/...)
- bheadmaster 4y agoI 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?
- falcolas 4y agoPersonal opinion: the second. If the container is popped so you can read environment variables, you can read files too.
- mschuster91 4y agoNot always. Stuff like exposed debug toolbars or over-exposing stacktraces can leak environment variables, but (usually not) files.
- newuser2022 4y agoIt'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.
- mschuster91 4y agoRCE is game over, no matter what you do, but leaking environment variables can easily happen via stacktraces or debug settings.
- denvrede 4y agoWe'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.
- ianpurton 4y agoSo how do you get the pods to read the new credentials?
- falcolas 4y agoThe 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.