[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.

[metadat]

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.

[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.