Lesson 02 — Kubernetes Authorization

Learning Objectives

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

Understand Kubernetes authorization
Differentiate authentication from authorization
Learn how Kubernetes evaluates permissions
Understand Role-Based Access Control (RBAC)
Understand Roles, ClusterRoles, RoleBindings and ClusterRoleBindings
Learn enterprise authorization design
Apply least privilege principles
Identify common authorization security risks

Why This Matters

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

Just because a user successfully logs into a Kubernetes cluster does not mean they should have unrestricted access.

For example:

A developer should deploy applications.
A SOC analyst should view logs.
A platform administrator should manage the cluster.
A finance application should never access HR Secrets.

Authorization ensures every identity only receives the permissions required to perform its job.

This follows one of the most important cybersecurity principles:

Principle of Least Privilege (PoLP)

What is Authorization?

Authorization is the process of determining whether an authenticated identity is permitted to perform a requested action.

Every request is evaluated against a set of access policies before Kubernetes executes it.

User

↓

Authenticated

↓

Authorization

↓

Allowed?

↓

Yes → Execute Request

No → Access Denied

Authentication vs Authorization

Authentication	Authorization
Who are you?	What can you do?
Identity verification	Permission verification
First security layer	Second security layer
AWS IAM, Certificates, Tokens	RBAC, Webhooks

Authentication always occurs before authorization.

Kubernetes Request Flow

Every Kubernetes API request follows the same sequence.

User

↓

kubectl

↓

API Server

↓

Authentication

↓

Authorization

↓

Admission Controllers

↓

Resource Created

If authorization fails, the request is rejected immediately.

Authorization Methods

Kubernetes supports multiple authorization mechanisms.

Authorization Method	Description
RBAC	Role-Based Access Control (Recommended)
ABAC	Attribute-Based Access Control (Legacy)
Node Authorization	Permissions for Worker Nodes
Webhook Authorization	External authorization service

Modern enterprise environments almost always use RBAC.

What is RBAC?

Role-Based Access Control (RBAC) controls access by assigning permissions to roles rather than directly to users.

Instead of giving permissions individually:

Developer

↓

Role

↓

Permissions

Multiple users can share the same role.

This simplifies administration and improves consistency.

RBAC Architecture

User

↓

RoleBinding

↓

Role

↓

Permissions

↓

Kubernetes Resources

The RoleBinding connects the user with the permissions defined in a Role.

Kubernetes RBAC Components

RBAC consists of four primary objects.

Object	Purpose
Role	Permissions inside one Namespace
ClusterRole	Permissions across the entire cluster
RoleBinding	Assigns a Role to a user, group or Service Account
ClusterRoleBinding	Assigns a ClusterRole cluster-wide

Understanding these four resources is essential for securing Kubernetes.

Roles

A Role grants permissions within a single Namespace.

Example:

Development Namespace

↓

Developer Role

↓

Create Pods

Delete Pods

View Logs

The Role cannot grant access outside its Namespace.

ClusterRoles

A ClusterRole grants permissions across the entire Kubernetes cluster.

Example:

Cluster Administrator

↓

Manage Nodes

Manage Namespaces

Manage Storage

View All Resources

ClusterRoles should be granted only to trusted administrators.

RoleBindings

A RoleBinding associates a Role with:

User
Group
Service Account

Example:

Developer

↓

RoleBinding

↓

Developer Role

↓

Development Namespace

The user receives only the permissions defined within that Role.

ClusterRoleBindings

A ClusterRoleBinding assigns a ClusterRole across the entire cluster.

Example:

Platform Administrator

↓

ClusterRoleBinding

↓

Cluster Administrator

↓

Entire Cluster

These permissions are extremely powerful and should be carefully controlled.

RBAC Example

Finance Namespace

↓

Finance Role

↓

Read ConfigMaps

Read Secrets

Create Pods

↓

Assigned to

↓

Finance Developers

Developers cannot access resources outside the Finance Namespace.

Namespace-Level Permissions

RBAC commonly separates environments.

Production

↓

Read Only

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

Development

↓

Create

Update

Delete

Developers often have full permissions in development but read-only access in production.

Cluster-Level Permissions

Only platform administrators typically receive cluster-wide permissions.

Platform Team

↓

ClusterRole

↓

Manage Cluster

↓

All Namespaces

Application teams rarely require cluster-wide access.

Least Privilege Principle

The Principle of Least Privilege means giving identities only the permissions required to perform their tasks.

Instead of:

Developer

↓

Cluster Admin

Use:

Developer

↓

Development Role

↓

Development Namespace

Smaller permission sets reduce the impact of compromised accounts.

Enterprise RBAC Design

A typical enterprise environment may look like this.

Platform Administrators

↓

Cluster Administrator

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

Security Team

↓

Security Auditor

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

Developers

↓

Developer Role

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

CI/CD

↓

Deployment Role

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

Applications

↓

Service Account Role

Each identity receives only the permissions necessary for its responsibilities.

Amazon EKS Authorization

Amazon EKS combines AWS IAM with Kubernetes RBAC.

Authentication:

AWS IAM

↓

Identity Verified

Authorization:

RBAC

↓

Allowed Actions

AWS IAM determines who can connect.

RBAC determines what they can do.

Service Account Authorization

Applications running inside Pods also require authorization.

Example:

Pod

↓

Service Account

↓

RoleBinding

↓

Role

↓

Read ConfigMaps

Applications should never receive unnecessary permissions.

Built-in ClusterRoles

Kubernetes provides several predefined ClusterRoles.

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

Avoid granting cluster-admin unless absolutely necessary.

Enterprise Example

A healthcare company uses Amazon EKS.

RBAC design:

Platform Team

↓

Cluster Administrator

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

Developers

↓

Development Role

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

SOC Team

↓

View Logs

View Events

Read ConfigMaps

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

Applications

↓

Service Account Roles

No user has unnecessary permissions.

All access is audited.

Authorization Security Risks

Security teams commonly identify:

Everyone assigned cluster-admin
Excessive ClusterRoleBindings
Unused administrator accounts
Wildcard permissions (*)
Shared administrator accounts
Default Service Accounts with unnecessary permissions
Production write access for developers
Missing RBAC reviews
Overly broad Service Account permissions
Privilege escalation opportunities

These issues significantly increase the attack surface.

Enterprise Monitoring

Security teams should monitor:

New Role creation
ClusterRole modifications
RoleBinding changes
ClusterRoleBinding changes
Privilege escalation attempts
Failed authorization requests
Administrator activity
Service Account permission changes
Namespace permission changes
Unusual RBAC modifications

Changes to RBAC should always be logged and reviewed.

Best Practices

As a Kubernetes Security Engineer:

Use RBAC for authorization.
Apply the Principle of Least Privilege.
Avoid granting cluster-admin unnecessarily.
Use Namespace-scoped Roles whenever possible.
Limit ClusterRoleBindings.
Review permissions regularly.
Separate production and development access.
Restrict Service Account permissions.
Monitor RBAC changes.
Audit all privileged activity.

Authorization should always follow the principle of “deny by default and grant only what is required.”

Real-World Scenario

An organisation mistakenly grants the cluster-admin ClusterRole to every developer.

One developer’s laptop is compromised through phishing.

The attacker uses the developer’s credentials to:

Delete production namespaces.
Access Kubernetes Secrets.
Create privileged Pods.
Deploy cryptocurrency mining containers.
Disable logging.

If least privilege RBAC had been implemented, the attacker would have been limited to a single development namespace instead of compromising the entire cluster.

Key Takeaways

After completing this lesson, you should understand:

What Kubernetes authorization is
The difference between authentication and authorization
RBAC architecture
Roles and ClusterRoles
RoleBindings and ClusterRoleBindings
Least privilege access
Enterprise RBAC design
Common authorization risks
Best practices for securing Kubernetes permissions

Authorization is the foundation of Kubernetes access control and one of the most important security mechanisms in every production cluster.

Knowledge Check

Question 1

What question does Kubernetes authorization answer?

A. Who are you?
B. What are you allowed to do?
C. Which Node should run the Pod?
D. How much storage is available?

Answer: B

Question 2

Which authorization method is recommended for modern Kubernetes environments?

A. ABAC
B. RBAC
C. Static Passwords
D. Basic Authentication

Answer: B

Question 3

Which Kubernetes resource grants permissions within a single Namespace?

A. ClusterRole
B. Role
C. Service
D. ConfigMap

Answer: B

Question 4

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

A. ClusterRole
B. RoleBinding
C. Deployment
D. Namespace

Answer: B

Question 5

Which security principle should always guide Kubernetes authorization?

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

Answer: C

What’s Next?

In the next lesson, you will dive deeper into Kubernetes Role-Based Access Control (RBAC) by learning how to design enterprise RBAC models, create custom Roles and ClusterRoles, manage RoleBindings and ClusterRoleBindings, and implement secure access strategies for large-scale Amazon EKS environments.

➡️ Next Lesson: Lesson 03 — Role-Based Access Control (RBAC)