Add optional TLS support to /metrics endpoint
1. Why is this pull request needed?
It adds optional TLS support to the CoreDNS metrics endpoint, allowing metrics to be served over HTTPS. This improves security by encrypting metrics traffic. TLS is disabled by default, so existing configurations continue to work.
2. Related issues
#7109
3. Documentation changes
- Update metrics plugin docs to include TLS settings and examples
- Add instructions for providing certificates and configuring Prometheus to scrape over HTTPS
- Add troubleshooting notes
4. Backward compatibility
No breaking changes. TLS is optional and off by default.
@chrisohaver @SuperQ Would you have time to review? :)
@chrisohaver @SuperQ can you please take a look on this PR? It would be nice to have this PR moving forward
Codecov Report
:x: Patch coverage is 60.46512% with 17 lines in your changes missing coverage. Please review.
:white_check_mark: Project coverage is 63.19%. Comparing base (93c57b6) to head (8c5515c).
:warning: Report is 1706 commits behind head on master.
| Files with missing lines | Patch % | Lines |
|---|---|---|
| plugin/metrics/setup.go | 0.00% | 11 Missing and 1 partial :warning: |
| plugin/metrics/metrics.go | 83.87% | 4 Missing and 1 partial :warning: |
Additional details and impacted files
@@ Coverage Diff @@
## master #7255 +/- ##
==========================================
+ Coverage 55.70% 63.19% +7.49%
==========================================
Files 224 278 +54
Lines 10016 15129 +5113
==========================================
+ Hits 5579 9561 +3982
- Misses 3978 4879 +901
- Partials 459 689 +230
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
It would be really nice to have someone review this and start the discussion rolling
It would be helpful if someone could take a look at this.
@jameshartig @miekg @superq @greenpau @Tantalor93 Can I get a review on this? What are the next steps needed to get this merged?
I consider TLS on metric endpoints to be an anti feature
I consider TLS on metric endpoints to be an anti feature
I understand the desire to minimise complexity—especially on internal metrics endpoints—but in a zero-trust architecture, all network traffic, regardless of source or function, must be both authenticated and encrypted.
Tampering with metrics may seem low-impact, but it can lead to unpredictable or harmful behavior. For example:
- It can reveal service topology and workload characteristics.
- It can trigger alerts or automated remediation based on falsified data.
In multi-tenant or regulated environments where the network is not implicitly trusted, TLS is not an anti-feature—it’s a baseline security control. Even when the content isn’t sensitive, preserving integrity and controlling access are essential.
To be clear, the PR does not propose mandatory TLS—it introduces optional support, as indicated in the title: “Add optional TLS support to /metrics endpoint”. Rejecting TLS outright disregards the realities of deployment models built on zero-trust principles.
I've simplified this TLS implementation quite a bit. It's still using the Prometheus exporter-toolkit but now in the intended way. There is no more creating any temp files (this was the concern brought up in this comment: https://github.com/coredns/coredns/pull/7255#discussion_r2073357522).
@jameshartig @miekg @SuperQ @greenpau @Tantalor93 Can I get a review on this? What are the next steps needed to get this merged?
@johnbelamaric would you please take a look at this one?
@SuperQ any additional feedback on the updated PR?