This issue was reported in the Kubernetes Security Audit Report

Description
The kube-apiserver includes multiple authentication backends for client request processing. These range in strength from client certificate authentication to simple HTTP Basic Authentication. When using a password (Basic Authentication), the kube-apiserver does not perform a secure comparison of secret values. In theory, this could allow an attacker to perform a timing attack on the comparison. For example, the AuthenticatePassword function simply performs string comparison to authenticate a user’s password (Figure 9.1).

func ( a* PasswordAuthenticator ) AuthenticatePassword ( ctx context . Context , username , password string ) (* authenticator . Response , bool , error ) {
	user, ok := a.users[username]
	if !ok {
		return nil , false , nil
	}
	if user.password != password {
		return nil , false , nil
	}
	return &authenticator.Response{User: user.info}, true , nil
}

Figure 9.1: Username and password authentication handling in passwordfile.go

Exploit Scenario
Alice runs a Kubernetes cluster in production. In order to support multiple organizational “customers,” she configures the cluster with HTTP Basic Authentication. Eve has a large number of username and password pairs for the organization, and uses the side-channel information from string comparison to tune her credential-stuffing attacks.

Recommendation
Short term, use a safe, constant-time comparison function such as crypto.subtle.ConstantTimeCompare. The comparison function should take the same amount of time regardless of matching prefix data within the password.

Long term, deprecate Basic Authentication in favor of more robust and secure options. Add documentation noting that any Basic Authentication is for use only in development scenarios, and not appropriate for production deployments. This will help users create a robust and secure default stance for all deployments.

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 ATR-K8S-002 and it was finding 18 of the report.

The vendor considers this issue Medium Severity.

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

Environment:

• Kubernetes version: 1.13.4

Fixed in v1.16.0 by #81152