介绍
在本文中，我们将探讨webhook如何在kubernetes中工作，更具体地说是关于ImagePolicyWebhook。因为有关它的kubernetes文档有点含糊不清，也没有真正的示例。
本文基于ImagePolicyWebhook 或 ValidatingAdmissionWebhook，实现准入控制器将拒绝所有使用带有latest标签的镜像的Pod。
准入控制器（Admission Control）在授权后对请求做进一步的验证或添加默认参数。不同于授权和认证只关心请求的用户和操作，准入控制还处理请求的内容，并且仅对创建、更新、删除或连接（如代理）等有效，而对读操作无效。
对比：ImagePolicyWebhook 和 ValidatingAdmissionWebhook
ImagePolicyWebhook是准入控制器，仅评估镜像，你需要解析请求做逻辑和以允许或集群中否认镜像的响应。
ImagePolicyWebhook: 通过 webhook 决定 image 策略，需要同时配置 –admission-control-config-file，配置文件格式见 这里。
ImagePolicyWebhook优势：
- 如果无法连接Webhook端点，可以指示API服务器拒绝镜像，这非常方便，但是它也会带来问题，例如核心Pod无法调度。
ImagePolicyWebhook劣势：
- 配置涉及更多内容，并且需要访问主节点或apiserver配置，文档尚不明确，可能难以进行更改，更新等。
- 部署并不是那么简单，你需要使用systemd进行部署或将其作为docker容器在主机中运行，更新dns等。
ValidatingAdmissionWebhook使用 Webhook 验证请求，这些 Webhook 并行调用，并且任何一个调用拒绝都会导致请求失败 。
ValidatingAdmissionWebhook优势：
- 由于该服务作为Pod运行，因此部署更容易。
- 一切都可以成为kubernetes资源。
- 需要较少的人工干预和访问主机。
- 如果pod或服务不可用，则将允许所有镜像，这在某些情况下会带来安全风险，因此，如果要使用此路径，请确保使其高度可用，这实际上可以通过指定failurePolicytoFail来配置的Ignore（Fail是默认设置）。
ValidatingAdmissionWebhook劣势：
- 具有RBAC权限的任何人都可以更新/更改配置，因为它只是kubernetes的一个资源。
准备工作
构建
如果你打算将其用作普通服务：
$ go get github.com/kainlite/kube-image-bouncer
你还可以使用此Docker镜像：
$ docker pull kainlite/kube-image-bouncer
证书
如果你想了解更多信息，我们可以依靠kubernetes CA生成我们需要的证书。具体可以参考 管理群集中的TLS证书 。
创建一个CSR：
$ cat
