Breaking the Bulkhead: Demystifying Cross-Namespace Reference Vulnerabilities in Kubernetes Operators

Kubernetes Operators, automated tools designed to manage application lifecycles within Kubernetes clusters, extend the functionalities of Kubernetes, and reduce the operational burden on human engineers. While Operators significantly simplify DevOps workflows, they introduce new security risks. In particular, Kubernetes enforces namespace isolation to separate workloads and limit user access, ensuring that users can only interact with resources within their authorized namespaces. However, Kubernetes Operators often demand elevated privileges and may interact with resources across multiple namespaces. This introduces a new class of vulnerabilities, the Cross-Namespace Reference Vulnerability. The root cause lies in the mismatch between the declared scope of resources and the implemented scope of the Operator logic, resulting in Kubernetes being unable to properly isolate the namespace. Leveraging such vulnerability, an adversary with limited access to a single authorized namespace may exploit the Operator to perform operations affecting other unauthorized namespaces, causing Privilege Escalation and further impacts. To the best of our knowledge, this paper is the first to systematically investigate Kubernetes Operator attacks. We present Cross-Namespace Reference Vulnerability with two strategies, demonstrating how an attacker can bypass namespace isolation. Through large-scale measurements, we found that over 14% of Operators in the wild are potentially vulnerable. Our findings have been reported to the relevant developers, resulting in 8 confirmations and 7 CVEs by the time of submission, affecting vendors including Red Hat and NVIDIA, highlighting the critical need for enhanced security practices in Kubernetes Operators. To mitigate it, we open-source the static analysis suite and propose concrete mitigation to benefit the ecosystem.

💡 Research Summary

Kubernetes Operators have become essential for automating the lifecycle of complex cloud‑native applications, but their elevated privileges introduce a novel class of security flaws that have not been studied systematically before. This paper identifies and characterizes the “Cross‑Namespace Reference Vulnerability” (CNRV), which arises when the declared scope of a custom resource (CR) – typically namespace‑scoped – does not match the effective scope of the Operator’s controller logic, which may perform cluster‑scoped actions. Because Operators often run with broad RBAC permissions to manage resources across many namespaces, a mismatch allows an attacker who only has legitimate access to a single namespace to leverage the Operator as a privileged conduit and affect resources in other, unauthorized namespaces.

The authors formalize a realistic threat model: the adversary possesses a valid Kubernetes account or a compromised pod that is limited to a specific namespace and cannot directly invoke cluster‑wide APIs. By creating or modifying a malicious CR in their allowed namespace, the attacker can trigger the Operator’s controller to (1) read or modify resources in other namespaces (resource‑injection attack) or (2) create or alter ClusterRole/ClusterRoleBinding objects, effectively granting themselves cluster‑level privileges (privilege‑escalation attack). Both tactics exploit the same root cause – the Operator’s code calls cluster‑scoped APIs without proper validation of the originating CR’s namespace.

To assess the prevalence of CNRV, the researchers built a static analysis suite for Go‑based Operators. The tool parses the Operator’s source code, extracts CRD definitions, and performs data‑flow analysis to locate any paths from a namespace‑scoped CR to a cluster‑scoped Kubernetes API call (e.g., corev1.Secret, rbacv1.ClusterRole, etc.). The analyzer also flags missing namespace checks or hard‑coded references to “*” (all namespaces). Applying the suite to 2,268 Operators collected from OperatorHub, Helm charts, and public GitHub repositories, they discovered that 321 (≈14 %) contain at least one potentially exploitable scope‑mismatch.

Responsible disclosure resulted in eight confirmed vulnerabilities and seven CVEs (including high‑severity CVEs for Red Hat and NVIDIA Operators) by the time of submission, demonstrating real‑world impact. The paper’s contributions are fourfold: (1) definition of a new attack class specific to Operators, (2) two concrete exploitation strategies that do not require prior container compromise, (3) a large‑scale measurement showing widespread susceptibility, and (4) open‑source tooling plus concrete mitigation guidance.

Mitigation recommendations include: (a) designing CRDs with explicit scope verification and refusing to expose namespace‑scoped CRs to controllers that need cluster‑wide access; (b) applying the principle of least privilege by granting Operators only the minimal set of RBAC permissions required for their declared tasks; (c) inserting rigorous namespace checks in controller code before any cluster‑scoped API call; and (d) using the provided static analyzer and automated patch generator to retrofit existing Operators. The authors also propose a community‑driven best‑practice guide for Operator developers and suggest future work on dynamic detection, inter‑Operator interaction analysis, and integration with cloud‑provider policy engines. Overall, the study reveals that Kubernetes’ powerful namespace isolation can be subverted by subtle implementation bugs in Operators, underscoring the need for tighter security engineering in the rapidly expanding Operator ecosystem.