Create a way to not have (Redis) credentials in an environment variable

[fblz]

Moved from #177:

Using environment variables for configuration does not provide a secure way to manage Redis credentials.
I propose implementing a configuration file to prevent credentials from being accessible through the environment.

From Luzifer in #177:

Please elaborate. Environment variables are an issue for systems with shared access, files are too. Environment variables will fall when the system is compromized, files will too. Environment variables can be injected by a wrapping process, files cannot.

So how would the security increase by writing the redis credentials into a file on disk in opposite to taking environment variables from a security store?

I think the following holds some good arguments on why environment variables are sub optimal for secret storage: https://security.stackexchange.com/questions/197784/is-it-unsafe-to-use-environmental-variables-for-secret-data

My concerns here are mainly with credentials ending up in crush dumps or similar.
I would prefer to pass the credentials at runtime via dedicated secrets management, but this is a bigger change.

[Luzifer]

Okay to take the post you linked:

• Mention of ps -eww - How should that expose env-vars? Okay if you put it into the CLI call it might (cannot reproduce as that's just plain stupid and nothing on my system uses that). When puttin them into through systemd / docker / k8s secrets they are not exposed.
• Application outputting env for debugging… …eh, yeah… …OTS does not do this as the ENV contains secrets…
• ENV passed to child procs - In Go you need to do that explicitly - also OTS has no child procs.
• Crashdumps: "Go doesn’t enable crash dumps by default […]"
• Last point: Improper management on OPS side which TBH is not an application issue but an organisational one.
• Accessing the /proc/<pid>/environ as the same user (or root): You can read the file.

So still, I don't see any argument against ENV vars and pro files which is effort to implement, a breaking change and does IMHO not improve security.

• The file needs to properly protected (as do the ENV vars)
• The file needs to be properly deployed and managed (as do the ENV vars)
• If the machine falls the file falls (as do the ENV vars)
• The file cannot be injected through Docker secure ENV…
• The file needs to be stored on an encryption-on-rest-FS (the ENV vars when coming from an env file needs to)
• Both can be set through K8s secrets
• In both cases the machine needs to have a proper protection