Bug 1809197
Summary: | CoreDNS Metrics exposed over insecure channel | ||||||
---|---|---|---|---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Pawel Krupa <pkrupa> | ||||
Component: | Networking | Assignee: | Stephen Greene <sgreene> | ||||
Networking sub component: | DNS | QA Contact: | Hongan Li <hongli> | ||||
Status: | CLOSED ERRATA | Docs Contact: | |||||
Severity: | high | ||||||
Priority: | medium | CC: | aos-bugs, bbennett, mmasters, sgreene | ||||
Version: | 4.4 | Keywords: | Reopened | ||||
Target Milestone: | --- | ||||||
Target Release: | 4.5.0 | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: |
Cause: CoreDNS prometheus metrics integration was not set up properly.
Consequence: CoreDNS metrics were being exposed over an insecure channel within a cluster.
Fix: Add proper TLS components and a kube-rbac-proxy sidecar to secure the CoreDNS metrics endpoint.
Result: CoreDNS metrics are exposed over a secure channel.
|
Story Points: | --- | ||||
Clone Of: | Environment: | ||||||
Last Closed: | 2020-07-13 17:17:25 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Pawel Krupa
2020-03-02 15:00:53 UTC
https://github.com/openshift/cluster-dns-operator/blob/master/manifests/0000_90_dns-operator_02_servicemonitor.yaml Was this bug generated by some boilerplate process? It refers to "the component" and the reproducer steps seem totally non-specific to the DNS operator. Sorry for not clarifying. This is about openshift-dns/dns-default component. Yes, so am I — what exactly leads you to believe that metrics are served insecurely? The CoreDNS pods are exposing a TCP port 9153 serving a TLS endpoint secured by a serving signer service certificate which Prometheus is configured to use. Created attachment 1667246 [details]
prometheus scrape targets - dns section
Based on prometheus scrape targets page all DNS endpoints are scraped over HTTP and not HTTPS, which is an insecure channel. Screenshot from 4.3 cluster is attached in this BZ.
Thanks, I see my confusion now — I was looking at the dns operator and not coreDNS itself, which indeed looks misconfigured somehow despite TLS config present throughout the relevant resources. Going to move to 4.5 for now unless someone can justify the blocker status (given this has probably been an issue since 4.1). After fixing please remove your component from an exclusion list in e2e tests at https://github.com/openshift/origin/blob/master/test/extended/prometheus/prometheus.go#L253-L268 Verified with 4.5.0-0.nightly-2020-04-25-170442 and issue has been fixed. $ oc -n openshift-dns get pod -owide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dns-default-wp7p6 3/3 Running 0 111m 10.128.0.4 hongli-pl442-mld8x-master-1 <none> <none> <---snip---> Go to Prometheus UI and check the targets as below: https://10.128.0.4:9154/metrics > After fixing please remove your component from an exclusion list in e2e tests For the record, that was done with this PR: https://github.com/openshift/origin/pull/24904 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2020:2409 |