Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Check out the Secrets Operator for Kubernetes. Injects your secrets from a secrets store as a file mounted into your container.


And how is /var/run/secrets any more secure than env?

I guess you avoid the risk of accidentally logging secrets with other env variables but otherwise it seems to be just as secure/insecure.


The secrets aren't in a shared location. They're stored in an ephemeral volume specific to each container which other processes cannot access.


If someone has enough privileges to access /proc/*/environ of another process (i.e. root or the same user or process or child process) then they should be easily able to reach inside the container, no?


Other processes running as the same user can be blocked from reading /var/run/secrets via the likes of SELinux/AppArmor whereas they can't be blocked from reading /proc/environ.

It's a pretty fine distinction and I don't know how many people actually bother doing SELinux etc. in practice, but theoretically it's marginally better.


AppArmor can restrict /proc, see example from docker: https://github.com/moby/moby/blob/master/contrib/apparmor/te...


how does the application pick it up? We use the built in secrets that are injected into the container as env vars and then the application picks it up that way. Not trying to sound combative, just looking for better ways to do things.


Read the file on startup.

Bonus: you can watch the file for changes. Which means your app can pick up rotated secrets without a process restart, whereas if you inject secrets via the environment they're fixed for process lifetime.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: