Encryption support for storing basic auth/bearer token in prometheus.yaml

[vinoth dharmalingam]

Hello,

We see the basic auth/bearer token details are being stored in the prometheus.yaml/password file in a plain text for target scraping. Our cyber process does not allow this plain storage. Are there ways for storing it in the encrypted format similar to how bcrypt encryption supported in web.config.file for HTTP APIs (version 2.24)? Please suggest. Thanks in advance.

Regards,

Vinoth

[Christian Hoffmann]

Hi,

On 2021-02-01 14:39, vinoth dharmalingam wrote:
> We see the basic auth/bearer token details are being stored in the
> prometheus.yaml/password file in a plain text for target scraping. Our
> cyber process does not allow this plain storage. Are there ways for
> storing it in the encrypted format similar to how bcrypt encryption
> supported in web.config.file for HTTP APIs (version 2.24)?

If you are talking about credentials which are required for Prometheus
to access other endpoints as a client, then the answer is "no" for
Prometheus and the answer is most likely "no" for any other software as
well, as far as I know.

I have often seen this issue come up: Some IT policy forbids storing
plaintext passwords without any context.

It is easily possible (and a good policy!) to avoid storing plaintext
passwords when acting as a server or account database, e.g. when the
server has to verify a user- or client-supplied secret. This can be
solved by using plain hashes (outdated, as it is prone to quick
cracking/rainbow tables) or more advanced schemes such as pbkdf2, bcrypt
and scrypt.

However, when Prometheus has to prove to another endpoint that it
possesses a certain secret, this won't work as hash functions, bcrypt
etc. are designed to be non-reversible. In theorey, you could encrypt
such passwords and lots of Enterprise software supports such schemes.
Nobody wants to ask the next question: How would the software (i.e.
Prometheus) decrypt the stored password? The answer is: With a key which
has to be placed right next to the config file with the encrypted values.

In other words, in most cases there is zero gain in security while still
having to deal with an increase of complexity.

The proper way to deal with this is ensuring that only the desired
technical users and persons have read permissions for your config files.

This applies to passwords, tokens and private keys all in the same way.

If your IT department has a solution to this fundamental "issue", then I
guess everyone will be eager to learn about it. :)

Kind regards,
Christian

[vinoth dharmalingam]

Thanks Christian for the timely response. Appreciate it.