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：枚举具有高危权限的 ClusterRole 和 Role

识别包含通配符权限、Secret 访问权限、Pod exec 权限或权限提升能力的角色。

# 列出所有具有通配符动词权限的 ClusterRole
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: {verbs}')
            print(f'  Resources: {resources}')
            print(f'  API Groups: {rule.get("apiGroups", [])}')
            print()
"

# 查找可读取 Secret 的角色
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} -> can access secrets (verbs: {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} -> has pods/exec access')
"

步骤 2：审计 ClusterRoleBinding 和 RoleBinding

审查绑定关系，识别拥有高权限访问的主体，并检测范围过宽的组分配。

# 列出所有 ClusterRoleBinding 及其绑定主体
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', 'cluster-wide')
        print(f'{name} -> Role: {role} | {kind}: {subj_name} ({ns})')
" | sort

# 查找绑定至 cluster-admin 的 ClusterRoleBinding
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: {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"WARNING: {binding['metadata']['name']} grants {binding['roleRef']['name']} to {subject['name']}")
"

步骤 3：使用 rbac-tool 进行全面分析

利用 rbac-tool 自动化执行 RBAC 分析，包括 who-can 查询及策略生成。

# 查询跨所有命名空间可读取 Secret 的主体
kubectl rbac-tool who-can get secrets

# 查询可创建 Pod 的主体（存在容器逃逸风险）
kubectl rbac-tool who-can create pods

# 查询可 exec 进入 Pod 的主体
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 自动识别存在风险的服务账户、Pod 及 RBAC 配置。

# 运行 KubiScan 查找高危 Role
python3 -m kubiscan -rroles   # 列出高危 Role
python3 -m kubiscan -rcr      # 列出高危 ClusterRole
python3 -m kubiscan -rrb      # 列出高危 RoleBinding
python3 -m kubiscan -rcrb     # 列出高危 ClusterRoleBinding

# 查找高危服务账户
python3 -m kubiscan -rs       # 高危服务账户

# 查找使用高危服务账户运行的 Pod
python3 -m kubiscan -rp       # 高危 Pod

# 检查权限提升路径
python3 -m kubiscan -pe       # 权限提升向量

# 生成完整审计报告
python3 -m kubiscan -a        # 执行全部检查项

步骤 5：审计服务账户 Token 的挂载与使用情况

检查是否存在不必要的服务账户 Token 挂载，此类配置可能在 Pod 被攻陷后导致横向移动。

# 查找启用自动挂载服务账户 Token 的 Pod
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} (token auto-mounted)')
"

# 查找绑定非默认 Token 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(s) bound')
"

# 检查以特权模式运行或具有主机访问能力的 Pod
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'RISK: {ns}/{name}/{container["name"]} - privileged={sc.get("privileged",False)} runAsRoot={sc.get("runAsUser","not set")==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

核心概念

工具与系统

• kubectl：查询 Kubernetes RBAC 资源（角色、绑定、服务账户）的主要命令行工具
• rbac-tool：kubectl 插件，支持 RBAC 分析，包括 who-can 查询、关系图可视化和策略生成
• KubiScan：Python 工具，用于扫描 Kubernetes RBAC 中的高危权限及权限提升路径
• Kubeaudit：安全审计工具，检查 Pod 和工作负载中违反安全最佳实践的行为，包括 RBAC 相关问题
• rakkess：kubectl 插件，展示当前用户对所有资源类型的访问矩阵

常见场景

场景：对多个开发团队共用的 EKS 集群进行审计

背景：一个共享 EKS 集群服务于四个开发团队。RBAC 在初始部署时配置完成，但过去 12 个月未进行复核。各团队反馈称可访问其他团队的命名空间。

应对方法：

1. 列出全部 ClusterRoleBinding，识别向 system:authenticated 等宽泛主体授予权限的绑定
2. 运行 kubectl rbac-tool who-can get secrets，查找可在跨命名空间读取 Secret 的主体
3. 发现某 ClusterRoleBinding 将 edit 角色授予 system:authenticated，导致所有用户获得全集群写权限
4. 运行 KubiScan，识别具有高危权限的服务账户以及使用高权限服务账户运行的 Pod
5. 将该 ClusterRoleBinding 替换为每个团队专属的命名空间级 RoleBinding
6. 对无需访问 Kubernetes API 的工作负载，禁用 automountServiceAccountToken
7. 创建 NetworkPolicy，隔离各团队命名空间间的网络通信

注意事项：移除 ClusterRoleBinding 可能破坏依赖集群范围权限的 CI/CD 流水线和 Operator。在删除前，务必审计哪些工作负载实际使用了这些绑定。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
  影响：所有已认证用户均可在全部命名空间中执行编辑操作
  风险：任意用户均可修改任一命名空间中的资源
  整改建议：替换为按团队划分的命名空间级 RoleBinding

[RBAC-002] 自定义 ClusterRole 包含通配符权限
  ClusterRole 名称：developer-admin
  规则：verbs=["*"], resources=["*"], apiGroups=["*"]
  绑定主体：4 名用户（通过 developer-admin-binding）
  风险：功能等效于 cluster-admin，仅名称不同
  整改建议：限定为实际所需的具体资源与动词

汇总统计：
  拥有 cluster-admin 权限的主体：6 个（建议：≤ 3 个）
  含通配符权限的角色：4 个
  具备 Secret 访问权限的服务账户：12 个
  启用自动挂载 Token 的 Pod：45 / 67
  特权容器：8 个