Kubernetes多租户发布流水线RBAC自动配置 - 第2节

2.1 RBAC 核心概念：为什么需要细粒度权限控制

Kubernetes 的 RBAC（基于角色的访问控制） 是集群安全的基础设施。在多租户场景下，不同团队（如开发、测试、运维）需要不同的操作权限：开发人员只需管理命名空间内的 Pod 和 Deployment，而集群管理员需要全局操作权限。RBAC 通过“角色”与“绑定”的分离，实现了权限的灵活分配与审计。

2.1.1 四个核心 API 对象

RBAC 体系由四个关键资源组成，它们共同定义了“谁”能对“什么资源”执行“哪些操作”：

2.1.2 权限规则结构

每个 Role 或 ClusterRole 包含一组规则（rules），每条规则由三个字段组成：

• apiGroups：API 组，如 ""（核心组）、"apps"、"batch"。
• resources：资源类型，如 pods、deployments、services。
• verbs：操作动词，如 get、list、create、update、delete。

# 示例：一个允许在命名空间 "dev" 中管理 Pod 的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-manager
rules:
- apiGroups: [""]          # 核心 API 组
  resources: ["pods"]      # 资源类型
  verbs: ["get", "list", "watch", "create", "update", "delete"]

2.2 Subject 类型：谁在发起请求

在 Kubernetes 中，所有 API 请求都来自一个 Subject（主体）。RBAC 支持三种主体类型：

2.2.1 ServiceAccount：自动化流水线的核心身份

在多租户发布流水线中，ServiceAccount（SA） 是最常用的主体类型。每个命名空间可以创建多个 SA，Pod 通过挂载 SA 的 来认证自身。

# 创建一个 ServiceAccount
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipeline-runner
  namespace: team-a

2.2.2 内置用户与组

Kubernetes 预定义了一些系统级用户和组，用于集群内部组件通信：

• system:admin：集群超级管理员（通常通过证书认证）。
• system:kube-scheduler：调度器使用的身份。
• system:serviceaccounts：所有 ServiceAccount 的组。
• system:authenticated：所有已认证用户的组。

2.3 RoleBinding 与 ClusterRoleBinding：绑定规则详解

绑定（Binding）是 RBAC 的“胶水”，它将角色与主体连接起来。理解两种绑定的区别至关重要：

2.3.1 使用 ClusterRole 与 RoleBinding 实现跨命名空间复用

一个常见模式是：创建 ClusterRole 定义通用权限（如 Pod 只读），然后通过 RoleBinding 将其绑定到不同命名空间的 ServiceAccount。这样既避免了重复定义 Role，又保持了命名空间隔离。

# 1. 创建 ClusterRole（集群级，定义通用权限）
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

---
# 2. 在命名空间 "team-a" 中绑定到 ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: team-a
subjects:
- kind: ServiceAccount
  name: pipeline-runner
  namespace: team-a
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

2.4 多租户场景下的 RBAC 设计原则

在自动化发布流水线中，RBAC 配置需要遵循以下原则：

1. 命名空间隔离：每个租户（团队/项目）使用独立命名空间，Role 和 RoleBinding 限定在命名空间内。
2. ServiceAccount 专用化：每个流水线任务（如构建、部署、测试）使用独立的 SA，避免权限混用。
3. 最小权限：只授予流水线执行所需的最小动词集合（如只给 create 不给 delete）。
4. 审计可追溯：通过 ClusterRoleBinding 绑定组而非单个用户，便于通过外部 IDP 管理成员变更。