Security features (basic auth and hidden credentiales)

[ApoXalvation]

Allow load configuration from the config file with the lowest priority to prevent showing credentials in ps output for security reasons and also a critical feature by @AirTrioa - basic auth on exporter endpoint.

[oliver006]

Thanks for the PR!

I think you can use env variables to prevent issues with surfacing sensitive information via ps. I also don't love how adding the conf file struct adds a ton of replication of the fields that the exporter struct has.
In absence of stronger arguments re: safety I'm inclined to not add the config file support.

The basic auth support can be done by e.g. nginx but adding it to the exporter seems rather minimal so I'm ok with that. Can you please split out the basic auth stuff into its own PR so it can be reviewed/discussed independently from the config file stuff? Thanks!

[ApoXalvation]

Hi @oliver006,
First of all, thank You for your work. Below are some of my thoughts:

The command "ps auxewww" displays all environment variables, which is why loading configuration from a file is considered more secure.

Regarding the basic authentication function, setting up an additional nginx instance appears redundant and offers no benefits, only expenses—namely, additional configuration, automation, and packages to maintain. Please note that other exporters, such as mongodb-percona, also provide administrators with the option to enable basic authentication.

[oliver006]

The command "ps auxewww" displays all environment variables, which is why loading configuration from a file is considered more secure.

Interesting, I didn't know that. That certainly opens a vector to retrieving secrets but it also requires the right user permissions, no? And if e.g. root is compromised (to read all env variables) then the attacker can also read the file with secrets? I'm asking to make sure that this actually adds addtl protections.

setting up an additional nginx instance appears redundant and offers no benefits, only expenses

The counter-argument is that adding a nginx sidecar with basic auth is light-weight, and one of the most robust, battle-tested web servers that I would trust to robustly handle malicious input from internet.

[ApoXalvation]

but it also requires the right user permissions, no?

No, root access is not needed in certain cases - that allows an attacker to escalate its permissions. Confident data must not be provided to process by flags/arguments nor envs. That's why lots of processes like web servers databases etc hide its envs ex:
mysql -u root -p mypassword shows up as mysql -u root -px xxxxxxxxxx in both top and ps -ef
but for a very short period of time when the process is forking itself to overwrite its envs it is possible to read those variables too, so the best approach is to not pass confidential data via envs nor args.

The counter-argument...

You can always choose the nginx or other software, this should be an option. As I wrote earlier, lots of exporters give You such option so that approach will be more consistent with the prometheus ecosystem.

[oliver006]

1. the env vars; I hear you, this makes sense. Can we please look into using a library that handles both the env and config file variables? There got to be a better way than doing this all by hand (kingpin comes to mind?)

2. ok, let's do basic auth. Can you look into using the https://github.com/prometheus/exporter-toolkit package? They handle basic auth and also tls right out of the box.
   (this might break some config params but not sure)