3. RBAC 策略设计原则：最小权限、职责分离与默认拒绝
在 Kubernetes 平台的生命周期运维中，RBAC（基于角色的访问控制）是保障集群安全的第一道防线。错误的 RBAC 配置可能导致权限泄露、越权操作甚至集群瘫痪。本章围绕三个核心设计原则展开：最小权限原则、职责分离与默认拒绝策略。这三者共同构成了生产级 RBAC 策略的基石。
3.1 最小权限原则（Least Privilege）
最小权限原则要求每个用户、服务账户或组件只获得完成其任务所必需的最小权限集合。在 K8s 中，这意味着：
- 粒度控制：优先使用 Role（命名空间级别）而非 ClusterRole（集群级别）。
- 资源限定：明确指定可操作的资源类型（如 pods、deployments、secrets）和操作动词（get、list、create、update、delete）。
- 避免通配符：禁止使用
*通配符授予所有资源或所有操作的权限。
实践案例： 为 CI/CD 流水线服务账户仅授予
get、list、watch 权限，而非 create 或 delete，除非明确需要。
3.2 职责分离（Separation of Duties）
职责分离通过将敏感操作拆分为多个独立角色，防止单个用户或组件拥有过度集中的权限。在 K8s 平台运维中，常见的分离模型包括：
| 角色 | 典型权限范围 | 说明 |
|---|---|---|
| 集群管理员 | 节点管理、RBAC 策略配置、集群证书轮换 | 拥有最高权限，但操作受审计 |
| 命名空间管理员 | 命名空间内资源管理（Deployment、Service、ConfigMap） | 不能跨命名空间操作，不能修改 RBAC |
| 只读审计员 | 所有资源的 get、list、watch |
用于安全审计与合规检查 |
| 应用开发者 | 仅特定命名空间内的 Pod 日志查看、应用部署 | 不能访问 Secrets 或修改网络策略 |
设计建议： 在集群初始化阶段就定义好角色模板，避免后期临时创建导致权限混乱。每个角色应只对应一个明确的运维职责。
3.3 默认拒绝策略（Default Deny）
默认拒绝策略是 RBAC 的底层安全模型：任何未显式授予的权限，默认都是拒绝的。这意味着：
- 新建的用户或服务账户在绑定角色之前，没有任何操作权限。
- 删除或解绑某个 RoleBinding 后，对应的权限立即失效。
- 不需要像防火墙一样配置“拒绝规则”，只需管理“允许规则”。
常见误区： 不要创建“拒绝所有”的 ClusterRole 或 Role，因为 K8s RBAC 本身已经是默认拒绝。创建多余的拒绝规则只会增加策略复杂度，且可能因规则顺序导致意外放行。
3.4 三原则协同架构
下图展示了三个原则在 K8s RBAC 策略设计中的协同关系：
3.5 策略设计检查清单
在编写 RBAC 策略时，建议逐项核对以下清单：
- 角色定义：是否只使用了必要的资源和动词？是否避免了
*通配符？ - 绑定范围：是否优先使用 RoleBinding 而非 ClusterRoleBinding？
- 职责拆分：创建、更新、删除操作是否由不同角色承担？
- 默认拒绝验证：删除所有绑定后，用户是否确实失去所有权限？
- 审计准备：是否开启了 Kubernetes 审计日志？RBAC 变更是否可追溯？
生产建议： 使用
kubectl auth can-i --list --as=system:serviceaccount:namespace:sa-name 命令定期验证服务账户的实际权限，确保与设计意图一致。
3.6 常见 RBAC 设计反模式
| 反模式 | 风险描述 | 正确做法 |
|---|---|---|
使用 cluster-admin 绑定所有服务账户 |
任何被攻破的服务账户都能控制整个集群 | 为每个服务账户创建最小权限的 Role |
在 Role 中使用 resources: ["*"] |
意外授予对 Secrets、RBAC 等敏感资源的访问 | 明确列出所需资源类型 |
| 多个用户共享同一个服务账户 | 无法区分操作者，审计失效 | 每个用户或应用使用独立的 ServiceAccount |
| 未及时清理废弃的 RoleBinding | 离职人员或退役应用仍持有权限 | 定期审计并删除无效绑定 |
遵循最小权限、职责分离和默认拒绝三大原则，能够显著降低 K8s 集群的权限滥用风险，为后续的集群生命周期运维和发布包校验奠定坚实的安全基础。