Webhook 模式
Webhook 是一个 HTTP 回调：当发生某些事件时，会触发一个 HTTP POST 请求；一种简单的通过 HTTP POST 实现的事件通知。实现 Webhook 的 Web 应用程序将在发生某些事件时，将消息 POST 到一个 URL。
当指定时，模式 Webhook 会导致 Kubernetes 在确定用户权限时查询外部 REST 服务。
配置文件格式
模式 Webhook 需要一个用于 HTTP 配置的文件，通过 --authorization-webhook-config-file=SOME_FILENAME 标志指定。
配置文件使用 kubeconfig 文件格式。在文件中，“users” 指的是 API 服务器 webhook，而“clusters” 指的是远程服务。
使用 HTTPS 客户端身份验证的配置示例
# Kubernetes API version
apiVersion: v1
# kind of the API object
kind: Config
# clusters refers to the remote service.
clusters:
- name: name-of-remote-authz-service
cluster:
# CA for verifying the remote service.
certificate-authority: /path/to/ca.pem
# URL of remote service to query. Must use 'https'. May not include parameters.
server: https://authz.example.com/authorize
# users refers to the API Server's webhook configuration.
users:
- name: name-of-api-server
user:
client-certificate: /path/to/cert.pem # cert for the webhook plugin to use
client-key: /path/to/key.pem # key matching the cert
# kubeconfig files require a context. Provide one for the API Server.
current-context: webhook
contexts:
- context:
cluster: name-of-remote-authz-service
user: name-of-api-server
name: webhook
请求有效负载
在面对授权决策时，API 服务器会 POST 一个 JSON 序列化的 authorization.k8s.io/v1beta1 SubjectAccessReview 对象，描述该操作。该对象包含描述尝试进行请求的用户，以及关于正在访问的资源的详细信息或请求属性的字段。
请注意，webhook API 对象受与其他 Kubernetes API 对象相同的 版本兼容性规则 约束。实施者应注意，beta 对象的兼容性承诺较弱，并应检查请求的“apiVersion”字段以确保正确反序列化。此外，API 服务器必须启用 authorization.k8s.io/v1beta1 API 扩展组 (--runtime-config=authorization.k8s.io/v1beta1=true)。
请求主体示例
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "kittensandponies",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
},
"user": "jane",
"group": [
"group1",
"group2"
]
}
}
预期远程服务将填写请求的 status 字段，并响应允许或拒绝访问。响应主体的 spec 字段将被忽略，可以省略。允许访问的响应将返回
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": true
}
}
对于拒绝访问，有两种方法。
第一种方法在大多数情况下是首选的，表明授权 webhook 不允许或对请求“没有意见”，但如果配置了其他授权者，则会给他们机会允许请求。如果没有其他授权者，或者没有任何一个授权者允许请求，则该请求将被禁止。webhook 将返回
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": false,
"reason": "user does not have read access to the namespace"
}
}
第二种方法立即拒绝，短路其他配置的授权者的评估。这应该只被拥有对集群完整授权者配置的详细了解的 webhook 使用。webhook 将返回
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"status": {
"allowed": false,
"denied": true,
"reason": "user does not have read access to the namespace"
}
}
对非资源路径的访问将被发送为
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"nonResourceAttributes": {
"path": "/debug",
"verb": "get"
},
"user": "jane",
"group": [
"group1",
"group2"
]
}
}
Kubernetes v1.31 [alpha]启用 AuthorizeWithSelectors 功能后，请求中的字段和标签选择器将被传递给授权 webhook。webhook 可以根据范围限定的字段和标签选择器做出授权决策，如果它愿意的话。
SubjectAccessReview API 文档 提供了有关授权 webhook 如何解释和处理这些字段的指导，特别是如何使用解析后的需求而不是原始选择器字符串，以及如何安全地处理无法识别的运算符。
{
"apiVersion": "authorization.k8s.io/v1beta1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"verb": "list",
"group": "",
"resource": "pods",
"fieldSelector": {
"requirements": [
{"key":"spec.nodeName", "operator":"In", "values":["mynode"]}
]
},
"labelSelector": {
"requirements": [
{"key":"example.com/mykey", "operator":"In", "values":["myvalue"]}
]
}
},
"user": "jane",
"group": [
"group1",
"group2"
]
}
}
非资源路径包括：/api、/apis、/metrics、/logs、/debug、/healthz、/livez、/openapi/v2、/readyz 和 /version. 客户端需要访问 /api、/api/*、/apis、/apis/* 和 /version 来发现服务器上存在的资源和版本。可以拒绝访问其他非资源路径，而不会限制对 REST API 的访问。
有关更多信息，请参阅 SubjectAccessReview API 文档 和 webhook.go 实现。