Repository: kubernetes
Issue: NCC-E003660-F9W: Common Certificate Authority Possible for Client CA and Request
Labels: priority/backlog,sig/auth,help wanted,sig/security,needs-triage

### NCC-E003660-F9W: Common Certificate Authority Possible for Client CA and Request
Header CA
This issue was reported in the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Impact**
A misconfiguration of the API server could lead to a situation where privilege escalation for
any authenticated user to cluster admin is possible.

**Description**
The Kubernetes API server allows a certificate authority (CA) to be specified (using the `--
client-ca-file flag`) which will be used to verify client certificates under the familiar X.
509 client certificate authentication scheme6. Another CA can be specified (using `--
requestheader-client-ca-file`) that will be used to verify requests authenticated using
the request header scheme (described in the documentation as Authenticating Proxy). If
these two CAs are the same, and the `--requestheader-allowed-names` flag is not used to
specify particular certificate common names that are permitted for request header
authentication, it is possible for any holder of a client certificate from the shared CA to
trivially authenticate to the API server as any user, by using their certificate to authenticate
a request using the request header scheme. While it is not intended that these CAs be the
same, and common Kubernetes deployment methods do not configure the deployment in
this way, it is possible that administrators could be unaware of this pitfall.

The Kubernetes documentation does include some advice against sharing CAs, but is not
explicit about the potentially serious security impact of this specific case.

For an example, please see the original finding on page 18 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Recommendation**
The Kubernetes API server should reject any configuration where `--client-ca-file` and
`--requestheader-client-ca-file` are set to the same value, unless `--requestheaderallowed-
names` has been set to specific value(s).

It may also be advisable to update the Kubernetes documentation to be more explicit about
the specific risks of sharing certificate authorities. For example, using the same CA for X.
509 client certificates for etcd authentication would allow any authenticated user to
directly access etcd (although this scenario is considered less likely than sharing of the
client CA and request header CA).

**Component**
kube-apiserver


**Anything else we need to know?**
See umbrella issue [#118980](https://github.com/kubernetes/kubernetes/issues/118980) for current status of all issues created from these findings.
The vendor gave this issue an ID of NCC-E003660-F9W and it was finding 5 of the report under the kube-apiserver section.
The vendor considers this issue Medium Risk, High Impact, Low Exploitability
To view the original finding, begin on page 18 of the [Kubernetes 1.24 Security Audit Report](https://github.com/kubernetes/sig-security/blob/main/sig-security-external-audit/security-audit-2021-2022/findings/Kubernetes%20v1.24%20Final%20Report.pdf)

**Test Environment**
Kubernetes 1.24.3