Kubernetes RBAC权限控制
约 1452 字大约 5 分钟
kubernetesrbacsecurity
2025-06-14
RBAC(Role-Based Access Control)是 Kubernetes 中基于角色的访问控制机制。它通过定义角色和绑定关系,精确控制用户、组和服务账户对集群资源的访问权限。
RBAC 架构
Role 与 ClusterRole
Role(命名空间级别)
Role 只能授予同一命名空间内资源的权限:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: pod-reader
rules:
- apiGroups: [""] # 核心 API 组
resources: ["pods", "pods/log", "pods/status"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch"]
resourceNames: ["frontend", "backend"] # 限定特定资源名ClusterRole(集群级别)
ClusterRole 可用于集群级别资源和跨命名空间授权:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: node-manager
rules:
# 集群级资源
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch", "patch"]
- apiGroups: [""]
resources: ["nodes/status"]
verbs: ["get", "patch"]
# 非资源 URL
- nonResourceURLs: ["/healthz", "/healthz/*"]
verbs: ["get"]
# CRD 资源
- apiGroups: ["monitoring.coreos.com"]
resources: ["prometheuses", "alertmanagers"]
verbs: ["get", "list", "watch"]可用的 verbs
| Verb | 描述 | 对应 HTTP 方法 |
|---|---|---|
| get | 读取单个资源 | GET |
| list | 列出资源集合 | GET (集合) |
| watch | 监听资源变化 | GET (watch) |
| create | 创建资源 | POST |
| update | 更新资源(完整替换) | PUT |
| patch | 部分更新资源 | PATCH |
| delete | 删除单个资源 | DELETE |
| deletecollection | 批量删除资源 | DELETE (集合) |
RoleBinding 与 ClusterRoleBinding
RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: production
subjects:
# 绑定用户
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
# 绑定用户组
- kind: Group
name: dev-team
apiGroup: rbac.authorization.k8s.io
# 绑定 ServiceAccount
- kind: ServiceAccount
name: monitoring-sa
namespace: monitoring # SA 可跨命名空间引用
roleRef:
kind: Role # 或 ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.ioClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-binding
subjects:
- kind: User
name: admin@example.com
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: cluster-admin # 内置最高权限角色
apiGroup: rbac.authorization.k8s.io重要:RoleBinding 可以引用 ClusterRole,但权限范围限定在 RoleBinding 所在的命名空间。这种方式常用于在多个命名空间复用同一角色定义。
ServiceAccount
ServiceAccount 是 Pod 访问 API Server 的身份凭证:
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-sa
namespace: production
annotations:
# AWS IRSA (IAM Roles for Service Accounts)
eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/app-role
automountServiceAccountToken: false # 不自动挂载 token
---
# 绑定角色
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-sa-binding
namespace: production
subjects:
- kind: ServiceAccount
name: app-sa
namespace: production
roleRef:
kind: Role
name: app-role
apiGroup: rbac.authorization.k8s.io在 Pod 中使用 ServiceAccount:
apiVersion: v1
kind: Pod
metadata:
name: app
namespace: production
spec:
serviceAccountName: app-sa
automountServiceAccountToken: true
containers:
- name: app
image: myapp:1.0
# Token 自动挂载到 /var/run/secrets/kubernetes.io/serviceaccount/
# 包含: token, ca.crt, namespaceKubernetes 1.24+ 不再自动为 ServiceAccount 创建永久 Token Secret。推荐使用 TokenRequest API 获取短期令牌:
kubectl create token app-sa --duration=1h -n productionAggregated ClusterRoles
聚合 ClusterRole 通过标签选择器自动组合多个 ClusterRole 的规则:
# 聚合角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-aggregate
aggregationRule:
clusterRoleSelectors:
- matchLabels:
rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 由聚合规则自动填充
---
# 子角色 1
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-pods
labels:
rbac.example.com/aggregate-to-monitoring: "true"
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
# 子角色 2
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: monitoring-deployments
labels:
rbac.example.com/aggregate-to-monitoring: "true"
rules:
- apiGroups: ["apps"]
resources: ["deployments", "replicasets"]
verbs: ["get", "list", "watch"]Kubernetes 内置的 admin、edit、view 角色就是聚合角色。自定义 CRD 可以通过添加标签自动聚合到这些角色中:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: custom-resource-viewer
labels:
# 自动聚合到内置 view 角色
rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["myapp.example.com"]
resources: ["widgets"]
verbs: ["get", "list", "watch"]默认 ClusterRole
Kubernetes 内置了几个重要的 ClusterRole:
| ClusterRole | 描述 |
|---|---|
| cluster-admin | 超级管理员,对所有资源有完全权限 |
| admin | 命名空间级管理员,可管理大部分资源 |
| edit | 可读写大部分资源,不能修改 Role/RoleBinding |
| view | 只读权限,不能查看 Secret |
| system:node | kubelet 使用的角色 |
| system:kube-scheduler | 调度器使用的角色 |
最小权限原则实践
# 反面示例:权限过大
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: too-permissive
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"] # 千万不要这样做!
---
# 正面示例:精确授权
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: deployment-manager
namespace: production
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
# 不授予 delete 权限
- apiGroups: ["apps"]
resources: ["deployments/scale"]
verbs: ["update", "patch"] # 只允许扩缩容
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"] # Pod 只读Audit Logging(审计日志)
审计日志记录所有 API 请求,用于安全审查和合规:
# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 不记录健康检查
- level: None
nonResourceURLs:
- /healthz*
- /readyz*
# Secret 操作只记录元数据(不记录内容)
- level: Metadata
resources:
- group: ""
resources: ["secrets"]
# RBAC 变更记录完整请求和响应
- level: RequestResponse
resources:
- group: "rbac.authorization.k8s.io"
verbs: ["create", "update", "patch", "delete"]
# 其他资源记录请求内容
- level: Request
resources:
- group: ""
- group: "apps"审计日志级别:
- None:不记录
- Metadata:记录请求元数据(用户、时间、资源、动作)
- Request:记录元数据 + 请求体
- RequestResponse:记录元数据 + 请求体 + 响应体
权限验证
# 检查当前用户权限
kubectl auth can-i create deployments --namespace production
# yes
# 以其他用户身份检查
kubectl auth can-i delete pods --namespace production --as alice
# no
# 以 ServiceAccount 身份检查
kubectl auth can-i get secrets --namespace production \
--as system:serviceaccount:production:app-sa
# no
# 列出所有权限
kubectl auth can-i --list --namespace production总结
RBAC 最佳实践:
- 遵循最小权限原则,只授予必要的权限
- 优先使用 RoleBinding 而非 ClusterRoleBinding,限制权限范围
- 为每个应用创建独立的 ServiceAccount,不使用 default SA
- 设置
automountServiceAccountToken: false,仅在需要时挂载 - 使用聚合 ClusterRole 组织权限,便于维护
- 启用审计日志监控敏感操作
- 定期审查 RBAC 配置,清理过期权限
- 使用
kubectl auth can-i验证权限配置是否正确
贡献者
更新日志
2026/3/14 13:09
查看所有更新日志
9f6c2-feat: organize wiki content and refresh site setup于