Note: Another techie post. Sorry! This conundrum has really taken over my spotted mind…
I’ve searched high and low for months trying to figure this one out, dear reader, and I’m now asking the general Internet for any ideas on how to make container secrets less dangerous. Especially in the age of daily supply chain exploits and privilege escalation bugs, this feels like a weak link.
It feels so odd to have a well-known directory, /run/secrets, sitting in every container, waiting for a ne’er-do-well to come in and read it all out. I feel like the files in there should be read-once then somehow inaccessible, but I’ve been unable to figure out how to convince the Linux kernel to do that with files. It’s driving me mad!
I’ve asked a few security-minded friends and colleagues, both at work and in my broader network, and all of them have suggested workarounds but none of them have felt really secure. One widely circulated idea is to use environment variables instead. But then all the attacker has to do is read out ENV – sounds to me like that would be even easier than convincing a typical app server to display an attacker-controlled file from the file system!
One thing I personally thought of was to mount an empty tmpfs on /run/secrets after container initialisation in a custom entry point. This still feels like a hack, but it’d be much harder to get the app server to umount (since you are dropping to non-root, right?) and the file descriptors shouldn’t remain open after they’re read in. Still, this feels like a really cheesy hack.
Has anyone else thought of an ingenious solution to this problem? Is anyone else even thinking this is a problem? I’d love to have a discussion about this, either in the comments or, if you’re feeling old-school, find me on Libera IRC as Spots.