2. 权限矩阵设计原则：最小权限原则、职责分离、权限分层模型

在生产级 Kubernetes 集群中，RBAC 权限矩阵的设计直接决定了系统的安全基线与运维效率。本章聚焦三大核心设计原则——最小权限原则、职责分离、权限分层模型，并结合后端权限矩阵的典型场景，给出可落地的设计方法与性能考量。

2.1 最小权限原则：从“默认拒绝”开始

最小权限原则要求每个主体（用户、ServiceAccount、Pod）只拥有完成其任务所必需的最小权限集合。在 RBAC 中，这意味着：

• 默认拒绝：不创建任何宽泛的 cluster-admin 或 *:* 规则。
• 按需授予：仅对特定资源、特定动词（get/list/watch/create/update/patch/delete）授权。
• 资源粒度：优先使用 resourceNames 字段限定到具体资源实例。

2.2 职责分离：三权分立模型

职责分离将集群管理权限拆分为互斥的角色，防止单一账户拥有过度集中的权力。推荐的后端权限矩阵职责分离模型如下：

2.3 权限分层模型：集群级 → 命名空间级 → 资源级

Kubernetes RBAC 天然支持三层权限模型。设计权限矩阵时，应按照“从宽到窄”的层次逐级收敛权限范围。

2.4 分层设计的最佳实践

在实际后端权限矩阵设计中，建议遵循以下分层策略：

• 集群级：只授予基础设施团队和监控系统。规则数量控制在 10 条以内，避免鉴权性能下降。
• 命名空间级：作为默认授权层级。每个命名空间独立管理 Role 和 RoleBinding，实现租户隔离。
• 资源级：用于敏感资源（如 Secret、PVC）或需要细粒度控制的 CI/CD 流水线。

2.5 权限矩阵设计对照表

以下表格对比了三种分层模型在典型场景下的设计差异：

2.6 实战案例：构建后端微服务权限矩阵

假设有一个后端微服务集群，包含三个命名空间：production、staging、monitoring。设计权限矩阵如下：

# 集群级：只读监控角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-monitor
rules:
- apiGroups: [""]
  resources: ["nodes", "pods", "services", "endpoints"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list"]

# 命名空间级：应用发布角色（仅 production 命名空间）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: app-deployer
rules:
- apiGroups: ["apps"]
  resources: ["deployments", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services", "configmaps"]
  verbs: ["get", "list", "watch", "create", "update"]

# 资源级：仅允许操作特定 Secret
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: secret-manager
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["db-credentials", "api-key"]
  verbs: ["get", "update"]