This article is based on reporting originally published by SDxCentral (August 2019) covering the first CNCF-commissioned security audit of Kubernetes.
Background: Why a Security Audit?
In mid-2019, the Cloud Native Computing Foundation (CNCF) released the results of the first independent security audit ever conducted on Kubernetes. The audit was carried out by security firms Trail of Bits and Atredis Partners, and focused on eight components within the Kubernetes ecosystem. The findings were significant: the review of Kubernetes 1.13.4 surfaced 37 vulnerability issues, including five rated high-severity and 17 rated medium-severity. According to the reporting, fixes for those issues had already been deployed by the time the audit was made public.
The audit was not a reaction to a single incident. Rather, it reflected an accumulation of concern: in the roughly eight months before the audit’s publication, a series of Kubernetes security flaws had been publicly disclosed, including one late in 2018 that received a score of 9.8 (Critical) on the Common Vulnerability Scoring System (CVSS).
What the Audit Found
The audit identified several systemic, Kubernetes-wide issues that went beyond individual CVEs. These included:
- Policies that may not be applied: Certain security policies could give administrators a false sense of security without actually being enforced.
- Insecure TLS defaults: Transport Layer Security (TLS) configurations that were not secure out of the box.
- Credential exposure: Credentials being exposed in insecure environments.
- Secret name leakage in logs: Names of Kubernetes Secrets being written to log output.
- Lack of certificate revocation: No built-in mechanism to revoke certificates.
- seccomp not enabled by default: The Linux kernel feature that restricts a process’s system calls (seccomp) was not activated in default configurations.
The audit attributed much of this to the inherent size and complexity of the Kubernetes project. As the auditors wrote:
“The assessment team found configuration and deployment of Kubernetes to be non-trivial, with certain components having confusing default settings, missing operational controls, and implicitly defined security controls.”
The codebase complexity was also highlighted as a barrier to good security hygiene:
“The codebase is large and complex, with large sections of code containing minimal documentation and numerous dependencies, including systems external to Kubernetes. There are many cases of logic re-implementation within the codebase, which could be centralized into supporting libraries to reduce complexity, facilitate easier patching, and reduce the burden of documentation across disparate areas of the codebase.”
What the Audit Got Right
The audit was not purely critical. It acknowledged that Kubernetes does meaningfully simplify difficult cluster operations—including deployments, replication, and storage management—and that role-based access control (RBAC) already gives operators a mechanism to enforce a stronger security posture. The auditors noted:
“Continued development of these security features and further refinement of best practices and sane defaults will lead the Kubernetes project towards a secure-by-default configuration.”
Recommendations for Administrators and Developers
The audit included concrete recommendations split by audience:
For Cluster Administrators
- Focus on attribute-based access control (ABAC) where appropriate, rather than relying solely on RBAC.
- Follow RBAC best practices rigorously.
- Carefully evaluate default settings and the security implications of backwards compatibility choices.
For Developers
- Avoid hardcoding paths to dependencies.
- Check and validate file permissions.
- Monitor processes at the Linux kernel level.
Part of the Process: CNCF’s Broader Security Posture
CNCF CTO Chris Aniszczyk framed the audit as a required, healthy step in the maturation of open source projects. He noted that CNCF now requires all graduating projects to go through a security audit, though that policy was still in a pilot phase when Kubernetes first graduated. He emphasized that the speed with which the community—across multiple vendors—developed fixes was a positive signal, not just the existence of the vulnerabilities themselves.
Aniszczyk drew a clear boundary around CNCF’s role, however:
“It’s not necessarily the role of the community to ship out all of the latest security fixes, that’s really the role of the member companies to do. But we do want to provide the knobs to make that easier.”
He also disclosed that CNCF had established a new security group tasked with driving audit recommendations back into CNCF-hosted projects, and that the foundation was evaluating a bug bounty program—an increasingly common tool for surfacing security issues in widely deployed open source software.
Rani Osnat, VP of product marketing at Aqua Security, put the audit in perspective in comments reported by SDxCentral:
“Software that’s as complex and as extensive as Kubernetes is bound to have vulnerabilities. Taking the initiative to perform an extensive third-party security audit … is absolutely the right thing to do in order to get ahead of having those vulnerabilities exposed ‘in the wild.'”
Context: Kubernetes Bugs at the Time
The audit landed against a backdrop of notable Kubernetes CVEs. The most prominent at the time was a critical vulnerability disclosed in late 2018 that scored 9.8 on the CVSS scale—near the maximum possible score. Several additional flaws were disclosed in the months that followed.
Wei Lien Dang, co-founder and head of product at security firm StackRox, argued that the audit’s real value extended beyond the specific vulnerabilities it identified:
“While many observers will emphasize the number and severity of vulnerabilities that were reported, that focus misses the forest for the trees. This audit provides value far more broad and critical than identifying additional vulnerabilities. Such vulnerabilities will keep surfacing – with or without this audit, given the combination of the rich code base with such broad, rapid adoption.”
Key Takeaways for DevOps Teams
- Default configurations are not secure configurations. Kubernetes’ defaults were designed for ease of adoption, not hardened security. Always audit your cluster configuration against published CIS Benchmarks or similar guidance.
- RBAC is necessary but not sufficient. The audit highlighted that RBAC alone does not close all access-control gaps. Understand what it does and does not enforce in your environment.
- Log hygiene matters. Secret names appearing in logs is a real operational risk. Audit your logging pipeline for sensitive data.
- seccomp should be explicitly enabled. It is not on by default; enabling it reduces the kernel attack surface for container workloads.
- Third-party audits are a sign of project maturity. The willingness to publish findings transparently—including unflattering ones—is a meaningful signal when evaluating the trustworthiness of an open source platform.