Hacker News new | ask | show | jobs
by dharmab 978 days ago
Envvars have much weaker access controls than files; basically anything in the same PID namespace can read your envvars. Poke around in /proc/*/environ to see for yourself. Files can use user permissions and MAC (AppArmor, SELinux, etc) to secure them against unauthorized processes.
1 comments
wutwutwat 978 days ago
If running in a containerized environment ENV is injected only to the container, at container runtime. If you’re running your containers with a single process, you are doing the exact access control you just outlined. At that point what is the difference between a file on disk with read permissions for the proc owner vs only the proc having the ENV injected to its shell at runtime? I’d maybe even say the ENV at runtime is more secure than the chown’d file on disk because the ENV injected variant is ephemeral and when that container/proc dies, so does the ENV sitting in its memory, whereas the other leaves a file on disk potentially depending on where it was written to, regardless of who can access it. Then there’s the fact that a lot more people than you think run containers as root so all file access control goes out the window.

From a security perspective it is always more secure to have something only in memory of the running process than it is to have a file on disk regardless of file permissions

link
dharmab 978 days ago
Containers don't enforce that isolation. Another process can nsenter the container's PID namespace. You also have issues if your container's PID1 creates subprocesses.

File are not necessarily written to disk. e.g. the Secrets CSI Driver loads secrets directly from a secrets store as virtual files within ephemeral volumes.

link
ninkendo 978 days ago
> the Secrets CSI Driver loads secrets directly from a secrets store as virtual files within ephemeral volumes.

You could totally spin this as agreeing with 12factor… the virtual files are attached resources that are part of a deployment. The configuration, expressed as env vars, configures where to look for those secrets (ie. their filesystem path) and where they’re used (e.g. as a templatized database URL.)

12factor says config should be env vars, it doesn’t say secrets should be. It’s unfortunate that the site lists credentials as an example of configuration, but… it’d be great IMO if we could sidestep a lot of contention by just considering this to be errata of the example, and that secrets are left as an exercise to the user.

link