0Pricing
Cyber Security Academy · Lesson

RBAC and Service Accounts

Locking down cluster access.

RBAC and Service Accounts is a free Cyber Security Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cyber Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

RBAC Controls Everything

Role-Based Access Control (RBAC) decides which identities can perform which actions on which resources in a cluster. Every API call is authorized against RBAC. Misconfigured RBAC is the leading cause of in-cluster privilege escalation.

  • Subjects: users, groups, service accounts.
  • Roles bind verbs to resources.
  • Bindings connect subjects to roles.

Roles vs ClusterRoles

Two scopes exist.

  • Role + RoleBinding: namespace-scoped permissions.
  • ClusterRole + ClusterRoleBinding: cluster-wide permissions.

A ClusterRoleBinding to cluster-admin is total control. Granting it to a service account is a frequent, dangerous mistake.

Service Account Tokens

Every pod runs as a service account and, by default, mounts its token. That token is a bearer credential carrying the account's RBAC. If the pod is compromised, so is the token.

Modern clusters issue short-lived, audience-bound projected tokens, but legacy long-lived secret tokens still linger.

# Inspect which service account a pod uses
kubectl get pod web -o jsonpath='{.spec.serviceAccountName}'

Enumerating Your Permissions

After capturing a token, the first move is to learn what it can do. Kubernetes provides a self-check API.

# What can this token do?
kubectl auth can-i --list

# Specific checks
kubectl auth can-i create pods
kubectl auth can-i create clusterrolebindings

Dangerous Permission Combinations

Certain verbs are escalation primitives even without cluster-admin.

  • create pods: schedule a privileged or hostPath pod to escape.
  • create pods/exec: run commands in existing pods.
  • get/list secrets: read credentials cluster-wide.
  • create rolebindings/clusterrolebindings: bind yourself to admin.
  • escalate / bind verbs: grant rights you do not hold.
  • impersonate: act as another, more privileged subject.

Escalation via Pod Creation

If a service account can create pods, it can often own the node. The attacker schedules a pod that mounts the host filesystem or runs privileged, then reads node credentials or escapes.

# Pod spec snippet that mounts the host root
# volumes: hostPath path: /  ;  container mounts it at /host
kubectl apply -f evil-pod.yaml
kubectl exec -it evil -- chroot /host bash

Escalation via Binding

If you can create (cluster)rolebindings, you may bind your service account directly to cluster-admin. Kubernetes guards this with the bind/escalate verbs, but misconfigured roles sometimes allow it.

# Bind a service account to cluster-admin (if permitted)
kubectl create clusterrolebinding pwn \
  --clusterrole=cluster-admin \
  --serviceaccount=default:web

Impersonation Abuse

The impersonate verb lets a subject act as any user, group, or service account. A principal with broad impersonation effectively holds every permission in the cluster.

# Act as a privileged user via impersonation
kubectl get secrets --as=admin-user --as-group=system:masters

Auditing RBAC

Defenders should continuously review RBAC for risky grants.

  • Find subjects bound to cluster-admin.
  • Flag wildcard verbs/resources (*).
  • Detect secret-read and pod-create grants on non-admin accounts.
# Tools to audit RBAC
kubectl-who-can create pods
rbac-tool analysis
rakkess --as=system:serviceaccount:default:web

Hardening Service Accounts

Apply least privilege to identities.

  • Set automountServiceAccountToken: false where the pod needs no API access.
  • Give each workload a dedicated, minimally-scoped service account.
  • Avoid the default service account for real workloads.
  • Use short-lived projected tokens with audiences; rotate and bind them.
  • Never bind workloads to cluster-admin.

Testing RBAC Ethically

When assessing RBAC, prefer non-destructive checks (auth can-i, dry-run) over actually creating cluster-admin bindings on production. If you must prove escalation, scope it to a test namespace and remove any bindings or pods you created.

Report the exact roles and bindings that enabled escalation so they can be tightened.

Quick Check

Confirm your RBAC understanding.

Recap

You learned how RBAC and service accounts govern and threaten cluster access.

  • RBAC binds subjects to verbs on resources; cluster-admin is total control.
  • Pods mount SA tokens; auth can-i reveals their reach.
  • create-pods, binding, secret-read, and impersonate are escalation primitives.
  • Least-privilege accounts and disabled auto-mount harden the cluster.

Next: pod security and network policies.

Frequently asked questions

Is the “RBAC and Service Accounts” lesson free?

Yes — the full text of “RBAC and Service Accounts” is free to read here on the web, and the Cyber Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cyber Security Academy course, upgrade to CoddyKit PRO.

What will I learn in “RBAC and Service Accounts”?

Locking down cluster access. You practise Cyber Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cyber Security Academy?

No prior experience is required. Cyber Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “RBAC and Service Accounts” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cyber Security Academy lesson?

Yes. Every Cyber Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. Kubernetes Threat Model
  2. RBAC and Service Accounts
  3. Pod Security and Network Policies
  4. Securing the Supply Chain and Secrets
← Back to Cyber Security Academy