In general, a mounted file would be better, because it is easier to restrict access to filesystem objects both via permissions and namespacing. Also it is more future proof, as the actual ideal solution is to use secret managers like Vault (which are overkill for many hobbyist), which can render secrets to files (or to ENV, but same security issue applies here).
Comment on Disclosure of sensitive credentials and configuration in containerized deployments - ownCloud
inspxtr@lemmy.world 6 months agowhat are the other alternatives to ENV that are more preferred in terms of security?
sudneo@lemmy.world 6 months ago
sphericth0r@kbin.social 6 months ago
It's probably best to look at what the devops industry is embracing, environment variables are as secure as any of the alternatives but poor implementations will always introduce attack vectors. Secret management stores require you to authenticate, which requires you to store the credential for it somewhere - no matter what there's no way to secure an insecure implementation of secrets access
sudneo@lemmy.world 6 months ago
They are not as secure, because there are less controls for ENV variables. Anybody in the same PID namespaces can cat /proc/PID/environ and read them. For files (say, config file) you can use mount namespaces and the regular file permissions to restrict access.
Of course you can mess up a secret implementation, but a chmod’d 600 file from another user requires some sort of arbitrary read vulnerability or privilege escalation (assuming another application on the same host is compromised, for example). If you get low-privileged access to the host, chances are you can dump the ENV for all processes.
Security-wise, ENV variables are worse compared to just a mounted config file, for example.
synestine@sh.itjust.works 6 months ago
A named volume for the config directory for one.
sphericth0r@kbin.social 6 months ago
That's just as insecure lol, env bars are far better