Pods, Services, and RBAC
Every pod carries a token, and RBAC decides how far that token gets you.
What you will learn
- -Read the service account token mounted into a pod
- -Explain how RBAC binds subjects to verbs on resources
- -Enumerate your own permissions before you burn a payload
The first thing to check after you land in a is what you are already holding. mounts a into almost every pod by default, at /var/run/secrets/kubernetes.io/serviceaccount/. That has three files: token, ca.crt, and namespace. The token is a the pod uses to authenticate to the . You did not steal it. It was handed to you the moment the pod started.
Whether that token is worth anything depends entirely on .
What RBAC actually says
Role-based access in Kubernetes is four object types and one simple sentence: this subject can perform these verbs on these resources. Nothing more clever than that.
A Role or ClusterRole is a list of permissions. Verbs like get, list, watch, create, delete, on resources like pods, secrets, deployments. A Role is namespaced. A ClusterRole applies -wide.
A RoleBinding or ClusterRoleBinding attaches that permission list to a subject: a user, a group, or a service account. No binding means no access, even if the Role exists. The binding is the wire that connects the token to the power.
So the question is never "what can this pod do" in the abstract. It is "which service account is this pod running as, and what bindings point at that account."
Read your own token
Pull the token and decode the middle segment of the JWT to see who you are.
$cat /var/run/secrets/kubernetes.io/serviceaccount/token$cat /var/run/secrets/kubernetes.io/serviceaccount/namespace$TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token); echo $TOKEN | cut -d. -f2 | base64 -d 2>/dev/nullThe sub looks like system:serviceaccount:prod:build-runner. That tells you the is prod and the account is build-runner. Now you know whose permissions to enumerate.
Ask the API what you can do
Do not guess at your rights by trying random verbs and watching for 403s. Kubernetes gives you a built-in way to ask. kubectl auth can-i queries the authorizer directly.
$kubectl auth can-i --list$kubectl auth can-i create pods$kubectl auth can-i get secrets --namespace prodStripped rarely ship kubectl. You can hit the API server directly. Set the server from the KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT env vars, pass the token as a bearer , and trust the mounted ca.crt: curl --cacert ca.crt -H "Authorization: Bearer $TOKEN" https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$NS/secrets. Same , no binary needed.
Services are the map, not the lock
A Service is just a stable name and virtual IP that load-balances to a set of pods. It does not authenticate anyone. When you list services you are reading a directory of everything reachable inside the cluster : databases, internal APIs, admin panels that assume nobody hostile is on the pod network.
$kubectl get services --all-namespacesThe pattern that keeps working: enumerate first, act second. A token that can list secrets in one namespace is a straight line to credentials. A token that can create pods is a straight line to access, which is the next lesson.
Enumerating RBAC and reading tokens is still touching a live authorization . Do it only inside clusters you own or have written to test. Every can-i and every read is logged by the API server backend.
A ClusterRole named secret-reader grants get and list on secrets, but your token gets 403 when you read one. What is the most likely reason?
You have shell in a pod with kubectl available. Write the single command that lists every action your current service account token is permitted to take, so you can plan an escalation path without triggering a wall of 403 errors.