【Kubernetes】K8s 集群 RBAC 鉴权

Kubernetes RBAC 提供了强大而灵活的权限管理机制，一起来看看如何使用吧！

1、概念区别

1.1、角色和绑定

Role: 定义在特定命名空间内的一组权限（规则），如对 Pod、Service 等资源的操作权限
RoleBinding: 将 Role 中定义的权限授予一个或多个用户、组或 ServiceAccount，该授权也仅限于特定命名空间

1.2、集群角色和集群绑定

ClusterRole: 定义集群范围的权限集，这些权限可以是：

a**、对集群级资源（如 Node、Namespace、PersistentVolume）的访问权限**

b、对非资源端点（如 /healthz ）的访问权限

c**、可跨所有命名空间对命名空间资源（如 Pod）的访问权限**

ClusterRoleBinding: 将 ClusterRole 中定义的权限授予一个或多个用户、组或 ServiceAccount，并且该授权是集群范围的，适用于所有命名空间

1.3、特殊用法

RoleBinding 也可引用一个 ClusterRole，在这种情况下，ClusterRole 中定义的权限会被限制在 RoleBinding 所在的命名空间内。这常用于定义一套可复用的权限模板（通过 ClusterRole），然后在多个命名空间中通过 RoleBinding 进行授权

2、完整示例

假设我们有一个名为 user-service 的微服务，它运行在app-prod 命名空间中，该服务需要：

a、对自己 Pod 的日志有读取权限

b、能够从 app-config 这个 ConfigMap 中读取配置

同时，我们有一个运维工程师 alice，她需要能查看所有命名空间的 Pod，但不能修改。

2.1、创建命名空间

bash 复制代码

# 0-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: app-prod

2.2、为 user-service 创建 ServiceAccount

bash 复制代码

# ServiceAccount 是 Pod 在集群内的身份标识
# 1-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: user-service-account
  namespace: app-prod

2.3、创建 Role（定义命名空间内权限）

bash 复制代码

# 这个 Role 定义了在 app-prod 命名空间内允许的操作
# 2-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app-prod
  name: pod-log-reader
rules:
- apiGroups: [""] # 核心 API 组，空字符串表示核心组，如 Pods, ConfigMaps
  resources: ["pods", "pods/log"] # 资源类型
  verbs: ["get", "list"] # 操作动词
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"] # 可以进一步限制为特定的 ConfigMap 实例
  verbs: ["get"]

2.4、创建 RoleBinding（在命名空间内绑定）

任何使用 user-service-account -> ServiceAccount 的 Pod（即 user-service 微服务）在 app-prod 命名空间内，就拥有了读取 Pod 日志和获取 app-config -> ConfigMap 的权限

bash 复制代码

# 将上面创建的 Role 绑定到 ServiceAccount
# 3-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pod-logs
  namespace: app-prod
subjects:
# 可以绑定多种类型的主体
- kind: ServiceAccount
  name: user-service-account # 上面创建的 ServiceAccount 名
  namespace: app-prod # 必须指定 ServiceAccount 的命名空间
roleRef:
  kind: Role
  name: pod-log-reader # 上面创建的 Role 名
  apiGroup: rbac.authorization.k8s.io

2.5、为运维工程师 alice 授权

alice 需要跨所有命名空间查看 Pod，这是一个集群范围的权限，因此使用 ClusterRole 和 ClusterRoleBinding
首先 Kubernetes 有一个内置的ClusterRole -> view，包含了读取命名空间内大多数资源的权限，可直接使用
创建 ClusterRoleBindng，将集群角色 view 授予用户 alice
完成绑定后，用户 alice 使用 kubectl 时，就可在任何命名空间中执行kubectl get pods 等查看操作，但无法创建、修改或删除

3、总结

Role + RoleBinding：精细化的命名空间权限控制，这是为微服务或团队分配权限最常见的方式，遵循最小权限原则
ClusterRole + ClusterRoleBinding：集群级管理权限，用于授予集群管理员、节点查看、存储管理等需要跨命名空间或在集群层面操作的权限
ClusterRole + RoleBinding：可复用的权限模板，若想在多个命名空间定义相同的角色规则，可先创建一个ClusterRole，然后在不同命名空间中创建 RoleBinding 来引用它，避免重复定义Role