In OpenShift, it was found that the certificate bundle used to verify the kube-apiserver contained more certificates than necessary, potentially allowing for scenarios where connections to the kube-apiserver or other routes will be trusted, when they should be rejected.
This is similar to a prior issue, CVE-2021-3636, which applied to the service-ca.crt, however this issue applies to the ca.crt, stored in the kube-root-ca.crt ConfigMap, which is injected into all namespaces and pods. Unlike CVE-2021-3636, most of the certificates in the ca.crt bundle are expected, most signing certificates in this bundle are expected, including: - kube-apiserver-lb-signer - kube-apiserver-localhost-signer - kube-apiserver-service-network-signer - kube-apiserver-operator-localhost-recovery-serving-signer These are used to trust connections to the kube-apiserver over several different endpoints (e.g. load balancer, localhost, service network, recovery). There are two signer certificates in the bundle that are not expected: - *.apps.** - ingress-operator Those two are used to trust routes served with our default router. By placing them in the same certificate bundle two possible security issues are possible: - if using ca.crt to verify the kube-apiserver, if the ingress operator or router certificate is used to sign any cert for any kube-apiserver hostname (internal LB, external LB, IP, kubernetes.default.service (or alias), then a serving cert for the kube-apiserver that should not be trusted will be silently trusted instead of rejected. - if using ca.crt to verify access to a route, if any of the kube-apiserver internal signers are used to sign a route name, then a serving cert for a route that should not be trusted will be silently trusted instead of rejected.