Kubernetes CVE-2020-8555: Fixing the kube-controller-manager Information Leak

This article is based on reporting originally published by devclass.com.

Overview: CVE-2020-8555 in kube-controller-manager

A medium-severity Server Side Request Forgery (SSRF) vulnerability, tracked as CVE-2020-8555, was disclosed in Kubernetes’ kube-controller-manager. Patches are available, and cluster operators should act promptly to update or apply mitigations.

The flaw enables a user who has permission to create certain storage-related resources to cause the controller manager to make HTTP requests to internal endpoints — and then leak a portion of the response back to the attacker.

What the Vulnerability Does

The vulnerability allows a user with sufficient Kubernetes RBAC permissions to exfiltrate up to 500 bytes of arbitrary data from endpoints that are reachable from the control-plane host’s network but are not otherwise exposed externally. Interceptable targets include:

• Link-local metadata endpoints (such as cloud provider instance metadata services)
• Unauthenticated services listening on localhost on the master node
• Other services located in the master node’s private network

The attack vector requires the adversary to create a pod that uses one of the affected volume plugins, or to create or modify a StorageClass. The affected volume plugins are:

• GlusterFS
• Quobyte
• StorageFS
• ScaleIO

Affected Kubernetes Versions

The vulnerability affects the following versions of kube-controller-manager:

• All versions older than 1.15.11
• 1.16.0 – 1.16.8
• 1.17.0 – 1.17.4
• 1.18.0

Clusters running versions outside these ranges with the relevant patches applied are not affected.

Risk Assessment

The practical risk of this vulnerability being exploited in a typical production environment is relatively low. The permissions required to create pods with the affected volume types or to write StorageClass resources are, under normal RBAC configurations, restricted to administrators or trusted developers. An external attacker would need to already have a meaningful foothold inside the cluster to leverage this flaw.

That said, the disclosure serves as a useful reminder to audit RBAC policies and ensure that only genuinely trusted users are granted pod creation and StorageClass write permissions. The principle of least privilege is your first line of defense.

Mitigation and Remediation

There are two complementary approaches to addressing CVE-2020-8555:

1. Update to a Patched Version

The most reliable fix is to upgrade kube-controller-manager to a version that includes the patch. Refer to your distribution’s release notes for the specific patched version.

2. Apply Policy-Based Mitigations

If an immediate upgrade is not feasible, you can reduce exposure through the following controls:

• PodSecurityPolicy (PSP): Define policies that restrict which volume types pods are allowed to use, blocking the affected plugins.
• OPA Gatekeeper: Use admission webhook policies to enforce restrictions on pod specs and StorageClass creation.
• RBAC hardening: Restrict create and update permissions on storageclasses and on pods that reference the affected volume types to only those users and service accounts that genuinely need them.

Impact on Specific Distributions

The impact of CVE-2020-8555 varies across Kubernetes distributions, and several vendors have published guidance:

D2iQ (Konvoy and MKE)

D2iQ updated both its Konvoy and MKE offerings and published a detailed upgrade guide for affected users.

Red Hat OpenShift

Red Hat confirmed that OpenShift Container Storage 4.2 is not affected, because the rook-ceph-operator container does not include support for the affected volume plugins.

For other Red Hat products, the assessed impact is low — either because the affected functionality is not used, or because not all of the vulnerable endpoints are exposed. However, Red Hat OpenShift Container Platform 4, Red Hat OpenShift Container Platform 3.11, and Red Hat Storage 3 were identified as affected and were expected to receive fixes.

Key Takeaways for DevOps and Platform Teams

• Patch promptly: upgrade kube-controller-manager to a fixed version as soon as your distribution makes one available.
• Audit RBAC: verify that pod creation and StorageClass write permissions follow the principle of least privilege.
• Use admission controls: PodSecurityPolicy or OPA Gatekeeper can block exploitation of this and similar SSRF vectors at the policy layer.
• Monitor control-plane network traffic: unexpected outbound requests from the master’s host network may indicate exploitation attempts.
• Check your distribution’s advisory: the impact and available fixes differ between managed Kubernetes offerings and self-managed clusters.