Kubernetes RBAC Mistakes That Lead to Breaches

The Silent Privilege Escalation Risks Hiding Inside Your Cluster

Most Kubernetes breaches don’t begin with a zero-day vulnerability.

They begin with a simple YAML file.

A service account receives excessive permissions.

A developer gets cluster-admin “temporarily.”

A wildcard permission sneaks into production.

Months later, an attacker compromises a pod and suddenly gains access to secrets, nodes, workloads, and even cloud credentials.

The scary part?

Everything was technically working as designed.

The real problem was RBAC.

In this article, we’ll explore the most dangerous Kubernetes RBAC mistakes, how attackers exploit them, and how platform teams can secure clusters before these mistakes become headline-worthy incidents.

Why RBAC Matters So Much

RBAC (Role-Based Access Control) is Kubernetes’ primary authorization mechanism.

Every request to the Kubernetes API is evaluated against RBAC policies.

When RBAC is poorly configured:

• Attackers can steal secrets
• Compromised pods can move laterally
• Developers can escalate privileges
• Entire clusters can be taken over

Think of RBAC as the security guard of your Kubernetes API.

If the guard gives everyone a master key, security becomes meaningless.

How Kubernetes Authorization Works

When a request reaches the API server:

 User/Service Account
          │
          ▼
   Authentication
          │
          ▼
 Authorization (RBAC)
          │
          ▼
Admission Controllers
          │
          ▼
  API Object Access

RBAC determines:

• Who can perform actions
• Which resources can be accessed
• What operations are allowed

Example:

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get","list"]

This allows reading pod information only.

Simple.

Dangerous when misconfigured.

Mistake #1: Giving Everyone cluster-admin

The most common RBAC mistake.

Example:

kind: ClusterRoleBinding

roleRef:
  kind: ClusterRole
  name: cluster-admin

subjects:
- kind: User
  name: developer-team

This effectively grants:

• Full cluster control
• Secret access
• Node access
• Workload creation
• Privilege escalation

An attacker compromising one developer credential now owns the entire cluster.

Attack Scenario

Developer laptop compromised.

Attacker steals kubeconfig:

kubectl get secrets -A

Then:

kubectl create clusterrolebinding evil \
--clusterrole=cluster-admin \
--serviceaccount=default:default

Persistence achieved.

Cluster compromised.

Mistake #2: Wildcard Permissions

Many teams use:

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

This is essentially:

Allow everything forever.

The danger grows over time.

Future Kubernetes resources automatically become accessible.

A role created years ago may unknowingly grant permissions to newly introduced APIs.

Better Approach

Grant only required resources.

Example:

rules:
- apiGroups: [""]
  resources:
  - pods
  - services
  verbs:
  - get
  - list

Least privilege always wins.

Mistake #3: Secret Access Everywhere

Secrets contain:

• Database passwords
• API keys
• OAuth tokens
• Cloud credentials

Yet many organizations grant:

resources:
- secrets
verbs:
- get
- list

to developers and service accounts.

Why This Is Dangerous

An attacker gains pod access.

Then:

kubectl get secrets -A

Result:

AWS_ACCESS_KEY
DATABASE_PASSWORD
JWT_SECRET

Game over.

Better Practice

Only allow access to specific secrets when absolutely necessary.

Avoid:

resources:
- secrets
verbs:
- list

The list verb is particularly dangerous.

Mistake #4: Overpowered Service Accounts

Many applications run with default service accounts.

Example:

serviceAccountName: default

Meanwhile the default account has broad permissions:

verbs:
- get
- list
- watch

across multiple resources.

Real Attack Chain

Compromised application:

cat /var/run/secrets/kubernetes.io/serviceaccount/token

Uses token:

kubectl --token=<stolen-token>

Now attacker queries the API directly.

The pod becomes an internal attacker.

Secure Alternative

Create dedicated service accounts.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-api

Grant only required permissions.

Nothing more.

Mistake #5: Allowing Pod Creation

This one surprises many teams.

A user who can create pods can often become root over the cluster.

Example:

verbs:
- create
resources:
- pods

Privilege Escalation Example

Attacker deploys:

hostPath:
  path: /

or

privileged: true

Now the pod gains access to host resources.

Potential outcomes:

• Node compromise
• Container escape
• Credential theft

Pod creation permissions should be treated as highly privileged.

Mistake #6: Dangerous Impersonation Rights

RBAC supports impersonation.

Example:

verbs:
- impersonate
resources:
- users

This enables:

kubectl auth can-i '*' '*' \
--as=admin

An attacker can act as another user.

Including administrators.

Security Recommendation

Avoid granting:

resources:
- users
- groups
verbs:
- impersonate

unless absolutely required.

Mistake #7: Ignoring Namespace Boundaries

Many teams create ClusterRoles for namespace-level needs.

Example:

kind: ClusterRole

instead of:

kind: Role

Consequences:

A compromise in one namespace can affect all namespaces.

Including:

• Production
• Staging
• Security tools
• Monitoring systems

Safer Design

Use:

kind: Role

whenever possible.

Reserve ClusterRoles for true cluster-wide responsibilities.

Mistake #8: Allowing Role Modification

One of the most dangerous permissions:

resources:
- roles
- rolebindings
verbs:
- create
- update

Attack Path

Attacker creates:

kind: RoleBinding

roleRef:
  name: cluster-admin

Then binds it to themselves.

Instant privilege escalation.

Mistake #9: No RBAC Auditing

Many organizations never review RBAC policies.

Years pass.

Permissions accumulate.

Nobody knows:

• Who has cluster-admin
• Which service accounts are overprivileged
• Which roles are unused

This creates massive attack surface.

Useful Commands

Find cluster admins:

kubectl get clusterrolebindings

Check permissions:

kubectl auth can-i --list

Review service accounts:

kubectl get sa -A

Mistake #10: Forgetting Aggregated Privileges

Some Kubernetes distributions aggregate roles.

Example:

aggregationRule:

Permissions may be inherited automatically.

Administrators often review one role while missing inherited permissions from another.

The result:

Unexpected privilege expansion.

Always inspect effective permissions, not just individual YAML files.

Real-World Breach Scenario

Imagine this sequence:

Step 1

Web application vulnerable to RCE.

Attacker gains shell.

bash

Step 2

Steals service account token.

cat token

Step 3

RBAC allows secret access.

kubectl get secrets

Step 4

Cloud credentials discovered.

Step 5

Attacker accesses AWS.

Step 6

Creates privileged pod.

Step 7

Compromises node.

Step 8

Controls entire cluster.

No Kubernetes vulnerability.

No container escape.

Just RBAC abuse.

RBAC Security Best Practices

Follow Least Privilege

Grant only necessary permissions.

Not future permissions.

Not convenience permissions.

Only required permissions.

Use Namespace Isolation

Prefer:

Role
RoleBinding

over:

ClusterRole
ClusterRoleBinding

Eliminate Wildcards

Avoid:

*

in:

• Resources
• Verbs
• API groups

Audit Regularly

Monthly reviews:

kubectl auth can-i

kubectl get clusterrolebindings

kubectl describe role

Separate Human and Workload Access

Developers:

Read-only permissions

Applications:

Dedicated service accounts

Never share identities.

Use Admission Controls

Combine RBAC with:

• OPA Gatekeeper
• Kyverno
• Pod Security Standards

RBAC alone is not enough.

Disable Token Mounting

When not required:

automountServiceAccountToken: false

This removes a common attack vector.

Security Checklist

✅ No cluster-admin for developers

✅ No wildcard permissions

✅ Dedicated service accounts

✅ Secret access minimized

✅ Pod creation tightly controlled

✅ Namespace isolation enforced

✅ RBAC reviewed monthly

✅ Privilege escalation paths tested

✅ Admission policies enabled

✅ Service account tokens minimized

Final Thoughts

Kubernetes RBAC is one of those systems that appears harmless until it’s not.

Most organizations spend time scanning container images, hardening nodes, and monitoring networks.

Yet a single overpowered RoleBinding can bypass all those defenses.

Attackers don’t care whether the door was opened by a vulnerability or by a permission you accidentally granted.

From a security perspective, the outcome is identical.

The strongest Kubernetes security posture starts with a simple principle:

Every permission is a potential attack path.

Treat RBAC policies like production code, review them continuously, test them aggressively, and remove permissions whenever possible.

Because in Kubernetes, the easiest breach often begins with a YAML file nobody questioned.

Kubernetes #DevOps #CloudSecurity #CyberSecurity #RBAC #PlatformEngineering #SRE #K8s #CloudNative #SecurityEngineering