The Cloud Native Computing Foundation (CNCF) has graduated Rook, an open source storage orchestrator for Kubernetes clusters, at a time when the number of stateful applications being built and deployed using containers is starting to increase.

Rook automates deployment, bootstrapping, configuration, provisioning, scaling, upgrading and migration of storage services on Kubernetes platforms in addition to enabling disaster recovery, monitoring and resource management.

Jared Watts, a Rook maintainer and founding engineer for Upbound, a provider of an open source platform for private clouds, says each storage service made is configured using Kubernetes Operator tools. Storage platforms supported by Rook include Ceph, EdgeFS, CockroachDB, Cassandra, NFS and Yugabyte DB.

In effect, Watts says Rook builds on much of the work the storage interest group (SIG) within the Technical Oversight Committee for Kubernetes has advanced to enable Kubernetes clusters to access various types of persistent storage.

Since becoming an incubating project within the CNCF in September 2018, the core Rook repository has seen its contributors grow to 279 from 90, a 260% growth rate. According to the CNCF, 184 distinct contributors have authored more than 1,140 pull requests over the last 12 months. A security audit was performed by the CNCF Security SIG in December that resulted in 13 findings ranging in severity from High to Low. The Rook maintainers have taken steps to address these issues, says Watts.

Organizations that have deployed Rook in production environments include the California Institute for Telecommunications and Information Technology, Cloudways, Finleap Connect, Geodata and RadioSound.

Interest in deploying stateful applications on Kubernetes clusters is on the rise in part because many organizations don’t want to rely on a separate team to manage storage externally. It’s more cost-effective to enable the same IT staff that manage the Kubernetes cluster to also manage all the storage resources attached to that cluster.

Historically, most of the container applications deployed on Kubernetes were stateless to the degree they typically stored data on a legacy database. However, as more databases are deployed on Kubernetes clusters, the number of stateful applications being deployed has increased. As the number and types of stateful applications increase, there is an increasing need to automate storage management tasks across fleets of Kubernetes clusters that may have very different storage services attached.

It’s not clear to what degree traditional storage vendors will embrace Rook. In the meantime, early adopters of stateful applications are moving ahead with an open source platform that enables them to manage a wide variety of heterogeneous storage services without worrying about becoming locked into a specific storage system.

Regardless of the path forward, the days when IT organizations paid a premium to store data are coming to an end. As storage software is disaggregated from hardware, it becomes easier for IT teams to replace industry-standard drives as see fit. It may take a while for storage administrators to appreciate that fact, but like it or not storage systems, just like every other IT infrastructure platform, is being turned into code.

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.