Kubernetes Attack Paths: RBAC, Tokens and Identity
From one RBAC verb to cluster control, plus ServiceAccount tokens, registry credentials, workload identity and admission webhooks that run before a pod exists.
Kubernetes authorization is granular enough that a single verb on a single resource can be the whole finding. These notes follow the verb to the identity it reaches.
Kubernetes RBAC Abuse
In Kubernetes, create pods can be more valuable than get secrets depending on the namespace. RBAC combines subject, verb, resource and scope. The impact of one permission appears in the relationships it can create afterward. Verbs such as bind, escalate and impersonate are especially sensitive. create, patch and update on workloads may also lead to stronger ServiceAccounts. I use kubectl auth can-i and inspect RoleBindings and ClusterRoleBindings before creating any object. A ClusterRole does not automatically mean cluster-wide access. A RoleBinding can reference a ClusterRole while keeping the grant inside one namespace.
1
2
kubectl auth can-i --list
kubectl get rolebindings,clusterrolebindings -A
Kubernetes Secrets and ServiceAccount Tokens
A shell inside a Pod may be only a shell or it may carry the workload identity inside the filesystem. Projected ServiceAccount tokens are short-lived, workload-bound and rotated. Traditional Secrets may hold passwords, registry credentials and keys encoded in Base64. Read access to Secrets is sensitive. Pod creation may also allow mounting a Secret or stronger ServiceAccount when policy permits it. I inspect mounts, token audience, namespace, RBAC and which Secrets the identity can read before copying any data. Base64 is not encryption. Encryption at rest protects etcd but does not stop an authorized subject from retrieving the Secret through the API.
1
2
ls -la /var/run/secrets/kubernetes.io/serviceaccount/
kubectl auth can-i get secrets -n app
Container Registry Attacks
Anyone able to replace the right image does not need to exploit the production server. Deployment does the work automatically. Registries store manifests, layers, tags and metadata. Authorization may allow pull, push, delete or repository administration. Mutable tags such as latest create trust in a name that may point to a different digest later. CI credentials and robot accounts expand the surface. I map registries, repositories, permissions and whether deployment pins a digest or only a tag. Push tests use lab namespaces. Image signing and admission policy can block unapproved artifacts. Vulnerability scanning does not catch a malicious image signed by the wrong identity.
1
2
docker manifest inspect registry.example.test/team/app:latest
crane digest registry.example.test/team/app:latest
Kubernetes Workload Identity and Cloud Pivots
A ServiceAccount with minimal RBAC may still become a powerful cloud identity when the cluster federates it into AWS, Azure or GCP. EKS IRSA, Azure Workload Identity and GKE Workload Identity connect Kubernetes identity to cloud IAM without static secrets. OIDC claims, ServiceAccount annotations and trust policies define which workload may obtain which cloud role or principal. I inspect the ServiceAccount, projected-token audience and provider trust before requesting cloud credentials. Least privilege needs to exist on both sides. Tight Kubernetes RBAC does not compensate for a broad cloud IAM role attached to the same Pod.
1
2
3
kubectl get sa -n app app-sa -o yaml
python3 -c 'import base64,sys;s=sys.stdin.read().strip().split(".")[1];print(base64.urlsafe_b64decode(s+"="*(-len(s)%4)).decode())' \
< /var/run/secrets/kubernetes.io/serviceaccount/token
Kubernetes Admission Controllers and Webhooks
Between kubectl apply and object persistence, admission controllers can reject or modify the request. That creates its own trust boundary. MutatingAdmissionWebhook changes objects. ValidatingAdmissionWebhook decides whether they are admitted. Configuration defines rules, selectors and failurePolicy. A compromised webhook may inject sidecars, change images, add mounts or block workloads. Availability also depends on failurePolicy. I enumerate webhook configurations, service endpoints, CA bundles, selectors and who may edit those objects. failurePolicy: Ignore favors availability and may reduce enforcement during failures. Fail increases operational dependence on the webhook.
1
kubectl get mutatingwebhookconfigurations,validatingwebhookconfigurations -o yaml