Skip to content

TOB-K8S-012: Use of InsecureIgnoreHostKey in SSH connections #81118

@cji

Description

@cji

This issue was reported in the Kubernetes Security Audit Report

Description
Kubernetes uses Secure Shell (SSH) to connect from masters to nodes under certain, deprecated, configuration settings. As part of this connection, masters must open an SSH connection using NewSSHTunnel, which in turn uses makeSSHTunnel. However, makeSSHTunnel configures the connection to skip verification of host keys. An attacker could man-in-the-middle or otherwise tamper with the keys on the node, without alerting the master. The code for makeSSHTunnel begins with:

func makeSSHTunnel(user string, signer ssh.Signer, host string) (*SSHTunnel, error) {
	config := ssh.ClientConfig{
		User:            user,
		Auth:            []ssh.AuthMethod{ssh.PublicKeys(signer)},
		HostKeyCallback: ssh.InsecureIgnoreHostKey(),
	}
      // (...)
}

Exploit Scenario
Alice’s cluster is configured to use SSH tunnels from control plane nodes to worker nodes. Eve, a malicious privileged user, has a position sufficient to man-in-the-middle connections from control plane nodes to worker nodes. Due to the use of InsecureIgnoreHostKey, Alice is never alerted to this situation. Sensitive cluster information is leaked to Eve.

Recommendation
Short term, document that this restriction is in place, and provide administrators with guidance surrounding SSH host auditing. This should support something similar to the Mozilla SSH Best Practices guidance.

Long term, decide if SSH tunnels will be deprecated. If they will be deprecated, remove support completely. If tunnels will not be deprecated, include a mechanism for nodes to report the SSH keys to the cluster, and always insist that the keys remain static. This may require a process to preload the trust-on-first-use (TOFU) mechanisms for SSH.

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

The vendor considers this issue Medium Severity.

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

Environment:

  • Kubernetes version: 1.13.4

Metadata

Metadata

Assignees

Labels

area/securitykind/bugCategorizes issue or PR as related to a bug.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.sig/api-machineryCategorizes an issue or PR as relevant to SIG API Machinery.wg/security-auditCategorizes an issue or PR as relevant to WG Security Audit.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions