RBAC Atlas: Mapping Real-World Kubernetes Permissions and Exposing Risky Projects

RBAC Atlas: Mapping Real-World Kubernetes Permissions and Exposing Risky Projects

Speakers: Lenin Alevski

Conference: BSides SF

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

Overview

In the rapidly evolving landscape of cloud-native computing, Kubernetes has emerged as the de facto operating system of the cloud, orchestrating containerized applications with unparalleled scale and flexibility. However, this power comes with inherent complexity, particularly concerning its Role-Based Access Control (RBAC) system. Lenin Alevski's talk, "RBAC Atlas: Mapping Real-World Kubernetes Permissions and Exposing Risky Projects," delves into the critical security implications of misconfigured RBAC policies, which often create hidden security minefields within Kubernetes clusters.

Alevski, a seasoned security professional and avid cybersecurity enthusiast, highlights how the intricate nature of Kubernetes RBAC frequently leads to overly permissive configurations, even in widely adopted open-source projects. This talk introduces RBAC Atlas, a platform and associated tooling designed to automatically analyze and expose these dangerous misconfigurations. By demonstrating how a high-profile vulnerability in Ingress Nginx could be leveraged to compromise an entire cluster due to over-privileged RBAC, Alevski underscores the urgent need for better visibility and auditing of Kubernetes permissions.

The research presented in this talk is crucial for anyone involved in securing Kubernetes environments—from developers deploying applications to security engineers auditing infrastructure. It provides practical insights into common attack vectors, showcases a powerful methodology for identifying and mitigating RBAC risks, and offers open-source tools to empower defenders. Ultimately, RBAC Atlas aims to paint a clear picture of the cloud-native threat landscape, pushing the industry towards more secure and auditable RBAC practices.

Background

▶ Watch: Introduction, speaker, and talk agenda overview (0:00)

Kubernetes, often dubbed the "operating system of the world," is a container orchestrator that allows organizations to declaratively manage and deploy applications across diverse environments—development, testing, pre-production, and production—without direct concern for underlying hardware. At its core, Kubernetes abstracts infrastructure, allowing users to define desired states via YAML manifests for services, deployments, and container images. These configurations are then translated into running components: services exposed to the outside world, backed by nodes (physical or bare metal machines), which host pods, each containing one or more containers. This layered architecture, while powerful, inherently expands the attack surface.

The Kubernetes architecture can be broadly divided into control plane components and node components. The control plane nodes are the most privileged, hosting critical processes like the kube-API server (the primary interface for interacting with the cluster), etcd (a distributed key-value store maintaining the cluster's state), the scheduler (assigns pods to nodes), and the controller manager (ensures the cluster's desired state is met). Node components, in contrast, run the actual application workloads and include processes such as the kubelet (an agent that runs on each node and communicates with the control plane), kube-proxy (maintains network rules), and a container runtime (like containerd or CRI-O).

From a red teamer's perspective, the threat model in Kubernetes is clear:

• Compromising a Container/Pod: Grants access to application source code, configurations, environment variables, and enables lateral movement to other services or pods. Attackers can also target the kubelet, which in older versions lacked authentication and exposed inventory information about running containers.
• Compromising a Worker Node: Allows control over all containers on that node and facilitates privilege escalation or lateral movement to more privileged control plane nodes.
• Compromising the Control Plane: This is "game over." Access to control plane components, especially etcd (if unencrypted), can bypass all Kubernetes authentication and authorization mechanisms by directly accessing cluster state data.

To understand and defend against these threats, Alevski recommends resources like the OWASP Top 10 for Kubernetes (2022) and the MITRE ATT&CK Matrix for Kubernetes. These frameworks detail common attack techniques, from initial access to execution, persistence, and privilege escalation within a cloud-native context.

Common attack techniques observed in Kubernetes environments include:

• kubectl exec: If an attacker gains credentials to the API server, they can use kubectl exec to run commands inside any container, effectively "living off the land."
• Credential Reuse: Compromised pods often contain credentials that can be reused for lateral movement to other services or to obtain cloud provider identities via metadata services (e.g., AWS EC2 metadata service, GCP metadata server).
• Unauthenticated Dashboards: Many Kubernetes dashboards or internal applications are deployed without proper authentication, providing attackers with direct access to cluster management.
• Lateral Movement Across Clouds: Companies often deploy clusters across multiple cloud providers, creating opportunities for attackers to jump between environments if credentials or identities are compromised.
• Host File System Access: Attackers with node access can directly inspect container file systems mounted at well-known paths, bypassing individual container access.

A particularly potent attack vector involves deploying a privileged container. A canonical command often circulated in the Kubernetes community, kubectl run --rm -it pwn --image=alpine --privileged --hostpid --host-ipc --host-network --mount type=bind,source=/,target=/host -- /bin/chroot /host /bin/bash, illustrates this. This command deploys a container with extensive privileges: it shares the host's PID, network, and IPC namespaces, and mounts the host's root file system (/) into the container at /host. This effectively grants the attacker a root shell on the underlying node. Such an attack is possible if the attacker possesses a sufficiently powerful credential, such as a cluster-admin role or a similarly over-privileged Service Account.

This brings us to the core problem: Kubernetes RBAC. RBAC defines who (users, groups, service accounts) can do what (verbs like get, create, delete) on which resources (pods, config maps, secrets). While incredibly flexible and granular, its complexity often leads to misconfigurations. Developers, seeking ease of deployment, frequently grant overly broad permissions, creating a "hidden security minefield" where a compromise of one application can lead to a full cluster takeover.

The motivation for Alevski's research was heavily influenced by a high-profile vulnerability discovered by Wiz researchers (CVE-2021-25742) in Ingress Nginx. This vulnerability, with a CVSS score of 9.8, allowed an unauthenticated attacker to read any sensitive secret within a cluster running the vulnerable Ingress Nginx controller. The exploit involved a sophisticated race condition: Nginx writes large HTTP request bodies to temporary files, and a separate unauthenticated endpoint allowed writing configuration directly to Nginx. By simultaneously submitting a malicious payload (e.g., a reverse shell shared object) and brute-forcing process IDs (PIDs) and file descriptors (FDs), an attacker could inject their code into the running Nginx process. The critical issue was that Ingress Nginx, by default, often runs with a highly privileged ClusterRole that grants list and watch permissions on secrets, config maps, endpoints, nodes, and pods across all namespaces. This meant an RCE on Ingress Nginx immediately translated into full secret exfiltration and a pathway to cluster compromise. This demonstrated the devastating impact of combining an application vulnerability with over-privileged RBAC.

Key Findings

▶ Watch: Kubernetes architecture: Services, nodes, pods, containers (2:40)

Lenin Alevski's research and the development of RBAC Atlas yielded several crucial findings regarding Kubernetes security:

• RBAC Misconfiguration is a Leading Cause of Vulnerabilities: The inherent complexity of Kubernetes RBAC makes it challenging to configure correctly, leading to widespread misconfigurations that are a primary source of security weaknesses in cloud-native environments.
• Prevalence of Overly Permissive RBAC in Open-Source Projects: A significant number of popular open-source Kubernetes projects ship with default RBAC policies that grant excessive permissions, often without undergoing proper security assessments. This creates a large attack surface for many deployed clusters.
• Automated Detection is Possible and Necessary: The RBAC Scope tool successfully automates the detection of dangerous RBAC patterns and misconfigurations by analyzing Kubernetes YAML artifacts offline, demonstrating the feasibility and importance of shifting security left.
• Successful Replication of High-Profile Vulnerabilities: Alevski's ability to replicate the Ingress Nginx vulnerability (CVE-2021-25742) and build a functional exploit from public research highlights how even complex attack chains can be realized when RBAC is misconfigured.
• Identified Top RBAC Misconfiguration Patterns: Through extensive scanning, RBAC Atlas identified common risky patterns, with the top five frequently detected misconfigurations being related to information disclosure and data exposure.
• Quantified Cloud-Native Threat Landscape: RBAC Atlas currently tracks over 257 projects across 108 repositories, having scanned more than 25,000 artifacts over six months. This provides a data-driven overview of the security posture of the cloud-native ecosystem.
• Average Project RBAC Profile: The analysis revealed that the average tracked project involves approximately two service accounts, 30 bindings, and three workloads, indicating the scale of RBAC definitions within typical deployments.
• Risk Categorization Methodology: A clear classification system for RBAC risk was established: Critical for any use of on API groups, resources, or verbs; Medium for scoped permissions; and so on. This provides a standardized way to assess the severity of misconfigurations.
• Open-Source Contribution to Security: The entire RBAC Atlas platform and its components are open-source, fostering community collaboration in identifying and addressing RBAC security issues.

Technical Deep Dive

▶ Watch: Kubernetes threat model: Attacker's perspective (4:25)

Kubernetes' power lies in its ability to orchestrate complex applications. A typical deployment involves a service (the external access point), which routes traffic to deployments that manage multiple pods. Each pod contains one or more containers, running on nodes. The control plane (kube-API server, etcd, scheduler, controller) manages the cluster state, while node components (kubelet, kube-proxy, container runtime) execute workloads. This distributed nature means many components interact, requiring a robust authorization system.

That system is Role-Based Access Control (RBAC). RBAC is fundamental to Kubernetes security, defining granular permissions using three core concepts:

1. Who: The entity making the request, which can be a user, a group, or, most commonly in Kubernetes, a Service Account (an identity for processes running in pods).
2. What: The resource being accessed, such as a pod, configmap, secret, deployment, or node. These resources belong to specific apiGroups.
3. How: The action or "verb" being performed, like get, list, watch, create, update, delete, or exec.

RBAC policies are defined through Roles (scoped to a namespace) or ClusterRoles (cluster-scoped), which specify permissible verbs on resources. These roles are then bound to users, groups, or Service Accounts via RoleBindings or ClusterRoleBindings. The flexibility of this system is its strength, allowing fine-grained control; however, this same flexibility leads to its complexity and frequent misconfigurations.

A prime example of RBAC misconfiguration's impact is the Ingress Nginx vulnerability (CVE-2021-25742). Alevski detailed the two-step exploit:

1. Payload Delivery: When a large HTTP request (over 8 kilobytes) is sent to Nginx, it writes the request body to a temporary file on the file system. The exact path of this temporary file is initially unknown to the attacker.
2. Configuration Injection and Race Condition: The vulnerability lies in a second, unauthenticated endpoint that allows an attacker to write configuration directly to Nginx. The exploit leverages a race condition: while the malicious payload (e.g., a reverse shell shared object .so file) is being written to a temporary file, the attacker simultaneously brute-forces possible process IDs (PIDs) of the Nginx process and file descriptors (FDs) associated with open files. If the attacker successfully guesses the correct PID and FD for the temporary file, they can trick Nginx into loading the partially written malicious shared object as a legitimate configuration module. This results in Remote Code Execution (RCE) within the Ingress Nginx container.

The critical consequence of this RCE stems from Ingress Nginx's default RBAC permissions. It typically runs with a ClusterRole that grants list and watch permissions on sensitive resources like configmaps, endpoints, nodes, pods, and most importantly, secrets across all namespaces. An attacker gaining RCE can then use this powerful identity to exfiltrate all secrets from the entire cluster, including TLS certificates and application credentials.

Alevski then introduced his solution, RBAC Scope, a CLI tool designed as a policy analyzer. This tool can be pointed at any Kubernetes YAML artifact (e.g., Helm charts, raw manifests) and statically analyzes its RBAC definitions against a growing set of over 110 predefined rules. For instance, RBAC Scope can immediately identify if a service account is bound to a ClusterRole that permits list and watch verbs on secrets across all apiGroups—precisely the misconfiguration that amplified the Ingress Nginx vulnerability. The rules are "by coded," meaning Alevski custom-writes them to detect specific toxic combinations of permissions, including those related to recently discovered vulnerabilities like remote code execution on node-proxy.

Building on RBAC Scope, Alevski developed RBAC Atlas, an automated platform. RBAC Atlas takes a curated list of popular Kubernetes projects (sourced from Operator Hub and Artifact Hub) and uses GitHub Actions to run RBAC Scope daily against their artifacts. The results are then published to a public website, rbac.dev (hosted on GitHub Pages), creating a dynamic, real-time threat landscape of the cloud-native ecosystem. The platform tracks historical data from over 25,000 artifacts over six months, allowing users to see detected vulnerabilities, associated service accounts, risk explanations, and even potential exploitation commands for specific project versions. This entire infrastructure leverages GitHub's free services, making it a sustainable and community-driven resource for security analysis.

Demo / Proof of Concept

▶ Watch: Critical impact of compromising the Kubernetes control plane (5:55)

Lenin Alevski demonstrated the practical application of his research and tools in two key phases: the initial exploit replication and the automated RBAC analysis platform.

First, Alevski recounted his experience in building a Proof of Concept (PoC) exploit for the Ingress Nginx vulnerability (CVE-2021-25742). Inspired by the Wiz research paper, he challenged himself to replicate the attack chain, which involved a complex race condition. Despite the difficulties of implementing such an exploit in a containerized Kubernetes environment, he successfully developed a functioning PoC. This hands-on experience validated the severe impact of the vulnerability, particularly when combined with the overly permissive default RBAC configuration of Ingress Nginx. He explained how, once the reverse shell was established, the attacker could leverage the Ingress Nginx identity, which typically had a ClusterRole granting list and watch permissions on various resources, including secrets, across the entire cluster. This demonstrated a clear path from RCE to widespread data exfiltration.

Following the exploit demonstration, Alevski showcased the RBAC Scope CLI tool. He presented a live view of the tool analyzing a vulnerable version of the Ingress Nginx artifact. The CLI output clearly highlighted critical findings, specifically identifying that the artifact's RBAC configuration included a ClusterRole with list and watch permissions on all secrets. This confirmed that the tool could effectively detect the exact misconfiguration that made the Ingress Nginx vulnerability so impactful. He emphasized that RBAC Scope can be pointed at any Kubernetes YAML configuration (e.g., Helm charts, Kustomize outputs) without needing to run inside a cluster or requiring any specific identity, making it ideal for integration into CI/CD pipelines.

Finally, Alevski presented the RBAC Atlas website, the culmination of his automated analysis efforts. He navigated to rbac.dev and searched for "ingress nginx." The website displayed historical data and current findings for various versions of the project. For a selected vulnerable version, the platform presented:

• A list of detected vulnerabilities (i.e., RBAC misconfigurations).
• The specific service account associated with the risky permissions.
• A clear explanation of the risk (e.g., "cluster-wide secret enumeration").
• Even actual commands that could be used to exploit these permissions.

This demonstration effectively illustrated how RBAC Atlas provides a comprehensive, up-to-date threat landscape of popular cloud-native projects, offering both high-level summaries and granular technical details for defenders. He also mentioned that the project is open source, with repositories for RBAC Scope (the analyzer) and RBAC Atlas (the automation and website), encouraging community contributions for new detection rules or project tracking.

Defensive Implications

▶ Watch: Brief overview of Kubernetes command execution techniques (7:40)

The insights and tools presented by Lenin Alevski offer critical guidance for organizations operating Kubernetes clusters. Proactive defense against RBAC misconfigurations is paramount to securing cloud-native environments.

1. Adopt the Principle of Least Privilege (PoLP) Religiously: This is the most crucial defensive measure. Developers and operators must rigorously review and prune RBAC permissions. Never use wildcard (*) permissions on apiGroups, resources, or verbs unless absolutely necessary and thoroughly justified. If a ClusterRole is used, ensure its scope is as narrow as possible. For example, if an application only needs to read secrets in its own namespace, do not grant it list/watch permissions on secrets cluster-wide.
2. Integrate RBAC Auditing into CI/CD Pipelines: Tools like RBAC Scope should be integrated early in the development lifecycle. By scanning Kubernetes YAML manifests (Helm charts, Kustomize, raw YAML) before deployment, teams can identify and fix misconfigurations proactively. This "shift left" approach prevents risky permissions from ever reaching production environments.
3. Do Not Trust Default Permissions of Open-Source Projects: While convenient, many open-source projects ship with overly permissive RBAC to ensure broad compatibility. Defenders must treat these defaults as a starting point for hardening, not a secure baseline. Always audit and customize RBAC to meet specific security requirements.
4. Regularly Scan and Monitor Deployed RBAC: Even with initial hardening, RBAC configurations can drift or be altered over time. Tools like RBAC Atlas provide continuous monitoring of popular projects, but internal tools should also be used to regularly audit the RBAC applied to your own custom applications and infrastructure within your clusters.
5. Stay Informed on Cloud-Native Vulnerabilities: Subscribe to security advisories and monitor platforms like RBAC Atlas for new detection rules and identified risky projects. Timely patching of vulnerabilities, especially those that can be amplified by RBAC misconfigurations (like Ingress Nginx CVE-2021-25742), is essential.
6. Harden Control Plane Components:

• Encrypt etcd: To prevent direct access to cluster state data, etcd should always be encrypted at rest and in transit.
• Secure kube-API Server: Implement strong authentication and authorization for API access.
• Harden Kubelet: Ensure proper authentication and authorization for kubelet endpoints, especially in older Kubernetes versions where it lacked these controls.

1. Secure Application Workloads: Implement robust security practices for applications themselves, such as regular vulnerability scanning of container images, secure coding practices, and runtime security monitoring. This reduces the likelihood of an initial compromise that could then leverage RBAC misconfigurations.
2. Educate Developers and Operators: Provide training on secure Kubernetes development and operation, emphasizing the importance of RBAC, the principle of least privilege, and common misconfiguration pitfalls.
3. Implement Network Policies: While RBAC controls who can do what, Network Policies control what can talk to what. Using network policies can segment your cluster and limit the blast radius of a compromised pod, even if it has overly broad RBAC permissions.
4. Review Service Accounts: Pay close attention to the permissions granted to Service Accounts, as these are the identities most commonly used by applications within pods. Avoid binding highly privileged ClusterRoles to Service Accounts, especially those used by internet-facing applications.

By combining automated analysis, continuous monitoring, and a strong adherence to security best practices, organizations can significantly reduce their exposure to RBAC-related vulnerabilities in Kubernetes.

Key Takeaways

• Kubernetes RBAC is a Double-Edged Sword: While powerful and flexible, the inherent complexity of Kubernetes RBAC frequently leads to misconfigurations, making it a critical security minefield.
• Overly Permissive Defaults are Common: Many popular open-source Kubernetes projects ship with default RBAC policies that grant excessive permissions, creating a significant attack surface that organizations must actively audit and prune.
• Automated RBAC Analysis is Essential: Tools like RBAC Scope provide a vital "shift-left" capability, enabling static analysis of Kubernetes YAML manifests to detect dangerous RBAC misconfigurations before deployment.
• Vulnerability Chaining is a Major Threat: As demonstrated by the Ingress Nginx vulnerability (CVE-2021-25742), an RCE in one component, when combined with over-privileged RBAC, can rapidly escalate to cluster-wide compromise and data exfiltration.
• RBAC Atlas Provides Real-World Visibility: The RBAC Atlas platform offers a continuously updated, data-driven view of RBAC security across the cloud-native ecosystem, helping defenders identify risky projects and common misconfiguration patterns.
• Principle of Least Privilege is Non-Negotiable: Adhering strictly to the Principle of Least Privilege for all Kubernetes identities and resources is the most effective defense against RBAC-related vulnerabilities, coupled with regular auditing and staying informed about new threats.

About the Speaker(s)

Lenin Alevski is a dedicated security professional with a passion for cybersecurity. He has a diverse background, having worked for both startups and large corporations, gaining extensive experience across various industry settings. Alevski is deeply involved in the cybersecurity community, volunteering at the Pacific Hacker Association, a non-profit organization focused on helping individuals break into the cybersecurity field and connect with hiring managers. He describes himself as "obsessed of cybersecurity," always eager to discuss security topics and connect with like-minded individuals. His work on RBAC Atlas and RBAC Scope exemplifies his commitment to improving security in the cloud-native space.