1. RBAC 概述：什么是 RBAC、为什么 Kubernetes 需要 RBAC、RBAC 在云原生安全中的核心地位
1.1 什么是 RBAC
基于角色的访问控制（RBAC，Role-Based Access Control） 是一种将系统权限与“角色”而非“用户”直接绑定的授权机制。在 Kubernetes 中，RBAC 通过定义 Role / ClusterRole（权限集合）和 RoleBinding / ClusterRoleBinding（角色与主体的绑定关系），实现对 API 资源的细粒度访问控制。
核心公式： 谁（User / ServiceAccount / Group）+ 能做什么（动词：get, list, create, delete, update, patch, watch, …）+ 对什么资源（Pods, Deployments, Secrets, Nodes, …）+ 在哪个范围（Namespace / Cluster）。
Kubernetes RBAC 的四个核心 API 对象如下表所示：
| API 对象 | 作用域 | 说明 |
|---|---|---|
Role |
Namespace | 定义在单个命名空间内对资源的操作权限 |
ClusterRole |
Cluster | 定义集群级别资源（Nodes、PV、CSR）或跨命名空间资源的权限 |
RoleBinding |
Namespace | 将 Role 绑定到主体（User / Group / ServiceAccount），仅在该命名空间生效 |
ClusterRoleBinding |
Cluster | 将 ClusterRole 绑定到主体，在整个集群生效 |
关键区别： Role 只能引用同一命名空间内的资源；ClusterRole 可以引用集群范围资源（如 Nodes、PersistentVolumes），也可以被 RoleBinding 引用以实现跨命名空间的权限复用。
1.2 为什么 Kubernetes 需要 RBAC
Kubernetes 控制平面（API Server、etcd、Controller Manager、Scheduler）是整个集群的“大脑”。如果没有 RBAC，任何拥有 API Server 网络访问权限的客户端都可以执行任意操作，这将导致以下严重风险：
- 权限爆炸： 所有用户共享管理员凭据，无法追溯操作来源。
- 横向移动： 攻击者一旦获得一个 Pod 的访问权限，即可通过 ServiceAccount 操作整个集群。
- 数据泄露： Secrets、ConfigMaps 等敏感资源可以被任意读取。
- 合规缺失： 无法满足 SOC 2、PCI DSS、GDPR 等合规框架对最小权限原则的要求。
RBAC 通过以下机制解决上述问题：
- 最小权限原则： 只授予完成工作所必需的最小权限集合。
- 职责分离： 将集群管理员、命名空间管理员、只读用户、CI/CD 流水线等角色的权限严格隔离。
- 审计追溯： 结合 Kubernetes 审计日志，可以精确追踪每个 API 请求的主体、动作、资源和结果。
- 动态调整： 无需重启 API Server 即可通过 YAML 声明式地修改权限。
常见误区： 很多团队在集群初始化时使用
--authorization-mode=AlwaysAllow 或绑定 cluster-admin 角色到所有 ServiceAccount，这完全绕过了 RBAC 的保护。生产集群必须启用 --authorization-mode=Node,RBAC。
1.3 RBAC 在云原生安全中的核心地位
在云原生安全体系中，RBAC 是控制平面安全的第一道防线，也是纵深防御策略中“身份与访问管理”层的基石。下图展示了 RBAC 在 Kubernetes 安全架构中的位置：
RBAC 在云原生安全中的核心地位体现在以下三个维度：
| 安全维度 | RBAC 的作用 | 典型场景 |
|---|---|---|
| 身份与访问管理（IAM） | 作为 Kubernetes 原生的授权机制，与外部 IAM 系统（OIDC、LDAP、云厂商 IAM）集成 | 企业 SSO 登录后自动映射到 RBAC 角色 |
| 最小权限与零信任 | 确保每个 ServiceAccount 只拥有其工作负载所需的最小 API 权限 | CI/CD 流水线只允许在特定命名空间创建 Pod，不能读取 Secrets |
| 合规与审计 | 提供可声明的权限边界，配合审计日志实现权限使用的完整追溯 | SOC 2 审计要求证明“只有授权人员才能访问生产环境 Secrets” |
行业最佳实践： 根据 CNCF 2023 年云原生安全报告，超过 68% 的 Kubernetes 安全事件与 RBAC 配置不当直接相关。正确的 RBAC 基线配置是云原生安全审计中最优先的检查项。
1.4 RBAC 权限审计的必要性
即使启用了 RBAC，错误的配置仍然会导致严重的安全漏洞。常见的 RBAC 配置问题包括：
- 过度授权的 ClusterRole： 将
cluster-admin绑定到非管理员用户或 ServiceAccount。 - 通配符滥用： 使用
verbs: ["*"]或resources: ["*"]绕过细粒度控制。 - Secrets 权限泄露： 授予
get/listSecrets 的权限给普通应用 Pod。 - RoleBinding 作用域错误： 将本应限制在命名空间内的权限通过 ClusterRoleBinding 扩散到整个集群。
- 未清理的遗留绑定： 人员离职或服务下线后，对应的 RoleBinding 仍然存在。