prometheus / prometheus/common
Ability to configure SAN/CN validation for client certificates is missing
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 295
- Forks
- 367
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 18
Description
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:
https://github.com/prometheus/common/blob/2f04d2ec94b96df44aa4f8a60ae9fb29d8512636/config/http_config.go#L819-L823
(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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in the linked config/http_config.go section around lines 819-823 and read the Prometheus HTTPS configuration documentation. Trace how client certificate validation is configured, then determine where a dns_name_regex option and its matching behavior would belong. Done means authorized client certificate identities can be restricted by the configured pattern rather than accepting every certificate signed by the CA.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100