Re:The Twelve-Factor App
by samus on Thursday October 12, 2023 @11:30AM
(#37858594)
The basic idea is still valid. You might just have to use a more appropriate mechanism when using containers. For example, the explanation of the Config factor explains that a config file can also be used.
[ Parent
| on HN ]
do you have any examples of more secure ways of injecting secrets?
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.