Kubernetes控制平面组件：API Server Webhook 授权机制 详解

云原生学习路线导航页（持续更新中）

• kubernetes学习系列快捷链接
  • Kubernetes架构原则和对象设计（一）
  • Kubernetes架构原则和对象设计（二）
  • Kubernetes架构原则和对象设计（三）
  • Kubernetes控制平面组件：etcd（一）
  • Kubernetes控制平面组件：etcd（二）
  • Kubernetes控制平面组件：etcd常用配置参数
  • Kubernetes控制平面组件：etcd高可用集群搭建
  • Kubernetes控制平面组件：etcd高可用解决方案
  • Kubernetes控制平面组件：Kubernetes如何使用etcd
  • Kubernetes控制平面组件：API Server详解（一）
  • Kubernetes控制平面组件：APIServer 基于 X509 证书的认证机制
  • Kubernetes控制平面组件：APIServer 基于 静态Token 的认证机制
  • Kubernetes控制平面组件：APIServer 基于 引导Token 的认证机制
  • Kubernetes控制平面组件：APIServer 基于 ServiceAccount 的认证机制
  • Kubernetes控制平面组件：APIServer 基于 OpenID 的认证机制详解
  • Kubernetes控制平面组件：APIServer 基于 Webhook Toeken令牌 的认证机制详解
  • Kubernetes控制平面组件：APIServer 基于匿名请求的认证机制详解
  • kubectl 和 kubeconfig 基本原理
  • kubeadm 升级 k8s集群 1.17到1.20
  • Kubernetes常见问题解答
  • 查看云机器的一些常用配置

本文主要对kubernetes的控制面组件API Server 授权机制中的 Webhook 授权机制进行详细介绍，涵盖Webhook机制基础概念、设计理念、实现原理、授权流程、参数配置等

• 希望大家多多 点赞 关注 评论 收藏，作者会更有动力编写技术文章

1.基础概念

1.1.Webhook 机制定义

• Webhook 是 Kubernetes 的扩展机制之一，允许将授权决策委托给外部 HTTP 服务。
• 当 API Server 收到资源操作请求时，会将请求转发至预先配置的外部 Webhook 服务进行权限验证，并根据其返回结果决定是否允许该操作。

1.2.核心设计理念

• 解耦性：将授权逻辑从 Kubernetes 核心组件中剥离，通过外部服务实现灵活的策略管理。
• 动态策略：无需重启 API Server 即可动态更新授权规则，适应快速变化的业务需求。
• 多租户支持：结合企业级身份认证系统（如 LDAP、OAuth）实现细粒度权限控制。

1.3.与 RBAC 的区别

• RBAC：基于角色和静态策略，适用于固定权限模型。
• Webhook：支持动态、外部化策略，适用于复杂场景（如跨系统鉴权、自定义规则）。

1.4.Webhook认证 与 Webhook授权 异同辨析

• 相同点：
  • 设计理念相同。认证/授权 均有Webhook的扩展机制，都是允许将当前请求发送到第三方服务进行认证/授权，apiserver 根据返回结果决定是否通过 认证/授权
  • 使用方式类似。都是使用kubeconfig格式指定第三方服务的url、cert等信息，供apiserver与之交互使用
• 不同点：
  • apiserver配置文件参数不同。在apiserver的参数中需要指定第三方服务的配置文件，认证参数：--authentication-token-webhook-config-file，授权参数：--authorization-webhook-config-file
  • 调用时机不同。在API Server处理链路中，认证在前，授权在后。

1.5.API Server启用webhook授权机制

• --authorization-mode=Webhook
• 使用 Webhook 授权机制需显式启用 authorization.k8s.io/v1beta1 API 扩展组：--runtime-config=authorization.k8s.io/v1beta1=true。

2.实现原理

2.1 核心组件交互

• API Server：作为请求入口，负责接收客户端请求，在合适时机将请求封装为 SubjectAccessReview 结构转发至 Webhook
• Webhook 服务：webhook服务，接收apiserver的 SubjectAccessReview 对象，可以自行处理授权，也可以作为代理调用第三方授权服务，将返回结果封装后将allowed 或 denied 返回给apiserver。
• 第三方授权服务：独立的第三方授权服务，一般为企业独立的授权模块，可以通过webhook代理插入apiserver。

如果 第三方授权服务 本身就可以处理 SubjectAccessReview 请求，那也可以省略中间的webhook代理服务

2.2 请求处理流程

1. 请求接收：客户端发起 API 请求（如 kubectl create）。
2. 认证与预检：完成 TLS 握手和身份认证（如 ServiceAccount Token）。
3. Webhook 匹配：根据资源配置（rules）判断是否触发 Webhook。
4. 请求转发：API Server 将请求封装为 SubjectAccessReview JSON 对象，通过 HTTPS 发送至 Webhook 代理服务。
5. 策略决策：Webhook 解析请求属性（用户、资源、操作），执行自定义逻辑（如调用外部权限系统）。
6. 响应处理：返回 allowed: true/false，若拒绝需附带原因（reason）。

3.参数配置

可以直接看官方文档：https://kubernetes.io/zh-cn/docs/reference/access-authn-authz/webhook/

3.1.配置文件格式

• Webhook 模式需要一个 HTTP 配置文件，通过 --authorization-webhook-config-file=SOME_FILENAME 的参数声明。
• 配置文件的格式使用 kubeconfig。 在该文件中，“users” 代表着 API 服务器的 Webhook，而 “cluster” 代表着远程服务。
• 使用 HTTPS 客户端认证的配置例子：

# Kubernetes API 版本
apiVersion: v1
# API 对象种类
kind: Config
# clusters 代表远程服务
clusters:- name: name-of-remote-authz-servicecluster:# 对远程服务进行身份认证的 CAcertificate-authority: /path/to/ca.pem# 远程服务的查询 URL。必须使用 'https'。不可以包含参数。server: https://authz.example.com/authorize# users 代表 API 服务器的 webhook 配置
users:- name: name-of-api-serveruser:client-certificate: /path/to/cert.pem # 要使用的 webhook 插件的证书client-key: /path/to/key.pem          # 与证书匹配的密钥# kubeconfig 文件必须有 context。需要提供一个给 API 服务器。
current-context: webhook
contexts:
- context:cluster: name-of-remote-authz-serviceuser: name-of-api-servername: webhook

3.2.请求载荷

• 在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 authorization.k8s.io/v1beta1 SubjectAccessReview 对象来描述这个动作。
• 这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。

// 请求SubjectAccessReview：资源类
{"apiVersion": "authorization.k8s.io/v1beta1","kind": "SubjectAccessReview","spec": {"resourceAttributes": {"namespace": "kittensandponies","verb": "get","group": "unicorn.example.org","resource": "pods"},"user": "jane","group": ["group1","group2"]}
}// 请求SubjectAccessReview：非资源类
{"apiVersion": "authorization.k8s.io/v1beta1","kind": "SubjectAccessReview","spec": {"nonResourceAttributes": {"path": "/debug","verb": "get"},"user": "jane","group": ["group1","group2"]}
}

3.3.请求响应

// 响应：通过授权
{"apiVersion": "authorization.k8s.io/v1beta1","kind": "SubjectAccessReview","status": {"allowed": true}
}// 响应：未通过授权，但未显式拒绝，如果还有其他授权服务，会继续调用
{"apiVersion": "authorization.k8s.io/v1beta1","kind": "SubjectAccessReview","status": {"allowed": false,"reason": "user does not have read access to the namespace"}
}// 响应：未通过授权，并且显式拒绝，如果还有其他授权服务，不会再继续调用
{"apiVersion": "authorization.k8s.io/v1beta1","kind": "SubjectAccessReview","status": {"allowed": false,"denied": true,"reason": "user does not have read access to the namespace"}
}

4.实操案例

• 可以参考 Kubernetes控制平面组件：APIServer 基于 Webhook Toeken令牌 的认证机制详解 中的实操案例，认证和授权的webhook使用方式基本一致，仅仅是apiserver的配置文件参数不同而已