Lab 03 — Implement Kubernetes Roles, ClusterRoles & Least Privilege Access

Mission Information

Item	Details
Lab ID	K8S-IAM-LAB-03
Difficulty	Intermediate–Advanced
Estimated Time	3 Hours
Environment	Local Kubernetes Cluster (kind)
Platform	Docker Desktop + kind
Cost	Free
Primary Role	Kubernetes Security Engineer
Module	Module 02 — Kubernetes Identity & Access Management
Previous Lab	Lab 02 — Secure Kubernetes Service Accounts & Authentication

Mission Scenario

CloudNova Technologies has migrated over fifty business applications to Kubernetes.

Initially, every engineer was granted cluster-admin privileges to simplify the migration. As the platform expanded, the Cloud Security team identified several governance issues:

Developers can delete production workloads.
Security analysts can modify application deployments.
Auditors have write access to cluster resources.
Platform engineers share privileged Service Accounts.
There is no formal RBAC design.

The Chief Information Security Officer (CISO) has instructed the Cloud Security team to redesign access management according to the Principle of Least Privilege.

As the Kubernetes Security Engineer, your task is to implement a secure RBAC model that supports multiple business teams while ensuring users only receive the permissions required to perform their job functions.

Learning Objectives

By completing this lab you will learn how to:

Design enterprise RBAC
Differentiate Roles and ClusterRoles
Implement namespace-scoped permissions
Configure cluster-wide permissions
Create RoleBindings
Create ClusterRoleBindings
Validate permissions
Troubleshoot RBAC issues
Apply least privilege
Implement separation of duties
Perform RBAC security assessments

Enterprise Architecture

                    CloudNova Kubernetes Cluster

                         Kubernetes API Server
                                   │
                          Authentication
                                   │
                         Authorization (RBAC)
                                   │
      ┌──────────────┬──────────────┬──────────────┬──────────────┐
      │              │              │              │
 Developers      Operations      Security      Auditors
      │              │              │              │
  Developer      Operations      Security      Read-Only
     Role            Role           Role       ClusterRole
      │              │              │              │
 RoleBinding    RoleBinding    RoleBinding  ClusterRoleBinding
      │              │              │              │
 Dedicated     Dedicated      Dedicated      Dedicated
ServiceAccount ServiceAccount ServiceAccount ServiceAccount

Lab Outcomes

By the end of this lab you will have:

Designed an enterprise RBAC model
Created multiple Roles
Created ClusterRoles
Created RoleBindings
Created ClusterRoleBindings
Validated user permissions
Tested least privilege
Documented enterprise access controls
Produced an RBAC assessment report

Prerequisites

Before starting:

Module 01 completed
Lab 01 completed
Lab 02 completed
Kubernetes cluster operational
kubectl installed

Tools Used

Tool	Purpose
kubectl	Kubernetes Administration
Docker Desktop	Container Runtime
kind	Local Kubernetes
VS Code	YAML Development
PowerShell / Git Bash	Command Execution

Task 01 — Verify Cluster Health

Confirm cluster accessibility.

kubectl cluster-info

kubectl get nodes

kubectl get namespaces

Verify:

Cluster accessible
Nodes Ready
No critical issues

Task 02 — Create Enterprise Namespaces

Create namespaces representing different business environments.

development
testing
production
security

Verify:

kubectl get ns

Task 03 — Create Department Service Accounts

Create dedicated Service Accounts.

Team	Service Account
Developers	developer-sa
Operations	operations-sa
Security	security-sa
Audit	auditor-sa
Platform	platform-admin-sa

Verify:

kubectl get sa -A

Task 04 — Design the RBAC Matrix

Create the following enterprise permission matrix.

Resource	Developers	Operations	Security	Audit
Pods	Read/Write	Read	Read	Read
Deployments	Read/Write	Read	Read	Read
Services	Read	Read/Write	Read	Read
ConfigMaps	Read/Write	Read	Read	Read
Secrets	No Access	Read	Read	Read
Nodes	No	Read	Read	Read
Namespaces	No	Read	Read	Read
Events	Read	Read	Read	Read

Discuss why different teams require different permissions.

Task 05 — Create Developer Role

Create a namespace-scoped Role.

Allow:

Pods
Deployments
ConfigMaps

Operations:

Get
List
Watch
Create
Update
Patch

Do not allow:

Secrets
Namespaces
Nodes

Deploy the Role.

Task 06 — Create Operations Role

Operations engineers require permissions to:

Services
Pods
Deployments
ConfigMaps

Allow:

Read
Update
Patch

Deny:

Secrets deletion
Namespace deletion
Cluster administration

Task 07 — Create Security Analyst Role

Security analysts should be able to investigate workloads.

Allow:

Read Pods
Read Deployments
Read Secrets
Read Events
Read ConfigMaps

Do not allow modifications.

Task 08 — Create Auditor ClusterRole

Create a cluster-wide read-only role.

Resources include:

Nodes
Namespaces
Pods
Deployments
Services
Events
Storage
RBAC objects

Permissions:

Get
List
Watch

Task 09 — Create Platform Administrator ClusterRole

Create a privileged administrative role.

Discuss:

Why should this role only be assigned to Platform Engineering?

Review risks of unrestricted cluster-admin.

Task 10 — Configure RoleBindings

Bind Roles.

Role	Service Account
Developer	developer-sa
Operations	operations-sa
Security	security-sa

Verify:

kubectl get rolebindings -A

Task 11 — Configure ClusterRoleBindings

Bind:

Auditor
Platform Administrator

Verify:

kubectl get clusterrolebindings

Task 12 — Validate RBAC Permissions

Validate using:

kubectl auth can-i

Examples:

kubectl auth can-i get pods

kubectl auth can-i create deployments

kubectl auth can-i get secrets

kubectl auth can-i delete namespaces

Record results.

Task 13 — Simulate Enterprise Access Requests

Scenario 1

Developer requests access to Secrets.

Question:

Should access be granted?

Explain.

Scenario 2

Operations engineer requests cluster-admin.

Assess:

Business justification
Security impact
Alternative approach

Scenario 3

Security analyst requests permission to delete Pods.

Review whether this aligns with the team’s responsibilities.

Task 14 — Test Cross-Namespace Isolation

Attempt to access resources across namespaces.

Observe:

Allowed actions
Denied actions

Verify that Roles remain namespace-scoped.

Task 15 — Review Existing RBAC Objects

Review:

kubectl get roles -A

kubectl get clusterroles

kubectl get rolebindings -A

kubectl get clusterrolebindings

Document:

Number of Roles
Number of ClusterRoles
Privileged bindings
Excessive permissions

Task 16 — Conduct an RBAC Security Review

Evaluate:

Shared Service Accounts
Wildcard permissions (*)
cluster-admin assignments
Least privilege
Separation of duties
Namespace isolation
Role documentation

Classify findings as:

Critical
High
Medium
Low

Task 17 — Troubleshoot an RBAC Issue

Scenario:

A developer reports:

Error from server (Forbidden)

Investigate:

Service Account
Role
RoleBinding
Namespace
API Group
Verb

Identify the root cause and resolve it.

Task 18 — Enterprise RBAC Assessment

Complete the assessment.

Control	Status
Least Privilege
Separation of Duties
Namespace Isolation
ClusterRoles Reviewed
Service Accounts Dedicated
RoleBindings Verified
Audit Access Configured
Administrative Access Restricted

Task 19 — Evidence Collection

Capture evidence for:

Roles
ClusterRoles
RoleBindings
ClusterRoleBindings
Service Accounts
Permission validation
Access denied examples
RBAC assessment
Security findings

Task 20 — Clean Up

Delete:

RoleBindings
ClusterRoleBindings
Roles
ClusterRoles
Service Accounts
Test Namespaces

Verify the environment has been restored.

Skills Developed

After completing this lab you will be able to:

Design enterprise RBAC
Implement namespace isolation
Configure Roles
Configure ClusterRoles
Create RoleBindings
Create ClusterRoleBindings
Validate permissions
Troubleshoot RBAC
Perform access reviews
Apply least privilege
Secure Kubernetes environments

Knowledge Check

Question 1

Which RBAC object grants permissions within a single namespace?

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

Answer: B

Question 2

Which RBAC object grants permissions across the entire cluster?

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

Answer: C

Question 3

What is the purpose of a RoleBinding?

A. Create a Service Account
B. Connect a Role to a user, group, or Service Account
C. Encrypt Secrets
D. Create Pods

Answer: B

Question 4

Which security principle should always guide RBAC design?

A. Maximum Privilege
B. Shared Administrator Accounts
C. Least Privilege
D. Open Access

Answer: C

Question 5

Why should the cluster-admin role be tightly controlled?

A. It only provides read-only access
B. It grants unrestricted administrative access across the cluster
C. It is required for every application
D. It improves Pod performance

Answer: B

Lab Summary

In this lab, you designed and implemented an enterprise-grade RBAC model for a Kubernetes environment. You created namespace-scoped Roles, cluster-wide ClusterRoles, RoleBindings, and ClusterRoleBindings to enforce least-privilege access for developers, operations engineers, security analysts, auditors, and platform administrators.

You validated permissions using kubectl auth can-i, tested namespace isolation, reviewed common RBAC misconfigurations, and investigated access denial scenarios. These practices mirror the identity and authorisation controls implemented in production Kubernetes platforms such as Amazon EKS, Azure AKS, and Google Kubernetes Engine.

What’s Next?

➡️ Next Lab: Lab 04 — Secure Kubernetes Authentication with OIDC & IAM Roles for Service Accounts (IRSA)

In the next lab, you will integrate Kubernetes with external identity providers, explore OpenID Connect (OIDC), configure IAM Roles for Service Accounts (IRSA) on Amazon EKS, and learn how modern cloud-native platforms eliminate long-lived credentials by using federated workload identities.