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

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

Speakers: Andong Chen

Conference: NDSS Symposium 2026

YouTube: https://www.youtube.com/watch?v=6AEcjT_QhnA

Overview

Kubernetes operators automate lifecycle management of complex applications, accepting user input through namespace-scoped custom resources and performing privileged operations on the cluster. This talk reveals a new class of vulnerabilities -- cross-namespace reference vulnerabilities -- where operators accept input from one namespace but perform operations affecting other namespaces, breaking Kubernetes' intended namespace isolation. A large-scale analysis of over 2,000 real-world operators found that over 14% are potentially vulnerable, enabling credential leakage, configuration theft, and cluster-level privilege escalation. Confirmations and CVEs were received from Google, Red Hat, NVIDIA, and Grafana -- including the original inventors of both Kubernetes (Google) and the operator pattern (Red Hat). The vulnerability stems from an insecure trade-off between convenience and security: operators implement cross-namespace resource sharing to help users, but this also helps attackers.

Background

▶ Watch: Kubernetes namespaces, RBAC, and the operator pattern (1:00)

Kubernetes uses namespaces as the primary logical isolation boundary and RBAC for access control. Resources within different namespaces are independent. Operators consist of Custom Resource Definitions (CRDs) that define input formats and controllers that watch for custom resources and perform operations. Namespace-scoped resources can be manipulated by regular users within their assigned namespaces. The threat model assumes a regular tenant with legitimate access to one namespace who seeks to break isolation -- realistic in multi-tenant clusters like Red Hat Developer Sandbox where different companies share a cluster.

Key Findings

▶ Watch: Threat model: malicious tenant in multi-tenant cluster (5:30)

Two attack tactics: (1) Insecure namespace-scoped resource reference -- attacker input controls references to resources in other namespaces (e.g., Google's Config Connector Oracle operator allowing database restore from backups in other namespaces, enabling data leakage/tampering). (2) Insecure cluster-scoped resource reference -- attacker input references cluster-scoped resources like ClusterRoleBindings, enabling cluster-level privilege escalation (e.g., Grafana Tempo operator).

14%+ of operators vulnerable: Static analysis of 2,000+ Go-based operators using interprocedural tracking identified that over 14% allow user-controllable input to feed into resources in other namespaces, affecting critical resources like Secrets, ConfigMaps, and ClusterRoleBindings.

Industry leaders affected: CVEs confirmed from Google, Red Hat, NVIDIA, and Grafana demonstrate the vulnerability class affects even the platform's original developers.

Technical Deep Dive

▶ Watch: Google Config Connector and Grafana Tempo operator vulnerabilities (7:30)

The measurement methodology crawls operators from GitHub (focusing on Go-based operators due to ecosystem dominance), extracts all involved resources and their declared scopes, performs interprocedural tracking to check if user-controllable input feeds into cross-namespace resource operations, and summarizes by resource type and API verb. The mitigation uses Kubernetes admission webhooks that intercept resources before cluster entry, checking whether the user is authorized in the referenced namespace. Implementation requires only tens of lines of code per case using scaffolding generated by Kubebuilder. Testing showed zero false positives.

Demo / Proof of Concept

▶ Watch: 14%+ of operators potentially vulnerable with CVEs from major vendors (10:30)

The Google Config Connector Oracle operator vulnerability allows a tenant to restore a database from another tenant's backups in a different namespace, enabling data leakage and tampering. The Grafana Tempo operator vulnerability allows a tenant to reference ClusterRoleBindings, obtaining cluster-level permissions. Both were confirmed by the respective vendors. Grafana has adopted the webhook-based mitigation approach.

Defensive Implications

▶ Watch: Admission webhook mitigation with zero false positives (11:30)

For Kubernetes platform operators, all deployed operators should be audited for cross-namespace reference vulnerabilities. The admission webhook mitigation is lightweight and can be deployed without modifying existing operator code. For operator developers, namespace-scoped CRD inputs should never directly reference resources in other namespaces without explicit authorization checks. For multi-tenant cluster administrators, the finding that 14%+ of operators are vulnerable means that deploying third-party operators in multi-tenant clusters introduces significant isolation risk.

Key Takeaways

• Over 14% of Kubernetes operators allow cross-namespace resource references that break namespace isolation
• Two tactics: insecure namespace-scoped and cluster-scoped resource references
• CVEs from Google, Red Hat, NVIDIA, and Grafana confirm industry-wide impact
• Root cause: operators implement convenient cross-namespace sharing that also enables attacks
• Admission webhook mitigation requires no modification to existing operator code
• Multi-tenant Kubernetes clusters are particularly at risk from third-party operators

About the Speaker(s)

Andong Chen is a researcher at Zhejiang University conducting the first systematic study of operator-specific vulnerabilities in the Kubernetes ecosystem. The research combines static analysis at scale with responsible disclosure to major cloud infrastructure vendors.