RBAC 简介
学习目标
- 理解 RBAC 的基本概念
- 掌握 RBAC 的核心组件
- 了解 RBAC 的工作流程
核心概念
一句话解释
RBAC (Role-Based Access Control) 是 Kubernetes 的授权机制，通过角色定义权限，将角色绑定到用户或服务账户。
RBAC 工作流程
用户/服务账户
│
▼
┌─────────────┐
│ 认证 (Authentication) │
│ 确认身份 │
└─────────────┘
│
▼
┌─────────────┐
│ 授权 (Authorization) │
│ RBAC 检查权限 │
│ 1. 你是谁？ (Subject) │
│ 2. 你要做什么？ (Verb) │
│ 3. 对什么资源？ (Resource)│
└─────────────┘
│
▼
允许/拒绝
RBAC 核心组件
| 组件 | 说明 | 示例 |
|---|---|---|
| Role | 定义权限集合 | 允许读取 Pod |
| ClusterRole | 集群级权限集合 | 允许读取所有 Node |
| RoleBinding | 将 Role 绑定到用户 | 用户 A 可以读取命名空间 X 的 Pod |
| ClusterRoleBinding | 将 ClusterRole 绑定到用户 | 用户 A 可以读取所有 Node |
RBAC 权限模型
权限 = Role (定义能做什么) + RoleBinding (绑定给谁)
示例：
Role: pod-reader
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
RoleBinding:
- role: pod-reader
users: ["alice", "bob"]
groups: ["dev-team"]
结果：alice 和 bob (以及 dev-team 组) 可以读取当前命名空间的 Pod
RBAC vs 其他授权模式
| 模式 | 说明 | 适用场景 |
|---|---|---|
| RBAC | 基于角色的访问控制 | 生产环境推荐 |
| ABAC | 基于属性的访问控制 | 复杂策略 |
| Node | 节点授权 | kubelet 专用 |
| AlwaysAllow | 总是允许 | 测试环境 |
| AlwaysDeny | 总是拒绝 | 安全测试 |
RBAC 调试技巧
# 检查当前用户权限
kubectl auth can-i create deployments
kubectl auth can-i list pods --namespace dev
# 检查特定用户权限
kubectl auth can-i list pods --as alice --namespace dev
# 查看所有权限
kubectl auth can-i --list
# 测试 RBAC 配置
kubectl auth can-i get pods --as system:serviceaccount:default:my-sa
实践练习
练习 1：理解 RBAC 概念
回答以下问题：
- Role 和 ClusterRole 的区别是什么？
- RoleBinding 的作用是什么？
- 如何调试 RBAC 权限问题？
练习 2：检查集群 RBAC
# 检查集群是否启用了 RBAC
kubectl api-versions | grep rbac
# 查看默认角色
kubectl get clusterroles | head -20
# 查看默认角色绑定
kubectl get clusterrolebindings | head -20
常见误解
1. RBAC 是可选的
事实：RBAC 是生产环境的安全基础
问题：不启用 RBAC 会导致任何认证用户都有完整权限
解决：始终启用 RBAC 并遵循最小权限原则
2. Role 只能绑定一个用户
事实：RoleBinding 可以绑定多个用户、组和服务账户
误解：需要为每个用户创建单独的 Role
解决：使用 RoleBinding 的 subjects 数组绑定多个主体
小结
| 要点 | 说明 |
|---|---|
| RBAC | 基于角色的访问控制 |
| 核心组件 | Role、ClusterRole、RoleBinding、ClusterRoleBinding |
| 工作流程 | 认证 → 授权 → 允许/拒绝 |
| 调试命令 | kubectl auth can-i |
| 最佳实践 | 启用 RBAC、最小权限、定期审计 |
练习编辑器
bash
Loading...