当前位置：首页 > news >正文

K8s角色权限管理全解析

news 2025/9/10 9:46:22

在 Kubernetes（k8s）集群中，角色定义是基于 RBAC（Role-Based Access Control，基于基于角色的访问控制）实现的，用于精细化管理用户、服务账户对集群资源的操作权限。主要通过 Role（命名空间内角色）和 ClusterRole（集群级角色）两种资源对象定义权限，再通过 RoleBinding 和 ClusterRoleBinding 将角色与用户 / 服务账户绑定，实现权限分配。

一、核心概念与区别

资源对象	作用范围	管理的资源类型	绑定方式
`Role`	单个命名空间（Namespace）	仅当前命名空间内的资源（如 Pod、Deployment）	`RoleBinding`（同命名空间内绑定）
`ClusterRole`	整个集群	1. 集群级资源（如 Node、Namespace） 2. 所有命名空间的资源（如跨命名空间的 Pod）	`ClusterRoleBinding`（集群级绑定）

二、角色定义示例

1. 命名空间内角色（`Role`）

场景：在 default 命名空间中创建一个 pod-reader 角色，允许用户查看该命名空间内的 Pod 列表和详情。

# role-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: default  # 仅作用于 default 命名空间name: pod-reader
rules:
- apiGroups: [""]  # 核心 API 组（无版本号的资源，如 Pod、Service）resources: ["pods"]  # 允许操作的资源类型为 Podverbs: ["get", "watch", "list"]  # 允许的操作：获取、监听、列表

创建角色：

kubectl apply -f role-pod-reader.yaml

2. 集群级角色（`ClusterRole`）

场景：创建一个 cluster-pod-reader 集群角色，允许用户查看所有命名空间的 Pod，以及查看 Node 资源（集群级资源）。

# clusterrole-cluster-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: cluster-pod-reader  # 集群级角色，无命名空间
rules:
- apiGroups: [""]resources: ["pods"]  # 所有命名空间的 Podverbs: ["get", "watch", "list"]
- apiGroups: [""]resources: ["nodes"]  # 集群级资源 Nodeverbs: ["get", "watch", "list"]

创建集群角色：

kubectl apply -f clusterrole-cluster-pod-reader.yaml

三、角色绑定示例（将角色分配给用户）

1. 命名空间内绑定（`RoleBinding`）

场景：将 default 命名空间的 pod-reader 角色绑定给用户 alice，使 alice 只能查看 default 命名空间的 Pod。

# rolebinding-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:name: read-podsnamespace: default  # 与 Role 同命名空间
subjects:
- kind: Username: alice  # 被绑定的用户（需提前在集群中定义）apiGroup: rbac.authorization.k8s.io
roleRef:kind: Role  # 绑定的是 Role 类型name: pod-reader  # 关联的 Role 名称apiGroup: rbac.authorization.k8s.io

创建绑定：

kubectl apply -f rolebinding-pod-reader.yaml

2. 集群级绑定（`ClusterRoleBinding`）

场景：将 cluster-pod-reader 集群角色绑定给用户 bob，使 bob 能查看所有命名空间的 Pod 和集群的 Node 资源。

# clusterrolebinding-cluster-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:name: read-all-pods-and-nodes
subjects:
- kind: Username: bob  # 被绑定的用户apiGroup: rbac.authorization.k8s.io
roleRef:kind: ClusterRole  # 绑定的是 ClusterRole 类型name: cluster-pod-reader  # 关联的 ClusterRole 名称apiGroup: rbac.authorization.k8s.io

创建集群绑定：

kubectl apply -f clusterrolebinding-cluster-pod-reader.yaml

四、常见角色定义场景扩展

1. 允许管理 Deployment 的角色

# role-deployment-manager.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:namespace: app-devname: deployment-manager
rules:
- apiGroups: ["apps"]  # Deployment 属于 apps API 组resources: ["deployments"]verbs: ["get", "list", "create", "update", "delete"]  # 完整管理权限

2. 允许查看 Secrets 的集群角色

# clusterrole-secret-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:name: secret-reader
rules:
- apiGroups: [""]resources: ["secrets"]  # 所有命名空间的 Secretsverbs: ["get", "watch", "list"]

五、验证角色权限

可通过 kubectl auth can-i 命令验证权限是否生效：

# 检查 alice 是否能在 default 命名空间查看 Pod
kubectl auth can-i get pods --namespace default --as alice  # 输出 yes# 检查 alice 是否能在 kube-system 命名空间查看 Pod（应拒绝，因 Role 仅作用于 default）
kubectl auth can-i get pods --namespace kube-system --as alice  # 输出 no# 检查 bob 是否能查看 Node（集群级权限）
kubectl auth can-i get nodes --as bob  # 输出 yes

总结

Role + RoleBinding 用于控制单个命名空间内的资源权限，适合命名空间隔离的场景（如多团队共享集群）。
ClusterRole + ClusterRoleBinding 用于控制集群级资源或跨命名空间资源的权限，适合集群管理员、监控组件等需要全局权限的场景。
权限定义需遵循 “最小权限原则”，避免过度授权导致安全风险。