Original reporting by PortSwigger Web Security (portswigger.net). Original disclosure date: June 2020.
Overview
Two French security researchers earned bug bounties from both the Kubernetes project and Microsoft after uncovering a server-side request forgery (SSRF) vulnerability in Kubernetes’ dynamic volume provisioning subsystem. The flaw, tracked as CVE-2020-8555, affected versions of Kubernetes hosted on Microsoft Azure and potentially other managed Kubernetes services.
The researchers involved were Brice Augras of Groupe Asten and Christophe Hauquiert of Nokia. Their work began as preparation for a conference talk on Kubernetes security in managed service environments — a practical exercise that turned into a significant vulnerability disclosure.
The Vulnerability: CVE-2020-8555
CVE-2020-8555 is rooted in Kubernetes’ dynamic volume provisioning feature, specifically its in-core provisioning mechanism. Dynamic volume provisioning allows storage volumes to be created on-demand without manual intervention from cluster administrators — a convenience feature that, in this case, introduced a security risk.
The attack chain worked as follows:
- The researchers crafted a malicious
StorageClassobject that pointed the in-tree volume provisioner at an attacker-controlled or internal network endpoint. - By abusing the SSRF weakness in the provisioner, they caused the Kubernetes control plane to make HTTP requests to internal cloud infrastructure endpoints — such as instance metadata services.
- Responses from those internal endpoints were partially reflected back, allowing the researchers to extract internal credentials and escalate privileges within the cloud environment.
The researchers confirmed the technique allowed them to “escape” the customer environment on multiple cloud providers offering managed Kubernetes services, not just Azure.
“The root cause (in this case a server-side request forgery) helped us escape our customer environment on multiple providers offering [Kubernetes’] managed service.”
— Brice Augras and Christophe Hauquiert, technical blog post
What Is a Server-Side Request Forgery (SSRF) Attack?
An SSRF vulnerability allows an attacker to induce a server-side application to make HTTP requests to an arbitrary destination — including internal services that are not exposed to the public internet. In cloud environments, this is especially dangerous because cloud instance metadata endpoints (such as http://169.254.169.254 on AWS, GCP, and Azure) often return temporary credentials, configuration data, and other sensitive information with no additional authentication required from within the instance network.
When a Kubernetes control-plane component can be manipulated into making such requests, the blast radius extends beyond the cluster itself and into the underlying cloud infrastructure.
Disclosure Timeline
- December 2019: Vulnerability reported to Microsoft.
- January 2020: Vulnerability reported to the Kubernetes security team.
- March 2020 (planned): Public disclosure originally scheduled.
- Postponed: Disclosure delayed due to the COVID-19 pandemic.
- June 2020: Public disclosure and CVE published.
Bug bounties were awarded by both Microsoft and the Kubernetes project prior to public disclosure, reflecting the severity and real-world impact of the finding.
Impact and Scope
The vulnerability’s impact was particularly notable in managed Kubernetes environments (such as Azure Kubernetes Service), where tenants do not control the underlying infrastructure and typically assume strong isolation between customer workloads and cloud-provider internals. CVE-2020-8555 undermined that assumption by providing a pathway from a cluster tenant to cloud-provider internal services.
Practical consequences of exploitation included:
- Dumping internal credentials from cloud metadata services.
- Privilege escalation within the cloud environment.
- Potential lateral movement to other internal resources accessible from the control plane network.
Remediation and Recommendations
Patches for CVE-2020-8555 were released in Kubernetes. Administrators running self-managed clusters should ensure they are running a patched version. Users of managed services such as AKS, GKE, or EKS should verify with their cloud provider that mitigations have been applied to the control plane.
General hardening recommendations relevant to this class of vulnerability include:
- Restrict which
StorageClassprovisioners are permitted in your cluster using admission controllers or OPA/Gatekeeper policies. - Apply network policies to limit egress from control-plane components where possible.
- Use instance metadata service (IMDS) protections offered by cloud providers, such as enforcing IMDSv2 on AWS or equivalent controls on Azure and GCP.
- Follow the principle of least privilege for service accounts and node identities.
- Monitor Kubernetes audit logs for unexpected
StorageClasscreation or modification events.
Researcher Commentary
“This was a really crazy experience; we didn’t expect such great feedback from the community! Stay tuned for more content as we’re hardly working on managed service applications with an implementation similar to Kubernetes.”
— Brice Augras, speaking to The Daily Swig (PortSwigger)
The case is a useful reminder that security research conducted as preparation for conference talks can yield real-world impact — and that managed Kubernetes environments warrant the same rigorous adversarial scrutiny as any other cloud service boundary.