【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、创建命名空间
# 0-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:name: app-prod2.2、为 user-service 创建 ServiceAccount
# ServiceAccount 是 Pod 在集群内的身份标识
# 1-serviceaccount.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: user-service-accountnamespace: app-prod2.3、创建 Role（定义命名空间内权限）
# 这个 Role 定义了在 app-prod 命名空间内允许的操作
# 2-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: app-prodname: pod-log-reader
rules:
- apiGroups: [""] # 核心 API 组，空字符串表示核心组，如 Pods, ConfigMapsresources: ["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 的权限
# 将上面创建的 Role 绑定到 ServiceAccount
# 3-rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-pod-logsnamespace: app-prod
subjects:
# 可以绑定多种类型的主体
- kind: ServiceAccountname: user-service-account # 上面创建的 ServiceAccount 名namespace: app-prod # 必须指定 ServiceAccount 的命名空间
roleRef:kind: Rolename: pod-log-reader # 上面创建的 Role 名apiGroup: rbac.authorization.k8s.io2.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