WHY
在 Kubernetes 中还有 authn/authz，为什么还会引入 admission 这种机制？
认证鉴权运行在 filter 中，只能获取 http 请求 header 以及证书，并不能获取请求的 body。所以 authn/authz 只能对客户端进行认证和鉴权，不可以对请求的对象进行任何操作
Admission 运行在 API Server 的增删改查 handler 中，可以操作 API resource
目前 Kubernetes 中有非常多的 Admission 插件， 但并不能保证满足所有的需求。 Kbernetes 可扩展能力功不可没。Admission 也提供了一种 webhook 的扩展机制。
WHAT
Admission Controller（准入控制）是 Kubernetes API Server 用于拦截请求的一种手段。Admission可以做到对请求的资源对象进行校验，修改。
- MutatingAdmissionWebhook：在对象持久化之前进行修改
- ValidatingAdmissionWebhook：在对象持久化之前进行
引入网上的流程：Admission Controller 工作流程
- API Server 接收到客户端请求后首先进行认证鉴权，认证鉴权后才会进行 endpoint handler 处理
- 当API Server 接收到对象后根据 http 的路径可以得到版本号，然后将 body 反序列化成 versioned object
- versioned object 转化为 internal object，即没有版本的内部类型，这种资源类型是所有 versioned 类型的超集。只有转化为 internal 后才能适配所有的客户端 versioned object 的校验
- Admission Controller 具体的 admit 操作，可以通过这里修改资源对象，例如为 Pod 挂载一个默认的 Service Account 等
- API Server internal object validation，校验某个资源对象数据和格式是否合法，例如：Service Name 的字符个数不能超过63等
- Admission Controller validate，可以自定义任何的对象校验规则
- internal object 转化为 versioned object，并且持久化存储到 etcd
HOW
Kubernetes 1.10之前的版本，
--admission-control打开 Admission Controller。同时--admission-control的顺序决定 Admission 运行的先后Kubernetes 1.10之后的版本，
--admission-control已经废弃，建议使用--enable-admission-plugins --disable-admission-plugins指定需要打开或者关闭的 Admission Controller。 同时用户指定的顺序并不影响实际 Admission Controllers 的执行顺序--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,Priority,ResourceQuota,PodSecurityPolicy
Webhook Admission 属于同步调用，需要部署自己的 webhook server，创建自定义的配置资源对象： ValidatingWebhookConfiguration 或 MutatingWebhookConfiguration
# kubectl api-resources | grep webhook
mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfigurationadmissionregistration.k8s.io/v1beta1 API enable 状态
# kubectl api-versions | grep admissionregistration.k8s.io/v1beta1
admissionregistration.k8s.io/v1beta1
HOW 部署
定义 ValidatingWebhookConfiguration 或者 MutatingWebhookConfiguration
apiVersion: admissionregistration.k8s.io/v1beta1
kind: MutatingWebhookConfiguration
metadata:
name: <name>
labels:
app: <label>
webhooks:
- name: <webhook name, e.g., pod-policy.example.io> 逗号分割，限制必须三段
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>
rules:
- operations: [ "CREATE" ]
apiGroups: [""]
apiVersions: ["v1"]
resources: ["pods"]
namespaceSelector:
matchLabels:
<key>: <value>
创建自己的 webhook 程序流程
- 创建TLS Certificate，即证书
- 编写服务端代码，服务端代码需要使用证书
- 根据证书创建k8s sercret
- 创建k8s Deployment和Service
- 创建k8s WebhookConfiguration，其中需要使用之前创建的证书
参考：
