Overview and What You Will Learn
Without RBAC, every service account and every developer has the same level of access to your cluster — which in a default Kubernetes install means full admin access. This is the fastest path to accidental data deletion, credential exposure, and compliance failures. This lab walks you through implementing production-grade RBAC from scratch using Roles, ClusterRoles, ServiceAccounts, and RoleBindings to enforce strict least-privilege access across a multi-team cluster.
By the end of this guide you will be able to:
- Understand the four RBAC primitives and how they compose into access policies
- Create namespace-scoped Roles and cluster-scoped ClusterRoles for different team personas
- Bind roles to users, groups, and service accounts using RoleBindings and ClusterRoleBindings
- Verify and audit RBAC permissions using
kubectl auth can-i - Design a multi-team RBAC structure that supports developers, SREs, and CI/CD pipelines independently
Why This Matters in Production
In 2022, a misconfigured Kubernetes service account with cluster-admin privileges was exploited at a fintech platform to exfiltrate customer data from a mounted secrets volume. The service account was originally created for a CI/CD pipeline that needed to deploy pods — it never needed cluster-admin. Least-privilege RBAC would have contained the blast radius to a single namespace.
At Razorpay, Hotstar, and Zerodha — running multi-team clusters with dozens of engineering squads — RBAC is the primary mechanism preventing one team's runaway deployment from deleting another team's production database. Getting RBAC right is a security and operational requirement, not optional.
Core Principles
The four RBAC primitives and how they relate:
