1. Kubernetes 鉴权概述：RBAC、ABAC、Webhook 鉴权模式对比与选择

Kubernetes 的鉴权（Authorization）是集群安全体系的核心环节，位于认证（Authentication）之后、准入控制（Admission Control）之前。当用户或 ServiceAccount 通过 kube-apiserver 发起请求时，鉴权模块负责判断“该请求者是否有权限执行指定操作”。Kubernetes 原生支持三种鉴权模式：RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）和 Webhook（外部鉴权回调）。此外，还存在一种 Node 鉴权模式（专用于 kubelet），但不在本章对比范围内。

核心原则：生产环境优先选择 RBAC；ABAC 已逐步弃用；Webhook 用于对接企业已有 IAM 或实现自定义鉴权策略。

1.1 三种鉴权模式核心对比

维度 RBAC ABAC Webhook
策略定义方式 通过 Kubernetes API 资源（Role / ClusterRole / RoleBinding / ClusterRoleBinding）声明 通过 JSON 策略文件（静态文件）配置，apiserver 启动时加载 外部 HTTP(S) 服务返回鉴权决策（Allow / Deny / NoOpinion）
动态性 高：创建/更新 RBAC 资源后即时生效，无需重启 apiserver 低：修改策略文件后必须重启 kube-apiserver 或触发热加载（需额外配置） 高：外部服务可实时更新策略，apiserver 仅做转发
粒度 粗到中：支持命名空间级别（Role）和集群级别（ClusterRole），操作粒度到 API 资源/动词 细：支持按用户、组、资源、命名空间、非资源路径等属性组合匹配 极细：完全由外部服务决定，可基于任意上下文（请求 IP、时间、审计标签等）
管理复杂度 低：原生 Kubernetes 资源，kubectl 直接管理，生态工具丰富 高：需维护 JSON 文件、手动同步、重启服务，易出错 中：需开发/维护外部鉴权服务，增加部署和运维成本
性能影响 低：apiserver 本地缓存 RBAC 对象，内存匹配 低：启动时加载到内存，运行时无额外网络开销 中：每次鉴权请求都需 HTTP 调用外部服务，增加延迟（通常 1-10ms）
适用场景 绝大多数生产集群，多租户隔离、团队权限管理 遗留系统、简单集群（用户数少且策略固定） 企业统一鉴权平台、自定义策略引擎、审计与动态阻断

1.2 RBAC：生产首选

RBAC 是 Kubernetes 1.8+ 的稳定 GA 特性，也是 CNCF 推荐的生产环境鉴权方案。其核心模型包含四个资源对象：

  • Role / ClusterRole：定义一组权限规则（verbs + resources + resourceNames）。
  • RoleBinding / ClusterRoleBinding：将 Role 绑定到用户、组或 ServiceAccount。

典型 RBAC 配置示例：

# 创建一个只读 Role（命名空间级别）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
---
# 将 Role 绑定到 ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: read-pods
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
最佳实践：始终遵循最小权限原则。优先使用 Role（命名空间范围）而非 ClusterRole；为每个微服务创建独立的 ServiceAccount 并绑定最小权限集；定期使用 kubectl auth can-i --list --as=system:serviceaccount:ns:sa-name 审计权限。

1.3 ABAC：遗留方案与弃用趋势

ABAC 是 Kubernetes 早期版本（1.6 之前）的默认鉴权模式。策略以 JSON 文件形式存储在 apiserver 节点上，启动时通过 --authorization-policy-file 参数加载。一个典型的 ABAC 策略条目如下：

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy",
 "spec": {"user": "alice", "namespace": "default", "resource": "pods", "apiGroup": "", "readonly": true}}

ABAC 的主要缺陷：

  • 静态配置：策略变更需要修改文件并重启 apiserver，无法在线热更新。
  • 缺乏分组支持：每个用户需要单独配置策略，无法像 RBAC 那样通过 Group 批量管理。
  • 审计困难：策略文件是纯文本 JSON，大规模集群下难以追踪“谁有什么权限”。
  • 社区弃用：Kubernetes 1.8+ 已标记 ABAC 为 deprecated，未来版本可能移除。
警告：新集群不应使用 ABAC。如果现有集群仍在使用 ABAC，请制定迁移计划，逐步将策略转换为 RBAC 资源，并启用 --authorization-mode=RBAC,Node。

1.4 Webhook：企业级自定义鉴权

Webhook 鉴权模式允许将鉴权决策委托给外部 HTTP(S) 服务。当 apiserver 收到请求时，会构造一个 SubjectAccessReview 对象并 POST 到 Webhook 服务，服务返回 Allowed: true/false 以及可选的原因描述。

Webhook 配置示例：

# apiserver 启动参数
--authorization-mode=Node,RBAC,Webhook
--authorization-webhook-config-file=/etc/kubernetes/webhook-config.yaml

# webhook-config.yaml 内容
apiVersion: v1
kind: Config
clusters:
- name: my-authz-service
  cluster:
    server: https://authz.example.com/authorize
    certificate-authority: /etc/kubernetes/ca.pem
users:
- name: apiserver
  user:
    client-certificate: /etc/kubernetes/apiserver-client.pem
    client-key: /etc/kubernetes/apiserver-client-key.pem

Webhook 的典型应用场景：

  • 企业 IAM 集成：对接 LDAP、AD、OAuth2 等统一身份平台，实现跨集群统一鉴权。
  • 动态策略引擎：基于请求上下文（时间、来源 IP、资源标签）做实时决策，例如“禁止在非工作时间删除生产命名空间”。
  • 审计与阻断：Webhook 服务可记录所有鉴权请求日志，并对高风险操作实施阻断。
性能考量：Webhook 会增加每次 API 请求的延迟。建议将 Webhook 服务部署在集群内（同区域），启用 HTTP/2 和连接池，并设置合理的超时（默认 5s）。对于高吞吐集群，可考虑使用 --authorization-webhook-cache-authorized-ttl 和 --authorization-webhook-cache-unauthorized-ttl 参数启用缓存。

1.5 鉴权模式选择决策树

下图展示了在规划集群鉴权策略时的决策流程：

Kubernetes 鉴权模式选择决策树 开始选择鉴权模式 需要对接企业外部 IAM 系统？ Webhook 模式 否 是否为遗留集群？ ABAC（建议迁移） 否 RBAC（生产推荐） 说明： 1. 生产集群通常组合使用 Node + RBAC + Webhook（按顺序评估）。 2. ABAC 仅建议在无法立即迁移的遗留集群中使用，且需规划迁移路径。 3. Webhook 可与 RBAC 共存：RBAC 做基础权限，Webhook 做动态策略覆盖。

1.6 多模式组合与评估顺序

Kubernetes 支持同时启用多种鉴权模式，通过 --authorization-mode 参数指定顺序（如 Node,RBAC,Webhook）。apiserver 会按顺序依次调用每个模块：

  1. Node 鉴权：首先判断是否为 kubelet 请求，如果是则按 Node 策略评估。
  2. RBAC 鉴权：如果 Node 未拒绝且未明确允许，则进入 RBAC 评估。
  3. Webhook 鉴权：如果 RBAC 返回 NoOpinion（未匹配到策略），则调用 Webhook 服务。

评估规则：

  • 任一模块返回 Allow → 请求通过，后续模块不再执行。
  • 任一模块返回 Deny → 请求被拒绝，立即返回 403。
  • 所有模块均返回 NoOpinion → 请求被拒绝（默认拒绝）。
推荐组合：--authorization-mode=Node,RBAC,Webhook。Node 处理 kubelet 请求，RBAC 覆盖 95% 以上的日常权限管理，Webhook 作为策略兜底和动态扩展层。

1.7 本章小结

选择鉴权模式时，应基于集群规模、运维能力和企业安全需求综合判断：

  • RBAC 是绝大多数场景的最佳选择，原生支持、动态生效、生态完善。
  • ABAC 已处于弃用状态，仅建议在遗留系统中短期使用。
  • Webhook 适用于需要自定义鉴权逻辑或对接企业统一鉴权平台的场景。
← 上一章 📖 返回目录 下一章 →