[eriner_]

I agree completely. Storing secrets in environment variables is wrong: https://blog.forcesunseen.com/stop-storing-secrets-in-enviro...

Even unsetting environment variables leaves them in /proc/self/environ. There isn't a thread-safe way to unset environment variables in POSIX, so even if you `unset TOP_SECRET` from within a program the contents of /proc/self/environ will remain unchanged and available.

[josephcsible]

But /proc/*/environ is only readable by the user the process is running as and root, so if you can read it, you're already on the other side of the airtight hatchway.

[eriner_]

Arbitrary file read vulnerabilities are extremely common.

[josephcsible]

Sure, but if you have one of them, then you can read the secret files out of /vault or whatever too.

[eriner_]

Correct! This is why I explicitly said the following in the blog post I linked above:

> Once the application hits “readiness” status (as determined by health endpoints or the load balancer), the secrets volume should be unmounted and made inaccessible.

[metadat]

Then I'll just pull it from the processes memory directly. It's security through obscurity at best.

[mumblemumble]

It seems to me in line with the comment that the post quoted:

> Ultimately, secrets need to live somewhere and need to be accessed as plain text. Just make sure that the access as small window is as [sic] possible, and try to obliterate it after use, if possible.

This is not an all-or-nothing situation; it's a game of mitigation. If the process needs to retain the secret in memory, true, there's not much you can do about that. But I don't think that minimizing where else you're storing it is just security through obscurity. Fewer possible attack vectors is still fewer possible attack vectors.

[Rapzid]

Just an arbitrary file read vulnerability away at /proc/$pid/mem

[mrslave]

I really like my applications to at least try to reestablish dropped connections though. But I do appreciate the minimization mindset with respect to secrets.

The last time I was responsible for the scaffolding of a new software service it supported reading secrets from a file. It confused the operations team and I was just told to include support for an environment variable. Oh well, I tried.

[hedora]

Or, if you only have access to proc, from the process's heap.

[CameronNemo]

How do you actually unmount the volume with kubernetes once the secrets are read and the process is ready? I've never heard of a feature like that.

[thinkmassive]

From my comment farther below:

> If your app can’t interface directly w/k8s, but it can read secrets from a file, you can use a small init program to fetch the k8s secret and write it to a named pipe. This is advantageous compared to mounting as a volume, because the pipe disappears after both ends close their connection to it.

[aliswe]

you dont ... you remove the mapping and restart the pod.