用途
本技能用于审计 Kubernetes 集群的 RBAC(基于角色的访问控制)配置,识别权限过宽的角色、通配符权限、危险的 ClusterRoleBinding、服务账号令牌挂载以及特权容器等安全问题。
适用场景包括:
- 对 Kubernetes 集群(EKS、GKE、AKS 或自管理)进行安全评估
- 验证 RBAC 策略是否对用户和服务账号强制执行最小权限
- 调查集群内潜在的横向移动或权限提升
- 合规审计需要记录访问控制与权限
- 新团队接入共享集群时定义合适的 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 或提权能力的角色。使用 kubectl 获取 clusterroles 的 JSON 输出,并通过 Python 脚本筛选:
- 通配符 verb 或 resource 的角色
- 可读取 secrets 的角色
- 具有 pods/exec 权限的角色(容器逃逸风险)
步骤 2:审计 ClusterRoleBindings 和 RoleBindings
审查绑定以识别谁拥有高权限访问,并检测过宽的用户组分配:
- 列出所有 ClusterRoleBindings 及其 subjects
- 查找绑定到 cluster-admin 的绑定
- 查找授予所有已认证用户访问权限的绑定(system:authenticated、system:unauthenticated)
步骤 3:使用 rbac-tool 进行全面分析
使用 rbac-tool 进行自动化 RBAC 分析,包括 who-can 查询和策略生成:
kubectl rbac-tool who-can get secretskubectl rbac-tool who-can create podskubectl rbac-tool who-can create pods/execkubectl rbac-tool who-can bind clusterroleskubectl rbac-tool who-can escalate clusterroleskubectl rbac-tool analysiskubectl rbac-tool viz --outformat dot > rbac-graph.dot
步骤 4:运行 KubiScan 检测风险权限
使用 KubiScan 自动识别有风险的服务账号、Pod 和 RBAC 配置:
python3 -m kubiscan -rroles列出有风险的 Rolespython3 -m kubiscan -rcr列出有风险的 ClusterRolespython3 -m kubiscan -rrb列出有风险的 RoleBindingspython3 -m kubiscan -rcrb列出有风险的 ClusterRoleBindingspython3 -m kubiscan -rs有风险的服务账号python3 -m kubiscan -rp有风险的 Podpython3 -m kubiscan -pe权限提升向量python3 -m kubiscan -a执行所有检查
步骤 5:审计服务账号令牌挂载与使用
检查不必要的服务账号令牌挂载,这些挂载可能使受损 Pod 实现横向移动:
- 查找自动挂载服务账号令牌的 Pod
- 查找具有非默认令牌 secret 的服务账号
- 检查以特权或主机访问运行的 Pod
步骤 6:运行 Kubeaudit 进行 RBAC 与安全策略验证
执行 Kubeaudit 进行全面安全检查,包括 RBAC 相关发现:
kubeaudit all --kubeconfig ~/.kube/configkubeaudit privesc检查 allowPrivilegeEscalationkubeaudit rootfs检查 readOnlyRootFilesystemkubeaudit nonroot检查 runAsNonRootkubeaudit capabilities检查危险 capabilities- 输出 JSON:
kubeaudit all --kubeconfig ~/.kube/config -f json > kubeaudit-results.json
关键概念
- RBAC:Kubernetes 中基于角色的访问控制,根据用户或服务账号的角色调节对集群资源的访问。
- ClusterRole:集群范围的角色定义,指定适用于所有命名空间的权限(对资源的 verb)。
- ClusterRoleBinding:在集群范围将 ClusterRole 与 subjects(用户、组、服务账号)关联。
- Service Account:与 Pod 关联的身份,用于向 Kubernetes API 服务器认证,除非禁用否则自动挂载。
- automountServiceAccountToken:Pod spec 字段,控制是否将服务账号令牌自动挂载到 Pod 文件系统。
- Privilege Escalation:RBAC verb(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 的 subjects - 发现一个 ClusterRoleBinding 将 edit 授予 system:authenticated,使所有用户拥有集群范围的写权限
- 运行 KubiScan 识别具有风险权限的服务账号和以高权限服务账号运行的 Pod
- 用每个团队的命名空间范围 RoleBindings 替换该 ClusterRoleBinding
- 对不需要 API 访问的工作负载禁用 automountServiceAccountToken
- 创建 NetworkPolicy 隔离团队之间的命名空间流量
陷阱:移除 ClusterRoleBindings 可能破坏依赖集群范围访问的 CI/CD 流水线和 operator。移除前务必审计哪些工作负载使用了这些绑定。EKS 通过 aws-auth ConfigMap 将 IAM 角色映射到 Kubernetes 组,因此 RBAC 变更必须与 IAM 角色映射协调。
输出格式
审计报告包含:集群信息、审计日期、命名空间数量、RBAC 清单(ClusterRoles、ClusterRoleBindings、Roles、RoleBindings、Service Accounts 数量)、关键发现(如授予 system:authenticated edit 权限、通配符权限的自定义 ClusterRole)、摘要(cluster-admin 主体数量、通配符权限角色数量、可访问 secret 的服务账号数量、自动挂载令牌的 Pod 数量、特权容器数量)。
限制
本技能不适用于网络策略审计、容器镜像扫描或运行时安全监控。使用前需确保具备相应权限和工具。具体收费、价格、平台支持等信息暂未提供。