Lesson 03 — Role-Based Access Control (RBAC)

Learning Objectives

By the end of this lesson, you will be able to:

Understand the purpose of Kubernetes RBAC
Explain the core RBAC components
Design enterprise RBAC architectures
Differentiate between Roles and ClusterRoles
Understand RoleBindings and ClusterRoleBindings
Secure Service Accounts using RBAC
Identify common RBAC misconfigurations
Apply enterprise RBAC best practices

Why This Matters

Identity is one of the most targeted attack vectors in modern cloud environments.

Once an attacker gains access to a Kubernetes cluster, their ability to move laterally depends largely on the permissions granted to the compromised identity.

A poorly configured RBAC model can allow an attacker to:

Read Kubernetes Secrets
Delete production workloads
Deploy malicious containers
Escalate privileges
Access sensitive customer data
Compromise the entire Kubernetes cluster

A well-designed RBAC model limits the blast radius of a security incident and is one of the most important controls in Kubernetes security.

What is RBAC?

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

Rather than assigning permissions directly to users, Kubernetes assigns permissions to Roles, and then associates users, groups, or Service Accounts with those Roles.

Identity

↓

Role

↓

Permissions

↓

Kubernetes Resources

This approach simplifies permission management and improves security.

RBAC Workflow

Whenever a request reaches the Kubernetes API Server:

User

↓

Authentication

↓

RBAC Authorization

↓

Permission Evaluation

↓

Allow or Deny

↓

API Request

RBAC evaluates whether the authenticated identity has permission to perform the requested action.

RBAC Components

RBAC consists of four primary resources.

Component	Purpose
Role	Namespace-level permissions
ClusterRole	Cluster-wide permissions
RoleBinding	Assigns a Role
ClusterRoleBinding	Assigns a ClusterRole

Together, these resources define who can perform which actions.

RBAC Architecture

Developer

↓

RoleBinding

↓

Developer Role

↓

Permissions

↓

Pods

Deployments

Services

ConfigMaps

The Role defines the permissions.

The RoleBinding connects those permissions to an identity.

Role

A Role grants permissions inside a single Namespace.

Example:

Namespace

Development

↓

Developer Role

↓

Create Pods

Delete Pods

View Logs

Read ConfigMaps

A Role cannot grant permissions outside its Namespace.

ClusterRole

A ClusterRole grants permissions across the entire Kubernetes cluster.

Example:

Cluster Administrator

↓

Manage Nodes

Manage Namespaces

Manage Storage

Manage CRDs

Manage RBAC

ClusterRoles should only be assigned to trusted administrative identities.

RoleBinding

A RoleBinding links a Role to:

User
Group
Service Account

Example:

Developer

↓

RoleBinding

↓

Developer Role

↓

Development Namespace

Permissions remain limited to the associated Namespace.

ClusterRoleBinding

ClusterRoleBindings assign ClusterRoles across the cluster.

Security Administrator

↓

ClusterRoleBinding

↓

ClusterRole

↓

Entire Cluster

This grants access to cluster-wide resources.

RBAC Permissions

Permissions are based on three elements.

Verb

+

Resource

+

API Group

Example:

Create

Pods

Core API

RBAC policies specify exactly what actions are permitted.

Common Verbs

Verb	Description
get	Read a resource
list	List multiple resources
watch	Monitor resource changes
create	Create resources
update	Modify existing resources
patch	Modify part of a resource
delete	Remove resources
deletecollection	Delete multiple resources

Limiting verbs is a critical security practice.

Common Kubernetes Resources

RBAC policies commonly protect:

Pods
Deployments
Services
Secrets
ConfigMaps
Namespaces
Nodes
Persistent Volumes
Jobs
CronJobs
Ingresses

Each resource can have different permission levels.

Example RBAC Design

Development Team

↓

Developer Role

↓

Pods

Deployments

Services

↓

Development Namespace

The same developer cannot access production resources.

Enterprise RBAC Model

Cluster

├── Platform Team
│      └── Cluster Administrator
│
├── Security Team
│      └── Security Auditor
│
├── Development Team
│      └── Developer Role
│
├── DevOps Team
│      └── Deployment Role
│
└── Applications
       └── Service Accounts

Each team receives permissions appropriate to its responsibilities.

Built-in ClusterRoles

Kubernetes includes several predefined ClusterRoles.

ClusterRole	Purpose
cluster-admin	Full administrative control
admin	Namespace administration
edit	Modify most resources
view	Read-only access

Where possible, assign the least privileged built-in role that meets operational requirements.

Service Accounts and RBAC

Applications authenticate using Service Accounts.

RBAC determines what those applications can access.

Application Pod

↓

Service Account

↓

RoleBinding

↓

Role

↓

Read ConfigMaps

Read Secrets

Applications should receive only the permissions they require.

Least Privilege

The Principle of Least Privilege (PoLP) means granting the minimum permissions necessary.

Instead of:

Developer

↓

Cluster Admin

Use:

Developer

↓

Developer Role

↓

Development Namespace

Smaller permission sets significantly reduce the impact of compromised credentials.

Privilege Escalation Risks

Improper RBAC configuration can allow privilege escalation.

Examples include:

Granting wildcard permissions
Allowing Role creation
Allowing ClusterRoleBinding creation
Granting Secret read access unnecessarily
Excessive Service Account permissions

An attacker may leverage these permissions to gain full administrative access.

Enterprise Example

A global retail organisation operates Amazon EKS for its e-commerce platform.

RBAC design:

Platform Team

↓

Cluster Admin

----------------------

Security Team

↓

Security Auditor

----------------------

Developers

↓

Developer Role

↓

Development Namespace

----------------------

CI/CD Pipeline

↓

Deployment Role

----------------------

Applications

↓

Dedicated Service Accounts

All production changes require approval through a controlled deployment pipeline.

RBAC in Amazon EKS

Amazon EKS combines AWS IAM authentication with Kubernetes RBAC authorization.

AWS IAM

↓

Authentication

↓

Amazon EKS

↓

RBAC

↓

Permissions Granted

AWS IAM determines identity.

RBAC determines access.

Auditing RBAC

Security teams should regularly review:

Roles
ClusterRoles
RoleBindings
ClusterRoleBindings
Service Account permissions
Privileged identities
Unused permissions
Wildcard rules
Namespace access
Administrative changes

Regular reviews help reduce privilege creep.

Common RBAC Security Risks

Cloud Security Engineers frequently discover:

Everyone assigned cluster-admin
Wildcard permissions (*)
Excessive ClusterRoleBindings
Shared administrator accounts
Default Service Accounts with unnecessary permissions
Production write access for developers
Forgotten administrator accounts
No RBAC reviews
Overprivileged CI/CD pipelines
Applications with unrestricted Secret access

These issues significantly increase the risk of compromise.

Enterprise Monitoring

Security Operations teams should monitor:

Role creation
ClusterRole changes
RoleBinding updates
ClusterRoleBinding updates
Privilege escalation attempts
Unauthorized access attempts
Service Account changes
Administrator activity
Secret access events
RBAC policy modifications

RBAC changes should generate alerts for security review.

Best Practices

As a Kubernetes Security Engineer:

Use Namespace-scoped Roles wherever possible.
Restrict ClusterRoles to platform administrators.
Avoid granting cluster-admin unnecessarily.
Assign permissions using groups instead of individual users.
Create dedicated Service Accounts for applications.
Follow the Principle of Least Privilege.
Regularly audit RBAC policies.
Remove unused Roles and RoleBindings.
Monitor RBAC changes continuously.
Document access policies and review them periodically.

RBAC should evolve alongside organisational changes and application growth.

Real-World Scenario

An enterprise grants the cluster-admin ClusterRole to every developer for convenience.

A developer accidentally executes:

kubectl delete namespace production

Because RBAC allowed unrestricted administrative access, the production namespace is deleted, causing:

Application outages
Customer impact
Service disruption
Emergency recovery procedures
Financial losses

A properly designed RBAC model would have restricted the developer to the development namespace, preventing the incident.

Key Takeaways

After completing this lesson, you should understand:

The purpose of RBAC
The four RBAC components
The differences between Roles and ClusterRoles
How RoleBindings and ClusterRoleBindings work
How RBAC secures Service Accounts
Common RBAC security risks
Enterprise RBAC design principles
Best practices for implementing least privilege

RBAC is the cornerstone of Kubernetes authorization and one of the most important controls for protecting enterprise Kubernetes environments.

Knowledge Check

Question 1

Which Kubernetes resource grants permissions within a single Namespace?

A. ClusterRole
B. Role
C. ServiceAccount
D. Deployment

Answer: B

Question 2

Which resource connects a Role to a user, group or Service Account?

A. RoleBinding
B. ConfigMap
C. Namespace
D. Ingress

Answer: A

Question 3

Which built-in ClusterRole provides unrestricted administrative access?

A. view
B. edit
C. admin
D. cluster-admin

Answer: D

Question 4

Which security principle should guide every RBAC implementation?

A. Shared Responsibility
B. High Availability
C. Principle of Least Privilege
D. Immutable Infrastructure

Answer: C

Question 5

In Amazon EKS, which service authenticates users before RBAC evaluates permissions?

A. Amazon Route 53
B. AWS IAM
C. Amazon CloudWatch
D. Amazon Inspector

Answer: B

What’s Next?

In the next lesson, you will learn about Service Accounts, exploring how Kubernetes workloads authenticate to the API Server, how Service Accounts interact with RBAC and IAM Roles for Service Accounts (IRSA), and how to securely grant applications access to AWS resources in Amazon EKS.

➡️ Next Lesson: Lesson 04 — Service Accounts & IAM Roles for Service Accounts (IRSA)