[jillesvangurp]

Disagree here. Basically if you use docker (which for most of the stuff you mention, you should), environment variables are pretty much how you configure your docker containers and a lot of sever software packaged up as docker containers expects to be configured this way.

Building a lot of assumptions into your containers about where and how they are being deployed kind of defeats the point of using containers. You should inject configuration, including secrets, from the outside. The right time to access secret stores is just before you start the container as part of the deploy process or vm startup in cloud environments. And then you use environment variables to pass the information onto the container.

Of course that does make some assumptions about the environment where you run your containers not being compromised. But then if that assumption breaks you are in big trouble anyway.

Of course this tool is designed for developer machines and for that it seems useful. But I hope to never find this in a production environment.

[jen20]

> The right time to access secret stores is just before you start the container as part of the deploy process or vm startup in cloud environments.

So how do you rotate secrets without bouncing app servers..?!

[lucasyvas]

You don’t - you bounce the servers because it’s simpler. If your secret is static for the lifetime of a deployment - just redeploy to get a new value.

I like secret stores but only when the value of something regularly changes in a way that redeploying becomes unacceptable.

[jen20]

Bouncing things is often unacceptably expensive - caches, consensus and the cost of data redistribution etc are all good reasons to have hot configuration for secrets.

[vitalysh]

inject those variables via mount?

[wegfawefgawefg]

When you launch the docker containers you can pass in process env vars or do it via file. Nowadays people do this via kubernetes config yamls, which passes env to docker. Or rather they used to. Most people now use Helm charts which pass in the env to k8 yaml which pass them to docker. But then they feel its not secure enough... so a lot of people have the env split halfway between github actions secrets, and amazon secrets. The yaml for your github action config sends aws secret uri to the runner, which runs cdk which grabs the aws secret, and passes that to helm which makes k8 yamls, which passes the env to docker, which passes it to the process.

Then I killed myself and was reborn. Now I just use an env file.