Kubernetes准入控制简单实践

1. 准入控制

一般我们操作Kubernetes资源的流程是如下这样的：

API Server认证；
API Server鉴权；
APT Server实际处理请求并持久化到ETCD；

而准入控制则具有一种能力，它可以在认证、鉴权之后对象被持久化之前对请求进行拦截，只有这些准入控制都通过之后才允许放行请求。截止Kubernetes v1.17版本，它自身已经内置支持很多admission插件，详情可移步Kubernetes内置准入控制器列表，但这些不是笔者在此述说的重点，今天主要谈谈admission插件在实际环境的动态扩展实现：admission webhook。

2. Admission Webhook

Admission webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。可以定义两种类型的 admission webhook，即 validating admission webhook 和 mutating admission webhook。 Mutating admission webhook 会先被调用。它们可以更改发送到 API 服务器的对象以执行自定义的设置默认值操作。

在完成了所有对象修改并且 API 服务器也验证了所传入的对象之后，validating admission webhook 会被调用，并通过拒绝请求的方式来强制实施自定义的策略。

如下针对admission webhook做一个简单的实践。

3. 实践

本文实例源码可参考：https://github.com/VeinFu/admission_webhook_example

3.1 功能需求

ValidatingAdmissionWebhook：创建Pod时，当这个Pod存在于test-misssion命名空间中且标签run: test-admission时则对该Pod其他标签进行校验，如果不存在必须满足的标签test-admission、admission-wenhook时则拦截该创建Pod的请求；
MutatingAdmissionWebhook：创建Pod时，当这个Pod存在于test-misssion命名空间中且标签run: test-admission时则对该Pod添加额外两个标签：test-admission、admission-wenhook；

3.2 代码部分

代码很简单，主要用到如下两个golang库：net/http和k8s.io/api/admission/v1beta1，前者用来启动一个HTTPS Server，后者用来处理admission的请求和响应的。

具体代码的逻辑就不在此逐一分析了，如下几点简单说明一下：

webhook服务是https协议接口，因此Kubernetes API Server和Webhook Server之间要做TLS认证，这里直接使用了集群根证书颁发机构(CA)来进行证书的签发，具体操作步骤如下：

# 一般集群CA私钥、证书存放在master节点的/etc/kubernetes/ssl目录下
# 生成webhook server的私钥
openssl genrsa -out server.key 2048

# 创建webhook server csr
openssl req -new -key server.key -subj "/CN=admission-service.default.svc" -out server.csr

# 创建webhook server证书
openssl x509 -req -in server.csr -CA /etc/kubernetes/ssl/ca.pem -CAkey /etc/kubernetes/ssl/ca-key.pem -CAcreateserial -out server.crt -days 10000

# 创建对应的secret
kubectl create secret generic webhook-server --from-file=server.key --from-file=server.crt

# 在部署webhook server应用时对此secret进行挂载，如此就可以实现kube-apiserver和webhook server的双向认证了。

上面进行证书签发时common name填的是admission-service.default.svc，如此就得保证集群层面是可以识别到这个域名，借助Core-DNS可以解决这个问题，先获取core-dns服务对应的Cluster-IP，然后将其配置到域名配置文件/etc/resolv.conf中：

如果域名设置不生效可以尝试systemctl stop/disable Network-Manager。

3.3 部署

首先下载源码至$GOPATH/src目录中进行镜像构建。

然后参照如下步骤部署webhook server即可：

# 创建test-admisssion命名空间
kubectl create ns test-admisssion
# 部署webhook server应用
kubectl create -f deploy/admission-server-deploy.yaml

3.4 测试

如下对两个admission webhook各自简单测试一下：

ValidatingWebhook测试

# 创建validationwebhook配置实例
[root@m01 ~] kubectl create -f deploy/validate-config.yaml  # 这个配置会存在caBundle的字段，值直接填入kubeconfig对应字段`certificate-authority-data`的值即可。
[root@m01 ~] cat deploy/test/test-admission-label-no.yaml
kind: Pod
apiVersion: v1
metadata:
  namespace: test-admisssion
  name: nginx-app
spec:
  containers:
  - name: nginx
    image: nginx
  restartPolicy: "Always"
[root@m01 ~] cat deploy/test/test-admission-label-no.yaml | kubectl create -f -
pod/nginx-app created
[root@m01 ~] kubectl get pod -n test-admisssion
NAME        READY   STATUS    RESTARTS   AGE
nginx-app   1/1     Running   0          6s
[root@m01 ~]

很显然，这个pod没有标签run: test-admission，因此不受该validatewebhook的限制，与期望相符。

[root@m01 ~] cat deploy/test/test-admission-label-yes.yaml
kind: Pod
apiVersion: v1
metadata:
  namespace: test-admisssion
  name: nginx-app-test
  labels:
    run: test-admission
spec:
  containers:
  - name: nginx
    image: nginx
  restartPolicy: "Always"
[root@m01 ~] cat deploy/test/test-admission-label-yes.yaml | kubectl create -f -
Error from server (required label is not set): error when creating "STDIN": admission webhook "admission-service.default.svc" denied the request: required label is not set
[root@m01 ~]

这个pod具有标签run: test-admission但是没有其他必备的标签，因此该api请求被拦截导致创建pod失败，也与期望相符。

MutatingWebhook测试

测试方法类似不再赘述，按如下步骤操作即可：

kubectl create -f deploy/mutate-config.yaml
kubectl create -f deploy/test/test-admission-label-no.yaml
kubectl create -f deploy/test/test-admission-label-yes.yaml

之后去查询新建的容器组nginx-app-test可以看到其新增了两个标签，与期望相符。

好啦，有关这次Kubernetes admission webhook的讲解就先到此了，后续有机会再继续深入。