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.32 [beta] (預設啟用：true)啟用 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 實作。