The RBAC Object Model
Kubernetes RBAC is built from four API objects: Role and ClusterRole define a set of permissions (verbs like get, list, create, delete on resources like pods or secrets), while RoleBinding and ClusterRoleBinding attach those permissions to subjects (users, groups, or ServiceAccounts). A Role is namespace-scoped, meaning its rules only apply within one namespace, whereas a ClusterRole can either be bound cluster-wide via a ClusterRoleBinding or bound to a single namespace via a RoleBinding that references a ClusterRole — a common pattern for reusing a permission set like 'view' or 'edit' across many namespaces without duplicating the rule definitions.
Cricket analogy: It's like a BCCI-issued umpiring certification (ClusterRole) that qualifies someone to officiate anywhere in India, but a specific match assignment (RoleBinding) restricts that umpire to only the Ranji Trophy fixture in Mumbai this week.
Writing Least-Privilege Policies
The core RBAC discipline is least privilege: grant only the verbs and resources a subject actually needs, scoped to the narrowest namespace possible, rather than reaching for cluster-admin or wildcard rules out of convenience. A common mistake is granting 'get, list, watch' on secrets cluster-wide when a workload only needs read access to one specific named secret in its own namespace — resourceNames lets you restrict a rule to specific object names, and aggregated ClusterRoles (using the rbac.authorization.k8s.io/aggregate-to-* label) let you compose broad roles like 'view' from smaller, auditable rule sets. kubectl auth can-i --as=system:serviceaccount:ns:name is the standard way to verify what a ServiceAccount can actually do before shipping it.
Cricket analogy: It's like giving a young net bowler access only to the practice nets for one specific session rather than a master key to the entire stadium and dressing rooms, matching access to the actual job of bowling to the batters that day.
RBAC in Practice
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: payments
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["payments-db-creds"]
verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: payments-sa-secret-reader
namespace: payments
subjects:
- kind: ServiceAccount
name: payments-api
namespace: payments
roleRef:
kind: Role
name: secret-reader
apiGroup: rbac.authorization.k8s.ioAvoid binding the built-in cluster-admin ClusterRole to ServiceAccounts or CI pipeline credentials — it grants unrestricted access to every resource in every namespace, including secrets and RBAC objects themselves, which means a compromised token becomes a full cluster compromise.
- Role/ClusterRole define permissions; RoleBinding/ClusterRoleBinding attach those permissions to subjects.
- A Role is namespace-scoped; a ClusterRole can be bound cluster-wide or per-namespace via RoleBinding.
- resourceNames restricts a rule to specific named objects, tightening scope beyond just resource type.
- Aggregated ClusterRoles compose broad roles from smaller labeled rule sets for maintainability.
- kubectl auth can-i --as verifies actual effective permissions before deploying a workload.
- Never bind cluster-admin to ServiceAccounts or automation credentials; scope tightly instead.
- Least privilege means matching verbs, resources, and namespace scope exactly to what a subject needs.
Practice what you learned
1. What is the key difference between a Role and a ClusterRole?
2. Which field restricts an RBAC rule to only specific named objects instead of an entire resource type?
3. What command checks whether a given ServiceAccount can perform a specific action?
4. Why is binding cluster-admin to a CI pipeline ServiceAccount risky?
5. What mechanism allows composing a broad role like 'view' from several smaller, labeled ClusterRoles?
Was this page helpful?
You May Also Like
Kubernetes Troubleshooting
A systematic approach to diagnosing failing pods, networking issues, and cluster-level problems using kubectl, events, and logs as your primary evidence.
Advanced Kubernetes Interview Questions
A study guide of advanced Kubernetes interview topics spanning scheduling internals, networking, RBAC, and operational judgment expected at senior and staff levels.
Helm Charts Explained
Helm is the package manager for Kubernetes, and charts are the templated bundles of manifests it installs, upgrades, and rolls back as a single versioned release.