3 ms·
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 e
by eriner_ 4y ago
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 4y agoThen I'll just pull it from the processes memory directly. It's security through obscurity at best.
- mumblemumble 4y agoIt 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 4y agoNow, 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 4y agoJust an arbitrary file read vulnerability away at /proc/$pid/mem
- mrslave 4y agoI 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.