killvxk/auditing-kubernetes-cluster-rbac

审计 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 个月内未经审查。各团队反映能够访问其他团队的命名空间。

方法：

1. 列出所有 ClusterRoleBindings，识别向已认证用户授予广泛访问的绑定
2. 运行 kubectl rbac-tool who-can get secrets，查找跨命名空间可读取 secrets 的主体
3. 发现一个 ClusterRoleBinding 向 system:authenticated 授予 edit 权限，给予所有用户集群范围的写访问
4. 运行 KubiScan，识别具有高风险权限的服务账户和以提权服务账户运行的 Pod
5. 将 ClusterRoleBinding 替换为每个团队命名空间范围的 RoleBindings
6. 对不需要 API 访问的工作负载禁用 automountServiceAccountToken
7. 创建 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 个