3. 鉴权机制基础：RBAC、ABAC、Node鉴权、Webhook鉴权的核心原理与对比
Kubernetes 的鉴权（Authorization）发生在身份认证（Authentication）之后，负责判断“已登录的用户/服务账号是否有权限执行当前请求”。Kubernetes 原生支持四种鉴权模式：RBAC（基于角色的访问控制）、ABAC（基于属性的访问控制）、Node鉴权（节点鉴权）和 Webhook鉴权（远程回调鉴权）。生产环境通常组合使用，以覆盖不同场景的安全需求。
3.1 四种鉴权模式的核心原理
3.1.1 RBAC（基于角色的访问控制）
RBAC 是 Kubernetes 1.8+ 的默认鉴权模式，也是生产环境最推荐的方式。其核心思想是：将权限授予角色（Role/ClusterRole），再将角色绑定到用户、组或服务账号（ServiceAccount）。
- Role / ClusterRole：定义一组规则（verbs + resources + resourceNames）。Role 作用于命名空间，ClusterRole 作用于集群范围。
- RoleBinding / ClusterRoleBinding：将角色与主体（subject）关联。
- 优势：细粒度、可审计、动态生效（无需重启 API Server）。
- 局限：无法基于请求属性（如时间、来源IP）做条件判断。
3.1.2 ABAC（基于属性的访问控制）
ABAC 是 Kubernetes 早期提供的鉴权模式，通过 JSON 策略文件定义权限规则。每个策略包含 user、group、apiGroup、resource、namespace、readonly 等属性。
- 策略示例：
{"apiVersion":"abac.authorization.kubernetes.io/v1beta1","kind":"Policy","spec":{"user":"alice","namespace":"*","resource":"pods","readonly":true}} - 生效方式：API Server 启动时加载策略文件，修改后必须重启 API Server。
- 优势：支持基于属性的灵活匹配。
- 局限：策略文件难以管理、变更需重启、不支持集群范围资源、已被 RBAC 取代。
3.1.3 Node鉴权（节点鉴权）
Node鉴权是一种专用鉴权模式，仅用于 kubelet 对 API Server 的访问。它自动授权 kubelet 读取自身节点信息、Pod 状态、Secret/ConfigMap 等资源。
- 授权规则：kubelet 只能操作以
system:node:<nodeName>命名的用户，且只能访问与自身节点相关的资源。 - 优势：无需手动配置节点权限，降低运维复杂度。
- 局限：仅适用于 kubelet 场景，不能用于普通用户或服务账号。
3.1.4 Webhook鉴权（远程回调鉴权）
Webhook鉴权允许将鉴权决策委托给外部 HTTP 服务。API Server 在收到请求后，将 SubjectAccessReview 对象 POST 到 Webhook 服务，根据返回的 allowed 字段决定是否放行。
- 工作流程：请求 → API Server → Webhook 服务 → 返回 allow/deny。
- 优势：可集成第三方鉴权系统（如 OPA、Open Policy Agent、自定义策略引擎），支持动态、复杂的策略逻辑。
- 局限：增加请求延迟（网络开销），Webhook 服务必须高可用。
3.2 四种鉴权模式的详细对比
| 对比维度 | RBAC | ABAC | Node鉴权 | Webhook鉴权 |
|---|---|---|---|---|
| 配置方式 | Kubernetes API 对象（YAML/JSON） | JSON 策略文件（启动时加载） | 自动启用（无需配置） | 外部 HTTP 服务 |
| 动态更新 | 是（立即生效） | 否（需重启 API Server） | 是 | 是（依赖 Webhook 服务） |
| 细粒度控制 | 高（资源、动词、命名空间） | 中（属性匹配） | 低（仅节点自身资源） | 极高（完全自定义） |
| 审计支持 | 强（原生审计日志） | 弱（策略文件变更无记录） | 中（kubelet 日志） | 强（可记录决策详情） |
| 生产推荐度 | ★★★★★（首选） | ★☆☆☆☆（已弃用） | ★★★★☆（必须启用） | ★★★★☆（补充方案） |
3.3 鉴权模式组合策略
Kubernetes 允许同时启用多种鉴权模式，API Server 按以下顺序依次检查：
- Webhook（如果配置）
- ABAC（如果启用）
- RBAC（如果启用）
- Node鉴权（如果启用）
只要任意一个模式返回 allow，请求即被放行；所有模式都返回 deny 时，请求被拒绝。
Node,RBAC,Webhook 组合。Node 鉴权处理 kubelet 请求，RBAC 处理用户和服务账号，Webhook 处理需要外部策略引擎的复杂场景。ABAC 已弃用，不建议在新集群中使用。
3.4 场景应用实践
3.4.1 场景一：多租户集群（RBAC + Webhook）
为不同团队创建命名空间，使用 RBAC 分配角色。同时通过 Webhook 集成 OPA，实现跨命名空间的资源配额校验和敏感操作审批。
3.4.2 场景二：边缘节点管理（Node鉴权 + RBAC）
kubelet 使用 Node鉴权自动获取节点信息，运维人员通过 RBAC 管理节点标签和污点。Webhook 用于限制非工作时间的大规模节点操作。
3.4.3 场景三：合规审计环境（Webhook + RBAC）
RBAC 提供基础权限隔离，Webhook 对接审计系统，记录所有敏感操作（如 Secret 读取、Pod 创建）并实时阻断违规行为。
3.5 配置示例
以下是在 kube-apiserver 启动参数中启用鉴权模式的示例：
# 启用 Node、RBAC、Webhook 三种模式
--authorization-mode=Node,RBAC,Webhook
--authorization-webhook-config-file=/etc/kubernetes/webhook-config.yaml
# 如果必须启用 ABAC（不推荐）
--authorization-mode=Node,RBAC,ABAC
--authorization-policy-file=/etc/kubernetes/abac-policy.jsonWebhook 配置文件示例（webhook-config.yaml）：
apiVersion: v1
kind: Config
clusters:
- name: authz-webhook
cluster:
server: https://authz.example.com/authorize
insecure-skip-tls-verify: false
certificate-authority: /etc/kubernetes/webhook-ca.crt
users:
- name: apiserver
user:
client-certificate: /etc/kubernetes/webhook-client.crt
client-key: /etc/kubernetes/webhook-client.key