动态准入控制

admission 控制器文档介绍如何使用标准的插件式 admission 控制器。然而，由于以下原因插件 admission 控制器对于所有用例来说都不够灵活：

他们需要编译到 kube-apiserver 里面。
它们仅在 apiserver 启动时可配置。

*Admission Webhooks*（1.9 版中的 beta）解决了这些限制。它允许 admission 控制器能被独立开发以及在运行时配置。

本页介绍如何使用 Admission Webhooks。

什么是 admission webhook？

Admission webhooks 是 HTTP 回调，它接收 admission 请求并对它们做一些事情。您可以定义两种类型的 admission webhook， validating admission Webhook 和 mutating admission webhook。通过 validating admission Webhook，您可以拒绝请求以执行自定义的 admission 策略。通过 mutating admission webhook，您可以更改请求以执行自定义的默认值。

尝试 admission webhook

admission webhook 本质上是集群控制平面的一部分。您应该非常谨慎地编写和部署它们。如果您打算编写/部署生产级 admission webhook，请阅读用户指南以获取相关说明。在下文中，我们将介绍如何快速试验 admission webhook。

先决条件

确保 Kubernetes 集群版本至少为 v1.9。
确保启用 MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook 控制器。这里是一组推荐的 admission 控制器，通常可以启用。
确保启用了admissionregistration.k8s.io/v1beta1 API。

编写一个admission webhook 服务器

请参阅 Kubernetes e2e 测试中的 admission webhook 服务器实现。 webhook 处理由 apiservers 发送的 admissionReview 请求，并将其决定包含在 admissionResponse 中发回。

admissionReview 请求可以有不同的版本（例如，v1beta1 或未来版本中的 v1）。 webhook 可以使用 admissionReviewVersions 字段定义它们接受的版本。 API 服务器将尝试在其支持的列表中使用第一个版本。如果 API 服务器不支持此列表中指定的任何版本，则此对象的验证将失败。如果 webhook 配置依然如此，则对 webhook 的调用将失败并受到失败策略的控制。

示例 admission webhook 服务器置 ClientAuth 字段为空，默认为 NoClientCert 。这意味着 webhook 服务器不会验证客户端的身份，认为其是 apiservers。如果您需要双向 TLS 或其他方式来验证客户端，请参阅如何验证 apiservers。

部署 admission webhook 服务

e2e 测试中的 webhook 服务器部署在 Kubernetes 集群中，通过 deployment API。该测试还创建了 service 作为 webhook 服务器的前端。参见代码。

您还可以在集群外部署 Webhook，这需要相应地更新 webhook 客户端配置。

动态配置 admission webhook

您可以通过 ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration 动态配置哪些资源通过哪些 admission webhook

以下是 validatingWebhookConfiguration 的示例，Mutating Webhook Configuration 类似。

apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
  name: <name of this configuration object>
webhooks:
- name: <webhook name, e.g., pod-policy.example.io>
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: "Namespaced"
  clientConfig:
    service:
      namespace: <namespace of the front-end service>
      name: <name of the front-end service>
    caBundle: <pem encoded ca cert that signs the server cert used by the webhook>
  admissionReviewVersions:
  - v1beta1
  timeoutSeconds: 1

scope 字段指定是否只有集群范围的资源（“Cluster”）或命名空间范围的资源（“Namespaced”）才匹配此规则。 “*” 表示没有范围限制。

Note: 使用clientConfig.service时，服务器证书必须对<svc_name>.<svc_namespace>.svc有效。

Note: webhook 调用的默认超时为 30 秒，但从 kubernetes 1.14 开始，您可以设置超时，并鼓励对 webhook 使用非常小的超时时间。如果 webhook 调用超时，则根据 webhook 的失败策略处理请求。

当一个 apiserver 收到一个与 rules 之一匹配的请求时，apiserver 会向 clientConfig 中指定的 webhook 发送一个 admissionReview 请求。

创建 webhook 配置后，系统将花费几秒钟来完成新配置的生效。

验证 apiservers

如果您的 webhooks 需要身份验证，您可以将 apiservers 配置为使用基本身份验证，不记名令牌或证书来对 webhook 进行身份验证。完成配置有三个步骤。

启动apiserver时，通过 --admission-control-config-file 参数指定许可控制配置文件的位置。

在准入控制配置文件中，指定 MutatingAdmissionWebhook 控制器和 ValidatingAdmissionWebhook 控制器应该读取凭据的位置。凭证存储在 kubeConfig 文件中（是的，与 kubectl 使用的模式相同），因此字段名称为kubeConfigFile。以下是一个示例准入控制配置文件：

apiVersion: apiserver.k8s.io/v1alpha1
kind: AdmissionConfiguration
plugins:
- name: ValidatingAdmissionWebhook
configuration:
apiVersion: apiserver.config.k8s.io/v1alpha1
kind: WebhookAdmission
kubeConfigFile: <path-to-kubeconfig-file>
- name: MutatingAdmissionWebhook
configuration:
apiVersion: apiserver.config.k8s.io/v1alpha1
kind: WebhookAdmission
kubeConfigFile: <path-to-kubeconfig-file>

admissionConfiguration 的 shcema 在这里.

在 kubeConfig 文件中，提供凭据：

apiVersion: v1
kind: Config
users:
# DNS name of webhook service, i.e., <service name>.<namespace>.svc, or the URL
# of the webhook server.
- name: 'webhook1.ns1.svc'
user:
client-certificate-data: <pem encoded certificate>
client-key-data: <pem encoded key>
# The `name` supports using * to wildmatch prefixing segments.
- name: '*.webhook-company.org'
user:
password: <password>
username: <name>
# '*' is the default match.
- name: '*'
user:
token: <token>

当然，您需要设置 webhook 服务器来处理这些身份验证。

反馈

此页是否对您有帮助？

Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.

参考