This issue was reported in the Kubernetes Security Audit Report

Description
Kubernetes can use DNS for service discovery. This allows both cluster components and containers alike to retrieve service and other information from a single source. However, CoreDNS does not distinguish between clients requesting information, allowing attackers to gain access to information outside of the current namespace.

root@wordpress-dccb8668f-mzg45:/var/www/html# nslookup -type=ns default.svc.cluster.local
;; Truncated, retrying in TCP mode.
Server:		10.233.0.3
Address:	10.233.0.3#53

cluster.local
	origin = ns.dns.cluster.local
	mail addr = hostmaster.cluster.local
	serial = 1555691051
	refresh = 7200
	retry = 1800
	expire = 86400
	minimum = 30
wordpress.default.svc.cluster.local	service = 0 100 80 wordpress.default.svc.cluster.local.
_http._tcp.wordpress.default.svc.cluster.local	service = 0 100 80 wordpress.default.svc.cluster.local.
kubernetes-dashboard.kube-system.svc.cluster.local	service = 0 100 443 kubernetes-dashboard.kube-system.svc.cluster.local.
...
_metrics._tcp.coredns.kube-system.svc.cluster.local	service = 0 100 9153 
...

Figure 28.1: An attacker querying name server (NS) records from a compromised container

Exploit Scenario
Alice has configured a cluster with multiple namespaces, so as to segment her containers across multiple units of her organization. Eve has access to a compromised container, and issues a name server query to CoreDNS in order to further map hosts and services for potential compromise.

Recommendation
Short term, document this behavior so that users and administrators are aware that CoreDNS may leak information in specific configurations.

Long term, work with CoreDNS to implement per-namespace DNS information, so as to minimize the leak of information across namespaces. This will allow administrators to denote which information is shared across environments, and prevent mistakes from cascading across namespaces or attackers from gaining access to information surrounding multiple namespaces across the cluster.

Anything else we need to know?:

See #81146 for current status of all issues created from these findings.

The vendor gave this issue an ID of TOB-K8S-032 and it was finding 29 of the report.

The vendor considers this issue Low Severity.

To view the original finding, begin on page 73 of the Kubernetes Security Review Report

Environment:

• Kubernetes version: 1.13.4