Listen to this Post
Introduction:
OWASP’s Broken Access Control remains the top web application security risk in 2025, and Kubernetes environments are particularly vulnerable when improperly configured. A critical misconfiguration allows attackers with limited permissions to escalate privileges by creating service account tokens through secret manipulation, bypassing intended security controls. This exploit demonstrates how legacy Kubernetes features, when left enabled, can create devastating authorization bypasses in modern container orchestration platforms.
Learning Objectives:
- Understand the Kubernetes service account token vulnerability and its security implications
- Learn to detect and exploit broken access control in misconfigureded clusters
- Implement proper hardening measures to disable legacy token mechanisms
You Should Know:
1. The Kubernetes Service Account Token Exploitation Vector
The vulnerability arises from Kubernetes’ legacy handling of service account tokens. When users have permission to create secrets but not explicit token creation rights, they can indirectly generate service account tokens by creating secrets of type ‘kubernetes.io/service-account-token’. The control plane automatically populates these secrets with valid JWT tokens, enabling privilege escalation and service account impersonation.
Step-by-step exploitation:
Check current permissions
kubectl auth can-i create token
kubectl auth can-i create secrets
Create a malicious secret leveraging the legacy token mechanism
kubectl create secret generic malicious-token \
--type=kubernetes.io/service-account-token \
--from-literal=annotation=value
Extract the generated token
kubectl get secret malicious-token -o jsonpath='{.data.token}' | base64 -d
Use the token for authentication
kubectl --token=$EXTRACTED_TOKEN get pods
2. Detecting Vulnerable Cluster Configurations
Identifying clusters with legacy token mechanisms enabled requires comprehensive security scanning. The vulnerability exists when the API server runs without the critical security flag disabling legacy service account tokens.
Step-by-step detection:
Check API server flags on control plane nodes ps aux | grep kube-apiserver | grep -v grep Look for missing security parameter CRITICAL: --disable-legacy-service-account-token=true should be present VULNERABLE: Parameter missing or set to false Verify using kubectl if cluster access available kubectl get secrets --all-namespaces -o json | jq '.items[] | select(.type=="kubernetes.io/service-account-token")' Check service account token automount settings kubectl get serviceaccount default -o yaml kubectl get pod <pod-name> -o yaml | grep automountServiceAccountToken
3. Modern Kubernetes TokenRequest API Implementation
Kubernetes now recommends using the TokenRequest API with short-lived tokens and projected volumes. This approach provides better security through token expiration and reduced attack surface.
Step-by-step secure implementation:
apiVersion: v1 kind: Pod metadata: name: secure-pod spec: containers: - name: app image: nginx volumeMounts: - name: token-volume mountPath: /var/run/secrets/tokens serviceAccountName: default volumes: - name: token-volume projected: sources: - serviceAccountToken: path: token expirationSeconds: 3600 1 hour validity audience: api
4. Hardening Kubernetes API Server Configuration
Proper cluster hardening requires disabling legacy features and implementing security best practices at the API server level.
Step-by-step hardening guide:
Edit API server manifest (location varies by installation method) sudo vi /etc/kubernetes/manifests/kube-apiserver.yaml Add critical security parameters spec: containers: - command: - kube-apiserver - --disable-legacy-service-account-token=true - --service-account-issuer=https://kubernetes.default.svc.cluster.local - --service-account-signing-key-file=/etc/kubernetes/pki/sa.key - --service-account-api-audiences=api Restart API server (if managed manually) sudo systemctl restart kubelet Verify configuration kubectl get pods -n kube-system | grep apiserver
5. RBAC Configuration to Prevent Token Manipulation
Implement least privilege access control to prevent secret creation abuse while maintaining operational functionality.
Step-by-step RBAC hardening:
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: restricted-secret-creator rules: - apiGroups: [""] resources: ["secrets"] verbs: ["create"] resourceNames: [] Empty means no specific secret names allowed apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: restricted-secret-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: restricted-secret-creator subjects: - kind: User name: restricted-user apiGroup: rbac.authorization.k8s.io
6. Continuous Security Monitoring and Auditing
Implement ongoing security validation to detect configuration drift and potential exploitation attempts.
Step-by-step monitoring setup:
Install kube-bench for CIS benchmarking kubectl apply -f job.yaml kubectl logs job/kube-bench Set up automated scanning with kubectl and jq kubectl get secrets --all-namespaces -o json | jq -r '.items[] | select(.type=="kubernetes.io/service-account-token") | "Found legacy token: (.metadata.namespace)/(.metadata.name)"' Create continuous monitoring cron job kubectl create cronjob token-audit --image=bitnami/kubectl --schedule="0 " -- \ /bin/sh -c "kubectl get secrets -A -o json | jq '.items[] | select(.type==\"kubernetes.io/service-account-token\")' | wc -l"
7. Emergency Response and Token Revocation
When exploitation is detected, immediate response procedures must be implemented to contain the breach.
Step-by-step incident response:
Identify compromised tokens and service accounts kubectl get secrets --field-selector type=kubernetes.io/service-account-token --all-namespaces Immediately delete malicious tokens kubectl delete secret malicious-token Rotate service account tokens kubectl delete secret --field-selector type=kubernetes.io/service-account-token -n default Revoke Kubernetes API credentials Locate and update kubeconfig files Rotate CA certificates if widespread compromise detected kubeadm certs renew all
What Undercode Say:
- Legacy features in modern platforms create invisible security debt that attackers actively exploit
- The principle of least privilege must extend to indirect permission pathways and API interactions
- Cloud-native security requires continuous validation, not just initial configuration
The persistence of OWASP Broken Access Control at the top of security risks highlights how authorization vulnerabilities transcend traditional web applications and permeate cloud-native infrastructure. Kubernetes’ complexity creates hidden attack vectors where seemingly innocuous permissions can be chained into full cluster compromise. This specific vulnerability demonstrates that security teams must not only understand application-level access control but also the intricate permission models of underlying platforms. The maintenance of legacy features for backward compatibility often becomes the weakest link in security chains, requiring proactive disabling and continuous monitoring.
Prediction:
As Kubernetes adoption continues accelerating, similar legacy feature exploits will emerge across cloud-native ecosystems, forcing organizations to implement more sophisticated runtime security measures. We’ll see increased automation in both attack and defense, with AI-driven security tools becoming essential for detecting complex permission abuse patterns. Regulatory frameworks will eventually mandate specific container security configurations, making proper API server hardening a compliance requirement rather than just a security best practice.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Marjansterjev Owasp – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
