Kubernetes RBAC权限管理核心概念与实战指南

1. Kubernetes RBAC 权限管理核心概念

在 Kubernetes 集群中，权限管理是确保系统安全的重要环节。RBAC（Role-Based Access Control）作为 Kubernetes 的核心授权机制，通过定义角色和绑定关系来控制对集群资源的访问。让我们先来理解几个关键概念。

1.1 Role 与 ClusterRole 的本质区别

Role 和 ClusterRole 本质上都是权限规则的集合，它们定义了可以对哪些资源执行哪些操作。两者的核心区别在于作用范围：

• Role：命名空间级别资源，仅在其所属的命名空间内有效
• ClusterRole：集群级别资源，作用于整个 Kubernetes 集群

举个例子，假设我们有一个查看 Pod 的 Role：

yaml复制apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-viewer
  namespace: dev
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

这个 Role 只在 dev 命名空间内有效。如果要在所有命名空间都能查看 Pod，就需要使用 ClusterRole。

实际经验：在中小型集群中，我通常会将 ClusterRole 用于集群管理员、节点查看等全局权限，而将 Role 用于具体业务应用的权限控制。

1.2 ServiceAccount 的工作原理

ServiceAccount 是 Kubernetes 中为 Pod 内进程设计的身份标识。每个命名空间都有一个默认的 default ServiceAccount，但生产环境中我们应该为不同用途创建专用账户。

创建 ServiceAccount 时，Kubernetes 会自动生成并挂载一个 token，Pod 内的应用可以使用这个 token 来访问 Kubernetes API。例如：

yaml复制apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitoring-agent
  namespace: monitoring

避坑指南：默认情况下，ServiceAccount 的 token 会永久有效。在安全性要求高的环境，可以考虑使用 TokenRequest API 获取有时间限制的 token。

1.3 绑定机制解析

权限的生效需要通过 Binding 将 Role/ClusterRole 与 ServiceAccount 关联起来：

• RoleBinding：将 Role 或 ClusterRole 绑定到主体（如 ServiceAccount）
• ClusterRoleBinding：将 ClusterRole 绑定到主体（作用于整个集群）

一个常见的误区是认为 ClusterRole 必须用 ClusterRoleBinding。实际上：

• ClusterRole + RoleBinding：权限限定在 RoleBinding 所在的命名空间
• ClusterRole + ClusterRoleBinding：权限作用于整个集群

2. RBAC