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.io

ClusterRoleBinding

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, namespace

Kubernetes 1.24+ 不再自动为 ServiceAccount 创建永久 Token Secret。推荐使用 TokenRequest API 获取短期令牌：

kubectl create token app-sa --duration=1h -n production

Aggregated 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 验证权限配置是否正确

贡献者

withesse

更新日志

2026/3/14 13:09

查看所有更新日志

9f6c2-feat: organize wiki content and refresh site setup于 2026/3/14