Lesson 04 — RBAC Exploitation

Welcome

Role-Based Access Control (RBAC) is one of the most important security controls in Kubernetes.

Every action performed inside a Kubernetes cluster—whether creating a pod, viewing secrets, modifying deployments, or managing nodes—is governed by RBAC permissions.

Unfortunately, RBAC is also one of the most commonly misconfigured components in enterprise Kubernetes environments. Excessive permissions, overly permissive ClusterRoles, and weak governance can allow attackers to escalate privileges, access sensitive resources, and ultimately compromise an entire cluster.

As a Cloud Penetration Tester, your responsibility is to identify RBAC weaknesses, validate authorization controls, and provide practical recommendations to improve security without disrupting business operations.

In this lesson, you will learn how RBAC works, common attack paths, and how consultants assess RBAC during enterprise Kubernetes security reviews.

Learning Objectives

After completing this lesson, you will be able to:

Understand Kubernetes RBAC architecture.
Differentiate Roles and ClusterRoles.
Understand RoleBindings and ClusterRoleBindings.
Identify excessive permissions.
Recognize common RBAC attack paths.
Assess least privilege implementation.
Review enterprise identity governance.
Document RBAC security findings.

Business Scenario

CloudNova Technologies has been contracted to perform a Kubernetes security assessment for a financial services organization.

The customer has hundreds of developers, DevOps engineers, and automation accounts accessing multiple Kubernetes clusters.

Management is concerned that overly permissive RBAC configurations may allow unauthorized access to production workloads and sensitive business data.

Your objective is to review the Kubernetes authorization model, identify excessive permissions, and assess whether the environment follows the Principle of Least Privilege.

What is RBAC?

Role-Based Access Control (RBAC) is Kubernetes’ authorization system.

RBAC determines:

Who can access cluster resources.
Which actions they can perform.
Which namespaces they can access.
Whether permissions apply to one namespace or the entire cluster.

Authentication answers “Who are you?”

Authorization answers “What are you allowed to do?”

RBAC Components

Kubernetes RBAC consists of four primary objects:

Role

Applies permissions within a single namespace.

Examples:

View Pods
Create ConfigMaps
Read Secrets

ClusterRole

Applies permissions across the entire cluster.

Examples:

Cluster Administrator
Node Management
Namespace Administration

RoleBinding

Assigns a Role to:

User
Group
Service Account

Only within one namespace.

ClusterRoleBinding

Assigns a ClusterRole across every namespace in the cluster.

These require careful governance because they provide cluster-wide permissions.

RBAC Architecture

User / Group / Service Account

↓

Role or ClusterRole

↓

RoleBinding / ClusterRoleBinding

↓

Kubernetes API Server

↓

Authorized Resources

Why Attackers Target RBAC

RBAC determines what an attacker can access after gaining an initial foothold.

Poorly configured RBAC may allow attackers to:

Read Secrets
Deploy malicious Pods
Modify Deployments
Access Nodes
Create privileged workloads
Execute commands inside containers
Create new Service Accounts
Escalate privileges
Gain cluster administrator access

Common RBAC Misconfigurations

During enterprise assessments, consultants frequently identify:

Excessive ClusterRole assignments
Cluster-admin granted unnecessarily
Wildcard permissions (*)
Overly permissive Service Accounts
Shared administrative accounts
Unused RoleBindings
Dormant administrative identities
Missing namespace isolation
Poor separation of duties
Inconsistent permission reviews

RBAC Attack Paths

Attackers typically follow this progression:

Compromise Identity

↓

Enumerate Permissions

↓

Identify Privileged Roles

↓

Access Secrets

↓

Create Privileged Pods

↓

Deploy Malicious Workloads

↓

Access Worker Nodes

↓

Gain Cluster Administrator

↓

Pivot into Cloud Environment

Understanding this sequence helps security teams identify and block privilege escalation opportunities.

Enterprise RBAC Review

During an enterprise assessment, review:

Roles

Defined permissions
Scope
Business purpose

ClusterRoles

Administrative access
Wildcard permissions
High-risk privileges

RoleBindings

Namespace assignments
User mappings
Group mappings

ClusterRoleBindings

Cluster-wide administrative access
Identity ownership
Business justification

Service Accounts

Review:

Assigned Roles
Namespace
Mounted Tokens
API Access
Workload Identity

Principle of Least Privilege

Every identity should receive only the permissions required to perform its job.

Examples include:

Role	Recommended Permissions
Developer	Manage workloads within development namespaces
DevOps Engineer	Deploy applications and manage infrastructure
Security Engineer	Read security resources and audit logs
Cluster Administrator	Full cluster administration
Monitoring Service	Read-only metrics and monitoring access

Avoid assigning broad permissions where narrower roles are sufficient.

RBAC Security Assessment Checklist

During an assessment, verify:

Roles are appropriately scoped.
ClusterRoles are justified.
RoleBindings follow least privilege.
ClusterRoleBindings are limited.
Administrative accounts use MFA (where integrated).
Service Accounts have only required permissions.
Dormant identities are removed.
Access reviews are performed regularly.
RBAC policies are documented.

Common Security Findings

Examples of findings include:

Cluster-admin assigned to developer accounts.
Wildcard permissions across multiple namespaces.
Shared Service Accounts.
Excessive RoleBindings.
Privileged automation accounts.
Missing access reviews.
Unused administrative identities.
Weak identity governance.
Lack of RBAC documentation.

Consultant Best Practices

Professional Kubernetes security consultants should:

Review RBAC before testing workloads.
Document every privileged identity.
Validate business ownership of administrative access.
Review namespace isolation.
Verify Service Account permissions separately from user accounts.
Recommend least privilege wherever possible.
Support findings with evidence.
Prioritize risks based on business impact.

Key Takeaways

RBAC is the primary authorization mechanism in Kubernetes.
Roles control namespace permissions, while ClusterRoles control cluster-wide permissions.
Excessive permissions significantly increase the risk of privilege escalation.
Service Accounts require the same level of governance as user accounts.
Applying the Principle of Least Privilege is essential for securing Kubernetes environments.
A structured RBAC review is a critical component of every enterprise Kubernetes security assessment.

Lesson Summary

In this lesson, you explored Kubernetes Role-Based Access Control (RBAC), including its core components, common misconfigurations, attack paths, and assessment methodology.

Understanding RBAC enables Cloud Penetration Testers to identify authorization weaknesses, evaluate identity governance, and recommend security improvements that reduce the risk of privilege escalation within Kubernetes clusters.

What’s Next?

➡️ Lesson 05 — Kubernetes Secrets

In the next lesson, you will learn how Kubernetes stores and manages sensitive information, how attackers target Secrets and Service Account tokens, and how consultants assess secrets management during enterprise Kubernetes security reviews.