This issue was reported in the Kubernetes Security Audit Report

Description
The Kubernetes system allows users to set up Public Key Infrastructure (PKI), but often fails to authenticate connections using Transport Layer Security (TLS) between components, negating any benefit to using PKI. The current status of authenticated HTTPS calls are outlined in the following diagram.

This failure to authenticate components within the system is extremely dangerous and should be changed to use authenticated HTTPS by default. Systems Kubernetes can depend on, such as Etcd, have also been impacted by the absence of authenticated TLS connections.

Exploit Scenario
Eve gains access to Alice’s Kubernetes cluster and registers a new malicious kubelet with the kube-apiserver. Since the kube-apiserver is not using authenticated HTTPS to authenticate the kubelet, the malicious kubelet receives Pod specifications as if it were an authorized kubelet. Eve subsequently introspects the malicious kubelet-managed Pods for sensitive information.

Recommendation
Short term, authenticate all HTTPS connections within the system by default, and ensure that all components use the same Certificate Authority controlled by the kube-apiserver.

Long term, disable the ability for components to communicate over HTTP, and ensure that all components only communicate over secure and authenticated channels. Additionally, use mutual, or two-way, TLS for all connections. This will allow the system to use TLS for authentication of client credentials whenever possible, and ensure that all components are communicating with their expected targets at the expected security level.

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-034 and it was finding 3 of the report.

The vendor considers this issue High Severity.

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

Environment:

• Kubernetes version: 1.13.4