killvxk 审计 Kubernetes 集群 RBAC
适用场景
- 对 Kubernetes 集群（EKS、GKE、AKS 或自管理）进行安全评估时
- 验证 RBAC 策略是否对用户和服务账户强制执行最小权限时
- 调查 Kubernetes 集群内的潜在横向移动或权限提升时
- 合规审计需要记录访问控制和权限时
- 将新团队加入共享集群并定义适当 RBAC 策略时
不适用于：网络策略审计（使用 Cilium 或 Calico 网络策略工具）、容器镜像扫描（使用 Trivy 或 Grype），或运行时安全监控（使用 Falco 或 Sysdig Secure）。
前置条件
- kubectl 配置了 cluster-admin 或等效的目标集群读取权限
- 安装 rbac-tool（
kubectl krew install rbac-tool或从 GitHub 下载二进制文件） - 安装 KubiScan（
pip install kubiscan） - 安装 Kubeaudit（
brew install kubeaudit或从 GitHub releases 下载） - 访问集群审计日志，用于将 RBAC 发现与实际 API 访问相关联
工作流程
步骤 1：枚举具有危险权限的 ClusterRoles 和 Roles
识别具有通配符权限、Secret 访问权限、pod exec 权限或提权能力的角色。
# 列出所有具有通配符动词访问的 ClusterRoles
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
name = role['metadata']['name']
for rule in role.get('rules', []):
verbs = rule.get('verbs', [])
resources = rule.get('resources', [])
if '*' in verbs or '*' in resources:
print(f'ClusterRole: {name}')
print(f' 动词: {verbs}')
print(f' 资源: {resources}')
print(f' API 组: {rule.get(\"apiGroups\", [])}')
print()
"
# 查找可读取 Secrets 的角色
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
name = role['metadata']['name']
for rule in role.get('rules', []):
resources = rule.get('resources', [])
verbs = rule.get('verbs', [])
if ('secrets' in resources or '*' in resources) and ('get' in verbs or 'list' in verbs or '*' in verbs):
if not name.startswith('system:'):
print(f'ClusterRole: {name} -> 可访问 secrets（动词: {verbs}）')
"
# 查找具有 pod/exec 权限的角色（容器逃逸风险）
kubectl get clusterroles -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for role in data['items']:
name = role['metadata']['name']
for rule in role.get('rules', []):
resources = rule.get('resources', [])
if 'pods/exec' in resources or 'pods/*' in resources:
print(f'ClusterRole: {name} -> 具有 pods/exec 访问权限')
"
步骤 2：审计 ClusterRoleBindings 和 RoleBindings
审查绑定以识别具有提升访问权限的主体，并检测过于宽泛的组分配。
# 列出所有 ClusterRoleBindings 及其主体
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for binding in data['items']:
name = binding['metadata']['name']
role = binding['roleRef']['name']
subjects = binding.get('subjects', [])
for subject in subjects:
kind = subject.get('kind', '')
subj_name = subject.get('name', '')
ns = subject.get('namespace', '集群范围')
print(f'{name} -> 角色: {role} | {kind}: {subj_name} ({ns})')
" | sort
# 查找绑定到 cluster-admin 的主体
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for binding in data['items']:
if binding['roleRef']['name'] == 'cluster-admin':
print(f\"绑定: {binding['metadata']['name']}\")
for subject in binding.get('subjects', []):
print(f\" {subject.get('kind')}: {subject.get('name')} (ns: {subject.get('namespace', 'N/A')})\")
"
# 查找授予所有已认证用户访问权限的绑定
kubectl get clusterrolebindings -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for binding in data['items']:
for subject in binding.get('subjects', []):
if subject.get('name') in ['system:authenticated', 'system:unauthenticated']:
print(f\"警告: {binding['metadata']['name']} 向 {subject['name']} 授予 {binding['roleRef']['name']}\")
"
步骤 3：使用 rbac-tool 进行综合分析
使用 rbac-tool 进行自动化 RBAC 分析，包括 who-can 查询和策略生成。
# 谁可以跨所有命名空间获取 secrets
kubectl rbac-tool who-can get secrets
# 谁可以创建 pods（容器逃逸的潜在途径）
kubectl rbac-tool who-can create pods
# 谁可以 exec 进入 pods
kubectl rbac-tool who-can create pods/exec
# 谁可以提升权限（bind/escalate 动词）
kubectl rbac-tool who-can bind clusterroles
kubectl rbac-tool who-can escalate clusterroles
# 生成 RBAC 策略报告
kubectl rbac-tool analysis
# 可视化 RBAC 关系
kubectl rbac-tool viz --outformat dot > rbac-graph.dot
dot -Tpng rbac-graph.dot -o rbac-graph.png
步骤 4：运行 KubiScan 检测高风险权限
使用 KubiScan 自动识别高风险服务账户、Pods 和 RBAC 配置。
# 运行 KubiScan 查找高风险 Roles
python3 -m kubiscan -rroles # 列出高风险 Roles
python3 -m kubiscan -rcr # 列出高风险 ClusterRoles
python3 -m kubiscan -rrb # 列出高风险 RoleBindings
python3 -m kubiscan -rcrb # 列出高风险 ClusterRoleBindings
# 查找高风险服务账户
python3 -m kubiscan -rs # 高风险服务账户
# 查找运行高风险服务账户的 Pods
python3 -m kubiscan -rp # 高风险 Pods
# 检查权限提升路径
python3 -m kubiscan -pe # 权限提升向量
# 生成完整报告
python3 -m kubiscan -a # 所有检查
步骤 5：审计服务账户令牌挂载和使用
检查不必要的服务账户令牌挂载，这些挂载可能使遭受入侵的 Pod 实现横向移动。
# 查找自动挂载服务账户令牌的 Pods
kubectl get pods --all-namespaces -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for pod in data['items']:
name = pod['metadata']['name']
ns = pod['metadata']['namespace']
sa = pod['spec'].get('serviceAccountName', 'default')
automount = pod['spec'].get('automountServiceAccountToken', True)
if automount and sa != 'default':
print(f'{ns}/{name} -> SA: {sa}（令牌已自动挂载）')
"
# 查找具有非默认令牌 Secret 的服务账户
kubectl get serviceaccounts --all-namespaces -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for sa in data['items']:
name = sa['metadata']['name']
ns = sa['metadata']['namespace']
secrets = sa.get('secrets', [])
if name != 'default' and len(secrets) > 0:
print(f'{ns}/{name}: 绑定了 {len(secrets)} 个 secret')
"
# 检查以特权方式运行或具有主机访问权限的 Pods
kubectl get pods --all-namespaces -o json | python3 -c "
import json, sys
data = json.load(sys.stdin)
for pod in data['items']:
name = pod['metadata']['name']
ns = pod['metadata']['namespace']
for container in pod['spec'].get('containers', []):
sc = container.get('securityContext', {})
if sc.get('privileged', False) or sc.get('runAsUser', 1) == 0:
print(f'风险: {ns}/{name}/{container[\"name\"]} - 特权={sc.get(\"privileged\",False)} 以root运行={sc.get(\"runAsUser\",\"未设置\")==0}')
"
步骤 6：运行 Kubeaudit 进行 RBAC 和安全策略验证
执行 Kubeaudit 进行全面安全检查，包括 RBAC 相关发现。
# 运行所有 kubeaudit 检查
kubeaudit all --kubeconfig ~/.kube/config
# 运行特定的 RBAC 相关检查
kubeaudit privesc # 检查 allowPrivilegeEscalation
kubeaudit rootfs # 检查 readOnlyRootFilesystem
kubeaudit nonroot # 检查 runAsNonRoot
kubeaudit capabilities # 检查危险的 capabilities
# 输出为 JSON 格式以便处理
kubeaudit all --kubeconfig ~/.kube/config -f json > kubeaudit-results.json
核心概念
| 术语 | 定义 |
|---|---|
| RBAC | Kubernetes 中的基于角色的访问控制（Role-Based Access Control），一种根据个人用户或服务账户的角色来规范集群资源访问的方法 |
| ClusterRole | 集群范围的角色定义，指定适用于所有命名空间的权限（资源上的动词） |
| ClusterRoleBinding | 在集群范围内将 ClusterRole 与主体（用户、组、服务账户）关联 |
| 服务账户（Service Account） | 与 Pod 关联的身份，用于向 Kubernetes API Server 认证，除非禁用否则自动挂载 |
| automountServiceAccountToken | Pod 规范字段，控制服务账户令牌是否自动挂载到 Pod 文件系统中 |
| 权限提升（Privilege Escalation） | RBAC 动词（bind、escalate、impersonate），允许用户向自己或他人授予提升的权限 |
工具与系统
- kubectl：查询 Kubernetes RBAC 资源（角色、绑定、服务账户）的主要 CLI
- rbac-tool：kubectl 插件，用于 RBAC 分析，包括 who-can 查询、可视化和策略生成
- KubiScan：Python 工具，用于扫描 Kubernetes RBAC 中的高风险权限和权限提升路径
- Kubeaudit：安全审计工具，检查 Pod 和工作负载的安全反模式，包括 RBAC 问题
- rakkess：kubectl 插件，显示当前用户对所有资源类型的访问矩阵
常见场景
场景：审计多个开发团队共享的 EKS 集群
场景背景：一个共享 EKS 集群服务于四个开发团队。RBAC 在初始设置时配置，12 个月内未经审查。各团队反映能够访问其他团队的命名空间。
方法：
- 列出所有 ClusterRoleBindings，识别向已认证用户授予广泛访问的绑定
- 运行
kubectl rbac-tool who-can get secrets，查找跨命名空间可读取 secrets 的主体 - 发现一个 ClusterRoleBinding 向
system:authenticated授予edit权限，给予所有用户集群范围的写访问 - 运行 KubiScan，识别具有高风险权限的服务账户和以提权服务账户运行的 Pod
- 将 ClusterRoleBinding 替换为每个团队命名空间范围的 RoleBindings
- 对不需要 API 访问的工作负载禁用 automountServiceAccountToken
- 创建 NetworkPolicy 隔离各团队之间的命名空间流量
常见陷阱：移除 ClusterRoleBindings 可能会破坏依赖集群范围访问的 CI/CD 流水线和 Operators。移除前务必审计哪些工作负载使用了这些绑定。EKS 通过 aws-auth ConfigMap 将 IAM 角色映射到 Kubernetes 组，因此 RBAC 变更必须与 IAM 角色映射协调。
输出格式
Kubernetes RBAC 审计报告
===============================
集群: production-eks (EKS 1.28)
审计日期: 2026-02-23
命名空间: 12 个
RBAC 资源清单:
ClusterRoles: 48 个（18 个自定义，30 个系统）
ClusterRoleBindings: 32 个（12 个自定义，20 个系统）
Roles（命名空间级）: 24 个
RoleBindings（命名空间级）: 36 个
服务账户: 67 个
严重发现:
[RBAC-001] ClusterRoleBinding 向 system:authenticated 授予 edit 权限
绑定: authenticated-edit
影响: 所有已认证用户在所有命名空间中具有 edit 访问权限
风险: 任何用户均可修改任意命名空间中的资源
修复: 按团队替换为命名空间范围的 RoleBindings
[RBAC-002] 具有通配符权限的自定义 ClusterRole
ClusterRole: developer-admin
规则: verbs=["*"], resources=["*"], apiGroups=["*"]
绑定: 通过 developer-admin-binding 绑定 4 个用户
风险: 等效于 cluster-admin，只是名称不同
修复: 缩减到所需的特定资源和动词
摘要:
具有 cluster-admin 权限的主体: 6 个（建议: <= 3 个）
具有通配符权限的角色: 4 个
可访问 Secret 的服务账户: 12 个
自动挂载令牌的 Pods: 45 / 67
特权容器: 8 个