[laumars]

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 their own secrets management service.

(not affiliated with Hashicorp and other services exist).

[falcolas]

The problem with Hashicorp Vault (and their peers): Your application still need a secret to access values made available to your application's role.

The values might not be in the immediate container space (well, aside from being in program memory), but they're only one (likely well documented internally to the container) hop away.

[laumars]

> The problem with Hashicorp Vault (and their peers): Your application still need a secret to access values made available to your application's role.

True but those credentials can be decoupled from the application (like env vars are) so you satisfy the developer problem I was addressing.

[andrewnicolalde]

I've constantly tried to figure out the answer to this. Is there literally any solution to this that doesn't involve the access key for the secrets vault being supplied by human input / secure hardware? But even in the case of secure hardware, if the hardware trusts the requesting application and that application becomes compromised, doesn't that defeat the purpose? Where is trust anchored?

[ablanco]

Sure, and they are great. But in some cases, it's inevitable to read some secrets from the secret management service to envs. This is what docker swarm doesn't allow with the 'docker secret' command