RBAC（Role-Based Access Control）工作原理
RBAC 是基于角色的访问控制模型，通过 角色（Role） 和 权限（Permission） 的抽象层实现细粒度权限管理。其核心思想是：
-
角色定义权限 ：将一组权限（如
get pod、create deployment）打包成一个角色。 -
用户绑定角色：将用户或用户组与角色关联，间接获得角色对应的权限。
-
动态验证：当用户发起请求时，系统自动检查其绑定的角色是否包含所需操作的权限。
Kubernetes 中的核心资源
| 资源类型 | 描述 |
|---|---|
| Role | 定义命名空间内的权限（非集群级） |
| ClusterRole | 定义集群级权限（所有命名空间有效） |
| RoleBinding | 将 Role 绑定到用户/用户组（命名空间内） |
| ClusterRoleBinding | 将 ClusterRole 绑定到用户/用户组（集群级） |
如何限制用户只能查看特定命名空间的 Pod？
步骤 1：创建 Role（定义权限）
# 创建名为 "pod-reader" 的 Role，允许在 `default` 命名空间内查看 Pod
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"] # 只允许查看，不允许创建/删除步骤 2：创建 RoleBinding（绑定用户）
# 将用户 "alice" 绑定到 "pod-reader" 角色
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
namespace: default
name: alice-pod-reader
subjects:
- kind: User
name: alice
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io步骤 3：应用配置
kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml验证权限
-
检查用户权限：
kubectl auth can-i get pods --namespace=default # 应返回 "yes" kubectl auth can-i create pods --namespace=default # 应返回 "no" -
尝试访问其他命名空间：
kubectl auth can-i get pods --namespace=another-ns # 默认返回 "no"（除非显式授权）
进阶控制（可选）
1. 限制多个命名空间
# 创建跨多个命名空间的 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: multi-namespace-pod-reader
namespace: kube-system
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
namespaces: ["default", "test"] # 仅允许访问指定命名空间2. 结合 Group 管理批量用户
# 将用户组绑定到 Role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-team-pod-reader
subjects:
- kind: Group
name: developers
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io关键原理总结
-
最小权限原则 ：仅授予必要的操作权限（如
getvs*）。 -
作用域隔离 ：通过
namespace字段限制资源范围（Role）或使用ClusterRole实现全局权限。 -
动态策略：权限生效无需重启服务，实时更新。
通过 RBAC，可以灵活实现类似以下场景的权限控制： • 开发人员只能访问自己项目的 Pod。 • 运维人员可以管理所有命名空间的资源。 • 审计人员仅能查看日志和事件。