This article is based on a summary originally published at helpnetsecurity.com, covering the Kubernetes Security Audit Working Group’s findings published in 2019.
Why Kubernetes Needed a Formal Security Audit
Kubernetes has grown into the de facto standard for container orchestration, underpinning production workloads at organizations of every size and sector. Yet despite its widespread adoption, the project had never undergone a structured, independent security audit at scale. With backing from the Cloud Native Computing Foundation (CNCF), the Kubernetes project leadership established the Security Audit Working Group to change that.
The scope was significant: roughly 1.5 million lines of code. The group included participants from Google, Red Hat, and Salesforce, as well as the broader security research community, and engaged two specialist firms — Atredis Partners and Trail of Bits — to carry out the technical work.
Audit Goals and Deliverables
The working group recognized from the outset that no single engagement could comprehensively cover a codebase of this size. Rather than attempting exhaustive coverage, the team prioritized work that would raise the baseline for all future security efforts — whether by subsequent auditors, independent researchers, or the Kubernetes development community itself.
The audit produced a defined set of artifacts intended to serve multiple audiences:
- Two Security White Papers — high-level guidance for cluster operators and developers on securing Kubernetes deployments.
- A Threat Model — a structured analysis of attacker goals, trust boundaries, and attack surfaces within Kubernetes.
- A Security Review Report — detailed technical findings produced by Atredis Partners and Trail of Bits.
- A published Request for Proposal (RFP) — documenting the vendor selection process for transparency and to guide future initiatives.
Publishing the RFP and vendor selection criteria was a deliberate choice. The working group wanted the process itself to be repeatable and open, not just the findings.
What the Audit Found: 37 Findings, Five High Severity
The research produced 37 findings spanning a wide range of security control categories. Of these, five were rated high severity. All findings were formally reported to the Kubernetes Product Security Committee and remediation work began immediately following disclosure.
The findings covered a broad spectrum, including:
- Authentication and authorization weaknesses — issues affecting how identities are verified and permissions enforced.
- Pod Security Policy bypass vectors — vulnerabilities allowing circumvention of critical workload isolation controls.
- Cryptography concerns — including support for older, less secure TLS cipher suites.
- Timing attacks — subtle vulnerabilities exploitable through observable timing differences in cryptographic or comparison operations.
Beyond the 37 enumerated findings, the audit generated 241 pages of supporting material, including detailed recommendations, threat models, reference architectures, and prioritized areas for future security research.
No Fundamental Architectural Flaws Found
One of the most important conclusions for operators and security teams evaluating Kubernetes for sensitive workloads: the audit did not uncover fundamental architectural design flaws or critical vulnerabilities that would warrant pausing adoption for high-security or business-critical environments.
This is meaningful context for enterprises conducting their own risk assessments. The findings represent real issues that warranted fixing, but Kubernetes’s core architecture was not found to be structurally unsound from a security perspective. Kubernetes security was maturing — and this audit formalized and accelerated that process.
How the Audit Was Structured to Enable Future Work
A recurring theme in the working group’s approach was building infrastructure for future audits. By documenting the RFP process, publishing threat models, and releasing findings openly, the group created reusable artifacts that lower the cost and increase the quality of subsequent security reviews.
This mirrors best practices from mature software security programs in other ecosystems, where the first audit is often as much about establishing process as it is about finding bugs. Kubernetes, with its rapid development pace and large contributor base, particularly benefits from having a documented, repeatable security review process.
What This Means for Kubernetes Operators
For teams running Kubernetes in production, the audit offers several practical takeaways:
- Review the white papers — they translate technical audit findings into operational guidance for hardening clusters.
- Audit your TLS configuration — ensure your clusters are not negotiating deprecated or weak cipher suites.
- Evaluate your Pod Security Policy (or successor) implementation — the bypass findings underscore that PSP requires careful, correct configuration to be effective. Note that Pod Security Policy has since been deprecated in favor of Pod Security Admission and third-party policy engines.
- Track the Kubernetes Product Security Committee — future vulnerabilities will be disclosed and remediated through this channel.
- Use the threat model — even if you do not have resources for a full internal audit, the published threat model provides a structured framework for evaluating your own exposure.
A Foundation for Ongoing Security Research
The 2019 audit was explicitly framed as the first of many. The Security Audit Working Group committed to continuing its involvement with the Kubernetes project, using the knowledge gained to guide ongoing security improvements across the project, its distributions, and its user community.
For the open-source security community, this audit set a precedent: large, complex infrastructure projects can and should undergo rigorous, transparent, and publicly disclosed security reviews. The CNCF’s willingness to fund this work, and the working group’s commitment to publishing everything openly, raises the bar for the entire cloud-native ecosystem.
The full Security Review report, Threat Model, and White Papers were published by the Kubernetes Security Audit Working Group. Researchers from Atredis Partners and Trail of Bits are individually credited in each document.