Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to configure SAN/CN validation for client certificates is missing #470

Open
Ten0 opened this issue Apr 2, 2023 · 0 comments
Open

Comments

@Ten0
Copy link

Ten0 commented Apr 2, 2023

Issue

Let's say I have a Prometheus server running, secured with TLS with a custom CA (that of my whole cluster).

Using the documentation at https://prometheus.io/docs/prometheus/latest/configuration/https/ I can specify that the server validates client certificates. However once that is configured, it will accept any certificate signed by the CA.

That is an issue because the safety levels of all the services that have certificates are not the same: some are more likely to be compromised than others.
And of course, it wouldn't be legitimate for some-random-maybe-compromised-service.example.com (even if we know it is that service thanks to the CA!) to access and export the Prometheus metrics.

Solving it

=> In order to avoid this, it should be possible not only to validate that the client certificate is signed by the CA, but that whoever it turns out to be thanks to that authentication is indeed authorized to connect to Prometheus.

Currently, the configuration does not seem to allow configuring that.

However, that also seems reasonably easy to enable:
It's just about adding the proper parameters here:

func NewTLSConfig(cfg *TLSConfig) (*tls.Config, error) {
tlsConfig := &tls.Config{
InsecureSkipVerify: cfg.InsecureSkipVerify,
MinVersion: uint16(cfg.MinVersion),
MaxVersion: uint16(cfg.MaxVersion),

(Note however that in the article it tries to validate based on some connection data, whereas we just want to validate based on e.g. a regexp).

Implementation notes

I think it would be good to validate that by providing a dns_name_regex in the TLS configuration parameters, as that is both simple and very flexible (users can specify sets of services, wildcards, prefix/suffix factoring..., all while keeping the prometheus side of things very simple). Kafka has done the same for their mTLS configuration, where you can specify which role you get depending on regex.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant