Interactive Explainer

Relevant for:JuniorMid-levelSeniorStaff

Why this matters at your level

Junior

Understand the Subject-RoleBinding-Role model. Know the difference between Role (namespace) and ClusterRole (cluster-wide). Never use cluster-admin for application ServiceAccounts.

Mid-level

Design least-privilege ServiceAccount roles. Use kubectl auth can-i to verify permissions. Understand aggregated ClusterRoles and how they compose.

Senior

Audit existing RBAC with rbac-audit tools. Implement RBAC policies that prevent privilege escalation (no binding of higher roles than you have). Restrict ServiceAccount token auto-mounting.

Staff

Design RBAC for multi-tenant clusters: namespace-scoped admin roles, shared cluster roles, OPA/Gatekeeper policies enforcing RBAC hygiene, and continuous RBAC drift detection.

RBAC & Service Accounts: Identity and Authorization in Kubernetes

RBAC controls what identities can do in Kubernetes. ServiceAccounts give pods an identity. Misconfigured RBAC -- especially wildcard permissions and cluster-admin bindings -- is the most common privilege escalation path in production clusters.

~3 min read

Be the first to complete!

LIVEPrivilege Escalation -- Wildcard RBAC -- CI/CD Pipeline -- 2021

Breaking News

T-14mo

CI/CD ServiceAccount granted wildcard ClusterRole for "pipeline to work"

T+0

Security audit discovers wildcard ClusterRoleBinding; escalation path demonstrated

T+1h

Researcher creates Job via pipeline SA that grants new SA cluster-admin in 3 API calls

T+2h

All Secrets in cluster accessible; signing keys potentially compromised

T+1w

All credentials rotated; RBAC audit tooling (kubectl-who-can) deployed; wildcard roles prohibited

—API calls to escalate to cluster-admin

—Wildcard role undetected

—Effective privilege from one misconfigured role

The question this raises

What is the minimum RBAC privilege a ServiceAccount needs to escalate to cluster-admin, and how do you prevent wildcard roles from persisting undetected?

Test your assumption first

A pod has a ServiceAccount with a Role that allows: resources: ["pods"], verbs: ["get", "list"]. The pod is compromised. What can the attacker do?

Lesson outline

What RBAC Solves

The Authorization Problem

Authentication (who are you?) and authorization (what can you do?) are separate in Kubernetes. RBAC is the authorization layer. It answers: can this identity (user, group, ServiceAccount) perform this action (verb) on this resource type in this namespace?

Least-privilege ServiceAccount

Use for: Create a dedicated ServiceAccount per workload. Grant only the specific resources and verbs needed. No auto-mounted token if the workload does not call the K8s API. This limits blast radius if the pod is compromised.

Aggregated ClusterRole

Use for: A ClusterRole with aggregationRule collects rules from other ClusterRoles matching a label. Used to build composable roles (view, edit, admin) without duplication. Adding a new CRD resource requires only labeling a new ClusterRole.

RBAC audit

Use for: Tools like rbac-lookup and kubectl-who-can enumerate who has what permissions. Run regularly to detect wildcard roles, unexpected cluster-admin bindings, and ServiceAccounts with over-broad permissions.

The System View: RBAC Authorization Chain

API Request: DELETE pods/my-pod
         |
         v  [Authentication]
Subject identified: ServiceAccount myapp in namespace prod
         |
         v  [Authorization -- RBAC check]
Find all RoleBindings/ClusterRoleBindings for: myapp SA
         |
         v
RoleBinding: myapp-reader -> Role: pod-reader (namespace: prod)
  rules:
  - resources: ["pods"]
    verbs: ["get", "list"]    <- DELETE not listed
         |
         v
403 Forbidden: cannot DELETE pods

Subject types:
  User (human, cert auth)
  Group (set of users)
  ServiceAccount (pod identity, stored in K8s)

Escalation risk example:
  Role: create RoleBindings
  + ClusterRole: cluster-admin exists
  = can bind cluster-admin to any subject = full cluster access

RBAC checks every API request; escalation is possible if binding permissions exist without corresponding role restriction

ServiceAccount Permission Design

Situation

Before

After

CI/CD pipeline that deploys Deployments to one namespace

“ClusterRoleBinding to custom role with resources:["*"] verbs:["*"] -- can create ClusterRoleBindings, read Secrets, modify nodes”

“RoleBinding (namespace-scoped) to Role: get/create/update Deployments only in the target namespace”

Application pod that reads its own ConfigMap

“Auto-mounted default SA token with inherited permissions; pod uses it for ConfigMap but attacker also gets SA credentials”

“automountServiceAccountToken: false; ConfigMap value injected as env var at deploy time; no SA token in pod”

How RBAC Works

Creating least-privilege ServiceAccount for a deployment controller

→

1. Create ServiceAccount: kubectl create serviceaccount myapp -n production

→

2. Define Role with minimum required verbs/resources for the specific namespace

→

3. Create RoleBinding linking the ServiceAccount to the Role

→

4. Set automountServiceAccountToken: false if the pod does not call K8s API

→

5. Verify with: kubectl auth can-i list pods --as=system:serviceaccount:production:myapp

6. Test a forbidden action: kubectl auth can-i delete secrets --as=system:serviceaccount:production:myapp (should say "no")

1. Create ServiceAccount: kubectl create serviceaccount myapp -n production

2. Define Role with minimum required verbs/resources for the specific namespace

3. Create RoleBinding linking the ServiceAccount to the Role

4. Set automountServiceAccountToken: false if the pod does not call K8s API

5. Verify with: kubectl auth can-i list pods --as=system:serviceaccount:production:myapp

6. Test a forbidden action: kubectl auth can-i delete secrets --as=system:serviceaccount:production:myapp (should say "no")

rbac-least-privilege.yaml

1apiVersion: v1
2kind: ServiceAccount
3metadata:
4  name: myapp
5  namespace: production
automountServiceAccountToken: false -- no token in pod unless explicitly mounted
6automountServiceAccountToken: false  # no token unless needed
7 
8---
9apiVersion: rbac.authorization.k8s.io/v1
10kind: Role
11metadata:
12  name: myapp-role
13  namespace: production
14rules:
15- apiGroups: [""]
resourceNames: restrict to specific objects -- prevents reading all ConfigMaps
16  resources: ["configmaps"]
17  resourceNames: ["myapp-config"]   # specific CM only
18  verbs: ["get"]
19- apiGroups: ["apps"]
20  resources: ["deployments"]
21  verbs: ["get", "list"]            # read-only on deployments
22 
23---
24apiVersion: rbac.authorization.k8s.io/v1
25kind: RoleBinding
26metadata:
27  name: myapp-binding
28  namespace: production
29subjects:
30- kind: ServiceAccount
31  name: myapp
32  namespace: production
33roleRef:
34  kind: Role
35  name: myapp-role
36  apiGroup: rbac.authorization.k8s.io

What Breaks in Production: Blast Radius

RBAC misconfiguration failure modes

Wildcard verb or resource — resources: ["*"] or verbs: ["*"] grant access to everything in that group. Combined with ClusterRole, this is effectively cluster-admin. Never use wildcards in production roles. Enumerate specific resources and verbs.
Cluster-admin bound to CI/CD SA — CI/CD pipelines need to deploy -- not administer. Namespace-scoped Role with create/update on Deployments/Services is sufficient. cluster-admin allows reading all Secrets, creating ClusterRoleBindings, modifying RBAC.
Auto-mounted token not disabled — Every pod gets a SA token by default. Compromised pod = compromised SA permissions. Set automountServiceAccountToken: false on ServiceAccounts and pods that do not need API access.
Overly permissive default SA — The "default" ServiceAccount in each namespace auto-mounts its token into all pods unless disabled. Bind nothing to the default SA. Create dedicated SAs per workload with minimum permissions.

Wildcard ClusterRole enables full cluster compromise from single SA

Bug

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipeline-role
rules:
- apiGroups: ["*"]     # every API group
  resources: ["*"]     # every resource type
  verbs: ["*"]         # every action
# This is equivalent to cluster-admin
# Can read all Secrets, create ClusterRoleBindings, delete nodes

Fix

apiVersion: rbac.authorization.k8s.io/v1
kind: Role                    # namespace-scoped, not ClusterRole
metadata:
  name: pipeline-deployer
  namespace: production       # only this namespace
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services", "configmaps"]
  verbs: ["get", "list", "create", "update"]

Wildcard ClusterRoles grant full cluster access. Replace with namespace-scoped Role with only the verbs and resources the pipeline actually needs. Most CI/CD pipelines only need to apply Deployments and Services in specific namespaces.

Decision Guide: RBAC Design

Does this workload call the Kubernetes API?

YesCreate a dedicated ServiceAccount with minimum Role; no wildcard verbs or resources

NoSet automountServiceAccountToken: false -- no SA token needed

Does the workload need to act across all namespaces?

YesClusterRole with specific resources (not wildcard) + ClusterRoleBinding; document and audit regularly

NoNamespace-scoped Role + RoleBinding; far smaller blast radius

Is a service account showing up with unexpected permissions?

YesRun: kubectl auth can-i --list --as=system:serviceaccount:ns:sa to enumerate all permissions; audit and remove excess

NoSchedule quarterly RBAC audit with rbac-lookup or OPA Gatekeeper policies

Cost and Complexity: RBAC Pattern Comparison

Pattern	Blast radius	Operational cost	Auditability	Recommended for
cluster-admin binding	Full cluster	None (just works)	Hard to audit	Never for apps or CI/CD
Wildcard ClusterRole	Full cluster (effectively)	Low	Hard to audit	Never in production
Namespace Role + RoleBinding	Namespace-scoped	Medium	Easy to audit	All application SAs
Specific resourceNames	Single object	High (enumerate objects)	Very easy	Sensitive ConfigMaps/Secrets
No SA (automount: false)	None	None	N/A	Pods that do not use K8s API

Exam Answer vs. Production Reality

1 / 3

Role vs ClusterRole

📖 What the exam expects

Role: grants permissions within one namespace. ClusterRole: grants permissions cluster-wide or can be used as a template bound in specific namespaces via RoleBinding.

Toggle between what certifications teach and what production actually requires

How this might come up in interviews

Security architecture questions about multi-tenant cluster design and debugging questions about "forbidden" API errors.

Common questions:

What is the difference between a Role and a ClusterRole?
What is a ServiceAccount and why does auto-mounting the token matter?
How would you check what permissions a ServiceAccount has?
What makes a wildcard RBAC role dangerous?

Strong answer: Mentions RBAC audit tools (rbac-audit, kubectl-who-can), OPA/Gatekeeper to enforce RBAC policies, and WorkloadIdentity / IRSA for cloud provider access instead of Secrets in pods.

Red flags: Granting cluster-admin to CI/CD pipelines, using wildcard resources/verbs, or not knowing that auto-mounted tokens are an attack surface.

Related concepts

Explore topics that connect to this one.

Suggested next

Often learned after this topic.

Pod Security Standards: Hardening Workload Configurations

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Continue learning

Pod Security Standards: Hardening Workload Configurations

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord