Webhook 模式

    具体来说，当在判断用户权限时， 模式会使 Kubernetes 查询外部的 REST 服务。

    Webhook 模式需要一个 HTTP 配置文件，通过 --authorization-webhook-config-file=SOME_FILENAME 的参数声明。

    配置文件的格式使用 。 在该文件中，“users” 代表着 API 服务器的 webhook，而 “cluster” 代表着远程服务。

    使用 HTTPS 客户端认证的配置例子：

    请求载荷

    需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都遵从。 实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 “apiVersion” 字段能被正确地反序列化。 此外，API 服务器还必须启用 authorization.k8s.io/v1beta1 API 扩展组 (--runtime-config=authorization.k8s.io/v1beta1=true)。

    一个请求内容的例子：

    1. {
    2.   "apiVersion": "authorization.k8s.io/v1beta1",
    3.   "kind": "SubjectAccessReview",
    4.   "spec": {
    5.     "resourceAttributes": {
    6.       "namespace": "kittensandponies",
    7.       "verb": "get",
    8.       "group": "unicorn.example.org",
    9.       "resource": "pods"
    10.     },
    11.     "user": "jane",
    12.       "group1",
    13.       "group2"
    15.   }
    16. }

    期待远程服务填充请求的 status 字段并响应允许或禁止访问。响应主体的 spec 字段被忽略，可以省略。允许的响应将返回:

    为了禁止访问，有两种方法。

    1. {
    2.   "apiVersion": "authorization.k8s.io/v1beta1",
    3.   "kind": "SubjectAccessReview",
    4.   "status": {
    5.     "allowed": false,
    6.     "reason": "user does not have read access to the namespace"
    7.   }
    8. }

    第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回：

    对于非资源的路径访问是这么发送的:

    1.   "apiVersion": "authorization.k8s.io/v1beta1",
    2.   "kind": "SubjectAccessReview",
    3.   "spec": {
    4.     "nonResourceAttributes": {
    5.       "path": "/debug",
    6.       "verb": "get"
    7.     },
    9.     "group": [
    10.       "group1",
    11.       "group2"
    12.     ]
    13.   }

    非资源类的路径包括：/api、/apis、/metrics、/logs、/debug、 /healthz、/livez、/openapi/v2、/readyz、和 /version。 客户端需要访问 /api、/api/*、/apis、/apis/* 和 以便 能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。

    更多信息可以参考 authorization.v1beta1 API 对象和 webhook.go。