You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
(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.
The text was updated successfully, but these errors were encountered:
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:
common/config/http_config.go
Lines 819 to 823 in 2f04d2e
(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.The text was updated successfully, but these errors were encountered: