Kubernetes Open-Sourced Their Security Audit: What Can We Learn?

This article is based on the CNCF’s August 2019 Kubernetes security audit announcement and analysis originally published on snyk.io.

Background: Why the CNCF Commissioned a Kubernetes Security Audit

On 6 August 2019, the Cloud Native Computing Foundation (CNCF) published a blog post detailing the results of a formal, third-party security audit of Kubernetes — the foundation’s flagship project and the most widely adopted open-source container orchestration platform. The CNCF had previously piloted its security audit programme with three smaller projects: CoreDNS, Envoy, and Prometheus. Following the success of that pilot, the programme was extended to Kubernetes itself.

Making the full audit findings publicly available — rather than sharing them only with maintainers — was a significant decision. It reflects a commitment to transparency and sets a concrete example for how large open-source communities can handle security at scale.

What the Audit Covered: Scope and Methodology

The auditors examined Kubernetes across five security control families:

• Networking — traffic flows, network policy enforcement, and exposure of internal APIs
• Cryptography — cipher suite choices, certificate management, and transport-layer security
• Authentication and Authorization — RBAC configuration, admission control, and identity verification
• Secrets Management — how sensitive data such as credentials and tokens is stored and accessed
• Multi-tenancy Isolation — namespace boundaries, workload separation, and privilege escalation paths

Given the sheer size and complexity of the Kubernetes codebase, the audit deliberately favoured breadth over depth. The goal was to produce a holistic security health assessment across all five areas, rather than exhaustively audit a single subsystem. Short-term and long-term remediation goals were recommended for each control category.

The Five High-Severity Findings

The audit identified five findings rated as high severity. Each touches a fundamental security concern:

• Access control bypass of PodSecurityPolicy — An attacker or misconfigured workload could circumvent the policies intended to restrict pod behaviour.
• No mechanism for certificate revocation — Kubernetes did not provide a built-in way to revoke TLS certificates, meaning compromised credentials could remain valid indefinitely.
• Unauthenticated HTTPS connections — Certain HTTPS endpoints did not enforce mutual authentication, leaving them open to impersonation or interception.
• Time-of-check/time-of-use (TOCTOU) race condition with PID handling — A race condition in process ID management could be exploited to interfere with workload scheduling or isolation.
• Improperly patched directory traversal in kubectl cp — A previously reported path traversal vulnerability in the kubectl cp command had not been fully remediated, potentially allowing a malicious container to overwrite arbitrary files on the host.

Beyond these five high-severity issues, the report also surfaced a range of lower-severity recommendations: cleaning up technical debt in the codebase, expanding test coverage, improving documentation, and hardening insecure defaults. These housekeeping recommendations are often the unglamorous but essential work that makes future vulnerability patching faster and safer.

Breadth vs. Depth: The Right Approach for a Project of This Scale

A common critique of broad security audits is that they trade depth for coverage. For a project as large and multifaceted as Kubernetes, however, the breadth-first approach makes practical sense. A targeted deep-dive into a single component — say, the API server’s authentication logic — would yield detailed findings for that subsystem while leaving the rest of the attack surface unexamined.

The holistic view produced by this audit is more useful for prioritisation. Maintainers and the CNCF security SIG can now see where the overall security posture is weakest, allocate resources accordingly, and commission follow-on deep-dive audits of the areas that warrant them. Think of it as a general health check that identifies which specialist referrals to make next.

Benefits for Maintainers: Proactive vs. Reactive Security

One of the most important takeaways from this audit is the value of finding your own vulnerabilities before others do. When a security flaw is discovered and disclosed by an external researcher or, worse, exploited in the wild, maintainers are forced into crisis mode: patches must ship under time pressure, communications must be carefully managed, and users are left exposed in the interim.

A planned security audit changes that dynamic entirely. Maintainers know about the findings in advance. Fixes can be prioritised thoughtfully against other roadmap commitments. Coordinated disclosure timelines can be agreed upon. The result is a more orderly and effective remediation process — and a lower risk of security incidents affecting end users.

Benefits for the Community: Transparency Builds Trust

By open-sourcing the full audit findings — including the white paper and threat model — the CNCF gave the wider Kubernetes community something valuable: the ability to make informed decisions. Organisations running Kubernetes in production can review the findings, assess their own exposure to the identified issues, and take compensating controls where necessary while waiting for upstream fixes.

This transparency also delivers a second benefit: it signals that the project takes security seriously as a first-class concern, not an afterthought. For enterprise adopters evaluating Kubernetes against competing platforms, a published, third-party security audit is meaningful evidence of security maturity.

Finally, the audit artefacts — particularly the threat model — are useful educational resources for anyone looking to deepen their understanding of Kubernetes internals or cloud-native security concepts more broadly.

Key Lessons for Other Open-Source Projects

The Kubernetes security audit offers a replicable model that other open-source projects — especially those handling sensitive workloads or infrastructure — should consider adopting:

1. Commission third-party audits proactively. Internal code review, however thorough, cannot fully replicate the perspective of an independent security team with no prior assumptions about the codebase.
2. Scope audits across control families, not just individual components. A cross-cutting assessment reveals systemic weaknesses that component-level reviews miss.
3. Publish the findings. Open-sourcing the results — not just the patches — builds community trust and accelerates collective learning.
4. Pair findings with actionable goals. Short-term and long-term remediation targets give maintainers and contributors a clear roadmap rather than an undifferentiated list of problems.
5. Treat the threat model as a living document. A threat model produced during an audit is a starting point, not a final answer. It should be updated as the project evolves.

Getting Involved: The CNCF Security SIG

If you want to follow the ongoing security work in the Kubernetes ecosystem, or contribute to future security audits, the CNCF maintains a Security Special Interest Group (SIG Security). The SIG coordinates security reviews, policy guidance, and disclosure processes across CNCF projects. Details on joining can be found through the official CNCF GitHub organisation and community pages.

Conclusion

The CNCF’s decision to commission, and then openly publish, a comprehensive security audit of Kubernetes was a landmark moment for cloud-native security. It demonstrated that even the largest and most complex open-source projects can take a structured, transparent, and proactive approach to security. The five high-severity findings identified in the audit serve as a reminder that no project — regardless of its maturity or community size — is immune to serious vulnerabilities. More importantly, the audit shows that the right response to that reality is not silence, but structured, open engagement with the security community.

For DevOps and platform engineering teams running Kubernetes, the practical takeaway is clear: review the published findings against your own cluster configurations, follow the upstream remediation progress, and consider commissioning your own security assessments for the internal platforms and tools your teams build and maintain.