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.

Arbitrary file read vulnerabilities are extremely common.

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

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.

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

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.

Now, if you encrypt them in memory, or even better obtain the creds in an audited fashion, use them and clear the memory promptly, it's slightly better.

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

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.

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

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.

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.

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