Open rvlane opened 3 years ago
I would argue that storing credentials in environment variables is better/more secure practice than using plain text files (configuration files). IMO, credentials belong to the deployment (e.g. one might use Kubernetes secrets for storing credentials). You would separate managing the code from managing the deployment, which is a preferable way.
@rvlane as Vetal said oftentimes the disk is less secure, especially when using docker or the like. If you are still interested why not give it a shot yourself with a PR?
We have customers (major cellular carriers) that search /proc structure for environment variables holding passwords and flag security violations when they are found, Granted you must have permissions to read /proc structure, but they still consider this a security violation.
We have ways to use a fuse file system to inject configuration files into a "fake" file structure to make it impossible for anyone other than the process using it to "see" the contents. This is how we handle the mysqld_exporter and how we managed the maxscale_exporter that we used to use. We were interested in this one because we are moving to maxscale-2.5.
Could an option be added to collect the current required environment variables (mostly MAXSCALE_USERNAME/MAXSCALE_PASSWORD) via a config file vs requiring them to be passed with environment variables? With a config file, one could use a fuse file system to hide the config file, however using env variables exposes the password and violates security requirements.