Add support for certificate managers/keystores

[gillg]

Hello,

It could be very usefull and compliant with lot of security levels to add the support of certificate managers/keystores as plugin or embded providers.

As common keystores we could start with :

• jks (java keystore)
• pfx (alias PKCS#12, windows certificate export format)
• Windows certificate store (where are stored already installed certificates)
• AWS cloud HSM
• Azure Key Vault

I know we could delegate it to a reverse proxy with already these capabilities, but for a full in transit encryption compliance it can be a nightmare.

[roidelapluie]

Thanks for your interest in this project.

This is out of scope for this library, but as you pointed out, this library should provide enough to enable a secure connection between a load balancer that supports these features and the exporter itself. Additionally, you are requesting embedding quite big dependencies (AWS SDK, Azure SDK) which would force everyone importing this library to also depend on.

[gillg]

Tanks for your answer !

What is your recomendation in case of third party endpoint like a reverse proxy or load blancer, to have a full on transit encryption ?
Except in PEM format it's not possbile to share a certificate with multiple components on a server and the renew operation could become a nightmare.
I'm not fan to embded big SDK like you said, but I would think to a solution to cover a use case where you can manage a certificate at almost one place (at the host level in wrost case).

[roidelapluie]

I don't provide security advices for particular stacks unfortunately, but it looks like you'd need a CA and some automation. Note that our security policy is at https://prometheus.io/docs/operating/security/ and should answer some of your questions about what to expect and not expect from Prometheus wrt this topic.

[gillg]

I understand, each stacks are different, and Prometheus follows good general guidelines with native cryptography libs to keep a good security and maintenability.

Maybe an alternative...
These certificates are loaded in memory during the start phase of the exporter. Am I wrong ?

Why not provide an option like :

tls_server_config:
  # Mutualy exclusive with cert_file and key_file
  cert_provider_command: "/path/to/command --output stdout --format pem"
  key_provider_command: "/path/to/command --output stdout --format pem"

This could handle all use cases, especialy with cloud providers. Even if you manage your own CA pki, you could automaticaly ask and challenge for a new certificate to your service. It can be compatible with Hashicorp Vault, LetsEncrypt, custom CA, Azure, AWS and so on...

[roidelapluie]

We do not have certificates in memory, they are read on every request. If you have a command, you just have to make it write the certs atomically on disk and it will work.

[gillg]

Ok, in this case it's a very simple workaround !
I note this solution to test it :)
Thanks to your vision