Bug 2129668

Summary:	openshift: kube-apiserver root certificate authority bundle contains more certificates than expected
Product:	[Other] Security Response	Reporter:	Sam Fowler <sfowler>
Component:	vulnerability	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	jburrell, joelsmith, vkumar
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2127784

Description Sam Fowler 2022-09-26 02:04:57 UTC

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.

Comment 1 Sam Fowler 2022-09-26 02:09:43 UTC

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.