This issue was reported in the Kubernetes Security Audit Report

Description
Kubernetes uses Transport Layer Security (TLS) throughout the system to connect disparate components. These include kube-proxy, kubelets, and other core, fundamental components of a working cluster. However, Kubernetes does not verify TLS connections by default for certain connections, and portions of the codebase include the use of InsecureSkipVerify, which precludes verification of the presented certificate (Figure 11.1).

if dialer != nil {
	// We have a dialer; use it to open the connection, then
	// create a tls client using the connection.
	netConn, err := dialer(ctx, "tcp", dialAddr)
	if err != nil {
		return nil, err
	}
	if tlsConfig == nil {
		// tls.Client requires non-nil config
		klog.Warningf("using custom dialer with no TLSClientConfig. Defaulting to InsecureSkipVerify")
		// tls.Handshake() requires ServerName or InsecureSkipVerify
		tlsConfig = &tls.Config{
			InsecureSkipVerify: true,
		}
	// ...
}

Figure 11.1: An example of InsecureSkipVerify in kubernetes-1.13.4/staging/src/k8s.io/apimachinery/pkg/util/proxy/dial.go

Exploit Scenario
Alice configures a Kubernetes cluster for her organization. Eve, a malicious privileged attacker with sufficient position, launches a man-in-the-middle attack against the kube-apiserver, allowing her to view all of the secrets shared over the channel.

Recommendation
Short term, audit all locations within the codebase that use InsecureSkipVerify, and move towards a model that always has the correct information present for all TLS connections in the cluster.

Long term, default to verifying TLS certificates throughout the system, even in non-production configurations. There are few reasons to support insecure TLS configurations, even in development scenarios. It is better to default to secure configurations than to insecure ones that may be updated.

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

The vendor considers this issue Medium Severity.

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

Environment:

• Kubernetes version: 1.13.4