RBAC的工作原理，以及如何限制特定用户访问

RBAC（Role-Based Access Control）工作原理

RBAC 是基于角色的访问控制模型，通过 角色（Role） 和 权限（Permission） 的抽象层实现细粒度权限管理。其核心思想是：

1. 角色定义权限：将一组权限（如 get pod、create deployment）打包成一个角色。

2. 用户绑定角色：将用户或用户组与角色关联，间接获得角色对应的权限。

3. 动态验证：当用户发起请求时，系统自动检查其绑定的角色是否包含所需操作的权限。

Kubernetes 中的核心资源

如何限制用户只能查看特定命名空间的 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

验证权限

1. 检查用户权限：

   kubectl auth can-i get pods --namespace=default  # 应返回 "yes"
   kubectl auth can-i create pods --namespace=default  # 应返回 "no"

2. 尝试访问其他命名空间：

   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

关键原理总结

1. 最小权限原则：仅授予必要的操作权限（如 get vs *）。

2. 作用域隔离：通过 namespace 字段限制资源范围（Role）或使用 ClusterRole 实现全局权限。

3. 动态策略：权限生效无需重启服务，实时更新。

通过 RBAC，可以灵活实现类似以下场景的权限控制： • 开发人员只能访问自己项目的 Pod。 • 运维人员可以管理所有命名空间的资源。 • 审计人员仅能查看日志和事件。