RBAC基础

概述

RBAC（Role-Based Access Control，基于角色的访问控制）是Kubernetes中用于管理集群资源访问权限的核心机制。通过RBAC，管理员可以精细地控制谁可以在哪些资源上执行哪些操作，从而实现最小权限原则和安全的集群管理。

核心概念

1. Role（角色）

Role定义了一组权限规则，用于在特定命名空间内对资源进行访问控制。Role只能用于授予单个命名空间内的资源访问权限。

2. ClusterRole（集群角色）

ClusterRole与Role类似，但它的作用范围是整个集群，可以授予集群级别的资源访问权限（如节点、持久卷等）或跨命名空间的资源访问权限。

3. RoleBinding（角色绑定）

RoleBinding将Role中定义的权限授予一个或一组用户、服务账户或组。它只在特定命名空间内有效。

4. ClusterRoleBinding（集群角色绑定）

ClusterRoleBinding将ClusterRole中定义的权限授予一个或一组用户、服务账户或组，作用范围为整个集群。

5. Subject（主体）

Subject表示权限授予的对象，可以是：

• User（用户）：外部管理的用户账户
• Group（组）：用户组
• ServiceAccount（服务账户）：Pod使用的账户

RBAC工作原理

┌─────────────┐
│   Subject   │ (User/Group/ServiceAccount)
└──────┬──────┘
       │
       │ 绑定
       ▼
┌──────────────┐
│ RoleBinding  │ 或 ClusterRoleBinding
└──────┬───────┘
       │
       │ 引用
       ▼
┌──────────────┐
│     Role     │ 或 ClusterRole
└──────┬───────┘
       │
       │ 定义
       ▼
┌──────────────┐
│   Permissions│ (API Groups/Resources/Verbs)
└──────────────┘

YAML配置示例

示例1：创建命名空间级别的Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: default
rules:
- apiGroups: [""]  # "" 表示核心API组
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""] 
  resources: ["pods/log"]
  verbs: ["get"]

示例2：创建RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: jane  # 用户名
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

示例3：创建集群级别的ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-reader
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["nodes/proxy"]
  verbs: ["get"]

示例4：创建ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-nodes
subjects:
- kind: Group
  name: system:node-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

示例5：完整的开发环境权限配置

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-role
  namespace: development
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["extensions", "networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods/exec", "pods/portforward", "pods/log"]
  verbs: ["create", "get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
- kind: User
  name: dev-user2
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

示例6：只读权限配置

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: readonly-clusterrole
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["extensions", "networking.k8s.io"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

kubectl操作命令

查看RBAC资源

# 查看所有Role
kubectl get roles --all-namespaces

# 查看特定命名空间的Role
kubectl get roles -n default

# 查看Role详细信息
kubectl describe role pod-reader -n default

# 查看所有ClusterRole
kubectl get clusterroles

# 查看ClusterRole详细信息
kubectl describe clusterrole node-reader

# 查看所有RoleBinding
kubectl get rolebindings --all-namespaces

# 查看所有ClusterRoleBinding
kubectl get clusterrolebindings

# 查看系统内置的ClusterRole
kubectl get clusterroles | grep system:

创建和删除RBAC资源

# 通过YAML文件创建Role
kubectl apply -f role.yaml

# 创建RoleBinding
kubectl apply -f rolebinding.yaml

# 删除Role
kubectl delete role pod-reader -n default

# 删除RoleBinding
kubectl delete rolebinding read-pods -n default

# 删除ClusterRole
kubectl delete clusterrole node-reader

# 删除ClusterRoleBinding
kubectl delete clusterrolebinding read-nodes

快速创建RBAC资源

# 快速创建Role（命令行方式）
kubectl create role pod-reader --verb=get,list,watch --resource=pods -n default

# 快速创建RoleBinding
kubectl create rolebinding read-pods --user=jane --role=pod-reader -n default

# 快速创建ClusterRole
kubectl create clusterrole node-reader --verb=get,list,watch --resource=nodes

# 快速创建ClusterRoleBinding
kubectl create clusterrolebinding read-nodes --group=system:node-admins --clusterrole=node-reader

# 为ServiceAccount创建RoleBinding
kubectl create rolebinding my-sa-binding --serviceaccount=default:my-service-account --role=pod-reader -n default

权限检查和测试

# 检查用户是否有权限执行操作
kubectl auth can-i list pods --as=jane -n default

# 检查ServiceAccount权限
kubectl auth can-i list pods --as=system:serviceaccount:default:my-service-account -n default

# 检查特定资源的权限
kubectl auth can-i create deployments --as=jane -n development

# 列出用户的所有权限
kubectl auth can-i --list --as=jane -n default

# 检查是否可以执行特定动作
kubectl auth can-i delete pods --as=dev-user -n development

查看RBAC配置详情

# 以YAML格式查看Role
kubectl get role pod-reader -n default -o yaml

# 以JSON格式查看RoleBinding
kubectl get rolebinding read-pods -n default -o json

# 查看ClusterRole的详细规则
kubectl get clusterrole admin -o yaml

# 查看系统内置角色的权限
kubectl describe clusterrole cluster-admin

真实场景实践示例

场景1：为开发团队创建命名空间权限

需求：开发团队需要在development命名空间中拥有完整的开发权限，但不能访问其他命名空间。

解决方案：

---
apiVersion: v1
kind: Namespace
metadata:
  name: development
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-full-access
  namespace: development
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["extensions", "networking.k8s.io"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["autoscaling"]
  resources: ["*"]
  verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-team-binding
  namespace: development
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-full-access
  apiGroup: rbac.authorization.k8s.io

验证步骤：

# 应用配置
kubectl apply -f developer-namespace-rbac.yaml

# 验证权限
kubectl auth can-i create deployments --as=dev-user --as-group=dev-team -n development
# 应该返回: yes

# 验证无法访问其他命名空间
kubectl auth can-i list pods --as=dev-user --as-group=dev-team -n production
# 应该返回: no

场景2：为CI/CD系统配置ServiceAccount权限

需求：Jenkins CI/CD系统需要能够部署应用到指定命名空间，但只能执行部署相关的操作。

解决方案：

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-deployer
  namespace: jenkins
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer-role
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps", "secrets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["extensions", "networking.k8s.io"]
  resources: ["ingresses"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-deployer-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: jenkins-deployer
  namespace: jenkins
roleRef:
  kind: Role
  name: deployer-role
  apiGroup: rbac.authorization.k8s.io

使用示例：

# 创建ServiceAccount和RBAC配置
kubectl apply -f jenkins-rbac.yaml

# 获取ServiceAccount Token（Kubernetes 1.24+）
kubectl create token jenkins-deployer -n jenkins --duration=24h

# 配置Jenkins使用该ServiceAccount
# 在Jenkins Pod中挂载ServiceAccount

场景3：创建只读监控权限

需求：监控系统需要读取集群中所有命名空间的资源状态，但不能修改任何资源。

解决方案：

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: monitoring-reader
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods", "nodes", "services", "endpoints", "configmaps", "namespaces"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch"]
  resources: ["jobs", "cronjobs"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log", "pods/status", "nodes/metrics", "nodes/stats"]
  verbs: ["get"]
- apiGroups: ["metrics.k8s.io"]
  resources: ["pods", "nodes"]
  verbs: ["get", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: monitoring-reader-binding
subjects:
- kind: ServiceAccount
  name: monitoring-reader
  namespace: monitoring
roleRef:
  kind: ClusterRole
  name: monitoring-clusterrole
  apiGroup: rbac.authorization.k8s.io

验证：

# 应用配置
kubectl apply -f monitoring-rbac.yaml

# 测试权限
kubectl auth can-i list pods --all-namespaces \
  --as=system:serviceaccount:monitoring:monitoring-reader
# 应该返回: yes

kubectl auth can-i create pods \
  --as=system:serviceaccount:monitoring:monitoring-reader
# 应该返回: no

场景4：多租户环境权限隔离

需求：在多租户环境中，每个租户只能访问自己的命名空间，管理员可以访问所有命名空间。

解决方案：

---
# 租户A的命名空间
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a
  labels:
    tenant: tenant-a
---
# 租户B的命名空间
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-b
  labels:
    tenant: tenant-b
---
# 租户A的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tenant-admin
  namespace: tenant-a
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
# 租户A的RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tenant-a-admin-binding
  namespace: tenant-a
subjects:
- kind: Group
  name: tenant-a-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: tenant-admin
  apiGroup: rbac.authorization.k8s.io
---
# 租户B的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tenant-admin
  namespace: tenant-b
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
# 租户B的RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: tenant-b-admin-binding
  namespace: tenant-b
subjects:
- kind: Group
  name: tenant-b-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: tenant-admin
  apiGroup: rbac.authorization.k8s.io
---
# 集群管理员的ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-custom
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
---
# 集群管理员的ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: Group
  name: cluster-admins
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin-custom
  apiGroup: rbac.authorization.k8s.io

场景5：细粒度的应用权限控制

需求：应用团队只能管理特定的资源类型，且只能执行特定的操作。

解决方案：

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-manager
  namespace: app-namespace
rules:
# 只能管理Deployments
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# 只能查看Pods
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
# 只能查看Pod日志
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]
# 只能执行到Pod中
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
# 只能管理Services
- apiGroups: [""]
  resources: ["services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# 只能管理ConfigMaps
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# 不能访问Secrets
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-manager-binding
  namespace: app-namespace
subjects:
- kind: User
  name: app-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: app-manager
  apiGroup: rbac.authorization.k8s.io

故障排查指南

问题1：权限被拒绝（Forbidden）

症状：

Error from server (Forbidden): pods is forbidden: User "jane" cannot list resource "pods" in API group "" in the namespace "default"

排查步骤：

# 1. 检查用户是否有对应的RoleBinding
kubectl get rolebindings -n default
kubectl describe rolebinding read-pods -n default

# 2. 检查RoleBinding引用的Role是否存在
kubectl get role pod-reader -n default
kubectl describe role pod-reader -n default

# 3. 检查权限规则
kubectl auth can-i list pods --as=jane -n default

# 4. 列出用户的所有权限
kubectl auth can-i --list --as=jane -n default

# 5. 检查ServiceAccount的权限
kubectl auth can-i list pods \
  --as=system:serviceaccount:default:my-service-account \
  -n default

解决方案：

• 确保RoleBinding正确引用了Role
• 确保Role中的规则包含所需的资源和操作
• 确保RoleBinding中的Subject正确配置了用户名或ServiceAccount名

问题2：RoleBinding不生效

症状：创建了RoleBinding但用户仍然无法访问资源。

排查步骤：

# 1. 检查RoleBinding的namespace是否正确
kubectl get rolebinding -n <namespace>

# 2. 检查RoleBinding的subjects配置
kubectl get rolebinding <binding-name> -n <namespace> -o yaml

# 3. 检查用户名是否正确（区分大小写）
kubectl auth can-i list pods --as=<username> -n <namespace>

# 4. 检查是否是Group而不是User
kubectl auth can-i list pods --as=<username> --as-group=<groupname> -n <namespace>

常见错误：

# 错误示例：User和Group混淆
subjects:
- kind: User
  name: dev-team  # 这实际上是一个组名
  apiGroup: rbac.authorization.k8s.io

# 正确示例：
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io

问题3：ClusterRole无法访问命名空间资源

症状：创建了ClusterRole和ClusterRoleBinding，但无法访问命名空间级别的资源。

原因分析：

• ClusterRole可以授予命名空间资源的访问权限
• 需要确保ClusterRoleBinding正确配置

排查步骤：

# 检查ClusterRole规则
kubectl get clusterrole <clusterrole-name> -o yaml

# 检查ClusterRoleBinding
kubectl get clusterrolebinding <binding-name> -o yaml

# 测试权限
kubectl auth can-i list pods --as=<username> --all-namespaces

问题4：ServiceAccount权限问题

症状：Pod中的应用无法访问Kubernetes API。

排查步骤：

# 1. 检查Pod使用的ServiceAccount
kubectl get pod <pod-name> -o jsonpath='{.spec.serviceAccountName}'

# 2. 检查ServiceAccount是否存在
kubectl get serviceaccount <sa-name> -n <namespace>

# 3. 检查ServiceAccount的RoleBinding
kubectl get rolebinding -n <namespace> | grep <sa-name>

# 4. 检查Pod内的Token是否正确挂载
kubectl exec <pod-name> -- ls -la /var/run/secrets/kubernetes.io/serviceaccount/

# 5. 测试ServiceAccount权限
kubectl auth can-i list pods \
  --as=system:serviceaccount:<namespace>:<sa-name> \
  -n <namespace>

问题5：权限过于宽泛

症状：用户拥有不应该拥有的权限。

排查步骤：

# 1. 列出所有绑定到用户的RoleBinding
kubectl get rolebindings --all-namespaces -o json | \
  jq -r '.items[] | select(.subjects[]?.name=="<username>") | .metadata.name'

# 2. 列出所有绑定到用户的ClusterRoleBinding
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.subjects[]?.name=="<username>") | .metadata.name'

# 3. 检查系统内置的ClusterRoleBinding
kubectl get clusterrolebindings | grep <username>

# 4. 检查是否继承了组的权限
kubectl auth can-i --list --as=<username> --as-group=<groupname>

问题6：RBAC配置更新不生效

症状：修改了Role或RoleBinding但权限没有变化。

解决方案：

# 1. 确保使用kubectl apply而不是kubectl create
kubectl apply -f role.yaml

# 2. 检查配置是否已更新
kubectl get role <role-name> -n <namespace> -o yaml

# 3. RBAC权限是实时生效的，无需重启服务
# 如果不生效，检查是否有多个RoleBinding冲突

# 4. 清理并重新创建
kubectl delete rolebinding <binding-name> -n <namespace>
kubectl apply -f rolebinding.yaml

最佳实践建议

1. 遵循最小权限原则

# 不推荐：过于宽泛的权限
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

# 推荐：精确的权限定义
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get"]

2. 使用命名空间隔离权限

# 为每个命名空间创建独立的Role
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-role
  namespace: production  # 明确指定命名空间
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

3. 使用组管理权限

# 使用组而不是单个用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-binding
  namespace: development
subjects:
- kind: Group
  name: development-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

4. 为ServiceAccount命名清晰

apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-monitoring  # 清晰的命名
  namespace: monitoring
  labels:
    app: prometheus
    component: monitoring

5. 使用注释记录权限用途

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-deployer
  namespace: production
  annotations:
    description: "允许部署应用和管理Pod"
    owner: "dev-team@example.com"
    created-by: "admin"
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]

6. 定期审计RBAC配置

# 列出所有ClusterRoleBinding
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

# 列出所有命名空间的RoleBinding
kubectl get rolebindings --all-namespaces -o json | \
  jq -r '.items[] | "\(.metadata.namespace)/\(.metadata.name): \(.subjects)"'

# 检查谁有集群管理员权限
kubectl get clusterrolebindings -o json | \
  jq -r '.items[] | select(.roleRef.name=="cluster-admin") | "\(.metadata.name): \(.subjects[].name)"'

7. 使用系统内置角色

Kubernetes提供了多个内置的ClusterRole，可以直接使用：

# 查看内置角色
kubectl get clusterroles | grep -E 'view|edit|admin'

# view: 只读权限
# edit: 读写权限（不包括资源配额和权限管理）
# admin: 命名空间管理员权限
# cluster-admin: 集群管理员权限

使用内置角色：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-edit-binding
  namespace: development
subjects:
- kind: User
  name: dev-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: edit  # 使用内置的edit角色
  apiGroup: rbac.authorization.k8s.io

8. 避免使用cluster-admin

# 不推荐：给普通用户cluster-admin权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: user-admin-binding
subjects:
- kind: User
  name: regular-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin  # 危险！
  apiGroup: rbac.authorization.k8s.io

# 推荐：创建自定义的受限角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-admin
rules:
- apiGroups: [""]
  resources: ["nodes", "namespaces", "persistentvolumes"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings"]
  verbs: ["*"]

9. 使用ResourceNames限制特定资源

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: configmap-updater
  namespace: default
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]  # 只能访问特定的ConfigMap
  verbs: ["get", "update"]

10. 版本控制和审计

# 将RBAC配置纳入Git版本控制
git add rbac-configs/
git commit -m "Update RBAC permissions for dev team"

# 使用kubectl auth命令定期审计
kubectl auth can-i --list --as=<username> > user-permissions-$(date +%Y%m%d).txt

RBAC权限速查表

常用Verbs（操作）

Verb	说明	示例
get	获取单个资源	kubectl get pod my-pod
list	列出资源集合	kubectl get pods
watch	监听资源变化	kubectl get pods --watch
create	创建资源	kubectl create -f pod.yaml
update	更新资源	kubectl update -f pod.yaml
patch	部分更新资源	kubectl patch pod my-pod -p '...'
delete	删除资源	kubectl delete pod my-pod
deletecollection	删除资源集合	kubectl delete pods --all

常用API Groups

API Group	资源示例
"" (核心)	pods, services, configmaps, secrets, namespaces
apps	deployments, statefulsets, daemonsets, replicasets
batch	jobs, cronjobs
networking.k8s.io	ingresses, networkpolicies
rbac.authorization.k8s.io	roles, rolebindings, clusterroles, clusterrolebindings
extensions	ingresses (已弃用)
autoscaling	horizontalpodautoscalers
storage.k8s.io	storageclasses, volumeattachments

常用资源组合

# 只读权限
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch"]

# 完全控制权限
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

# 执行权限（进入容器）
rules:
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]

# 查看日志权限
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

总结

RBAC是Kubernetes安全体系的核心组件，通过精细化的权限控制，可以实现：

1. 最小权限原则：只授予必要的权限
2. 职责分离：不同角色拥有不同权限
3. 多租户隔离：命名空间级别的权限隔离
4. 审计和合规：清晰的权限定义便于审计

关键要点

• Role和RoleBinding用于命名空间级别权限
• ClusterRole和ClusterRoleBinding用于集群级别权限
• 始终遵循最小权限原则
• 定期审计和清理不必要的权限
• 使用组而不是单个用户管理权限
• 为ServiceAccount配置最小必要权限

下一步学习

• ServiceAccount - 深入了解Pod身份认证
• 网络安全 - 学习网络策略和安全隔离
• Pod安全 - 掌握Pod安全策略
• SecurityContext - 配置容器安全上下文

参考资料

• Kubernetes RBAC官方文档
• Kubernetes授权概述
• 使用RBAC配置权限