Something else pulls from the vault and exposes it as a regular env var to your process. The .env file is a workaround to get this running locally! For open source, the simplest to explain is using a k8s secret mounted to a pod — pod identity allows access to the secret via rbac, which cannot be faked. Only that pod has access to that secret. But your process, running on the pod, sees it as an env var.

You were on the right path when you called a vault “one more layer of redirection.” A vault on its own won’t dramatically improve your security posture. Neither will a .env file.

Instead, they both beat the alternative (which is writing secrets and environmental config directly in the source code). And they’re both part of defending in depth.

Defense in depth is hard to explain to a five year old, so think of candy. You’re five and you’re obsessed with candy. If I don’t want you to eat pounds of it every single day, I’ll likely do different things to stop you.

1.) I’ll give you a reasonable amount of candy.

2.) I’ll explain that if you eat too much candy, you’ll face health consequences like tooth decay or childhood obesity.

3.) I’ll put the candy somewhere both out of sight and out of reach.

Software security is like that too. Instead of relying upon just one method, you’ll do a number of different things. On their own, few of them are really very useful. But when you combine them all together, you can end up with a reasonably secure system.

In the case of vaults, it’s just a slightly safer tradeoff with its own problems. We’ve already established that it’s bad to write secrets and environmental configuration info in source code. One way around that is to put secrets in a .env file but then distributing that file becomes the weak link. Maybe you Slack them around, or email them or maybe you write all the secrets on a whiteboard in your office? A vault has a lot of flaws, but it’s better than writing them on a whiteboard. In some threat models, it’s better than Slack or email.

It adds depth but it’s far from perfect.

During deployment, the pipeline connects to the Vault, dumps relevant secrets in a .env file that it pushes to production systems that the application then reads from.

A script fetches values from a database then sticks them in a file. This script runs before the your application starts so the file will be there waiting.