Shulou(Shulou.com)05/31 Report--

How to use dynamic admission controller in CCS TKE? for this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Overview of the principle

The dynamic admission controller Webhook can change the request object or reject the request completely during the access authentication process. The way it calls the Webhook service makes it independent of the cluster component, so it has great flexibility and can easily do a lot of custom admission control. The following figure shows the position of the dynamic admission control in the API request call chain (from the Kubernetes official website):

As can be seen from the figure above, the dynamic admission control process is divided into two stages: first, the Mutating phase is executed, in which the arrival request can be modified, and then the Validating phase is executed to verify whether the incoming request is allowed. The two phases can be used alone or in combination. This article will implement a simple example of dynamic admission control call in TKE.

View the validation plug-in

Validating admission webhook and mutating admission webhook API are enabled by default in the existing cluster version of TKE (1.10.5 or above). For a lower version of the cluster, you can execute kube-apiserver-h in Apiserver Pod | grep enable-admission-plugins verifies whether the current cluster is enabled. If there are MutatingAdmissionWebhook and ValidatingAdmissionWebhook in the output plug-in list, the controller plug-in for dynamic access is enabled for the current cluster, as shown in the following figure:

Issue a certificate

In order to ensure that the dynamic admission controller invokes the trusted Webhook server, the Webhook service (TLS authentication) must be invoked through HTTPS, so you need to issue a certificate for the Webhook server, and bind the trusted authority certificate (CA) to the caBundle field (the caBundle field in the ValidatingWebhookConfiguration and MutatingAdmissionWebhook resource list) when registering the dynamic admission control Webhook to verify that the Webhook server's certificate is trusted. Here are two recommended methods for issuing certificates:

Note: when ValidatingWebhookConfiguration and MutatingAdmissionWebhook are configured using clientConfig.service (the Webhook service is in the cluster), the certificate domain name issued to the server must be... SVC.

Method 1: make self-signed certificate

The method of making self-signed certificate is relatively independent and does not depend on K8s cluster. It is similar to making a self-signed certificate for a website. There are many tools that can make self-signed certificate. In this example, Openssl is used to make self-signed certificate. The steps are as follows:

Generate a ca.key with 2048 key bits:

Openssl genrsa-out ca.key 2048

Generate ca.crt based on ca.key. "webserver.default.svc" is the domain name of the Webhook server in the cluster. Use the-days parameter to set the validity period of the certificate:

Openssl req-x509-new-nodes-key ca.key-subj "/ CN=webserver.default.svc"-days 10000-out ca.crt

Generate a server.key with 2048 key bits:

Openssl genrsa-out server.key 2048

i. An example of creating a profile csr.conf to generate a certificate signing request (CSR) is as follows:

[req] default_bits = 2048prompt = nodefault_md = sha256distinguished_name = dn [dn] C = cnST = shaanxiL = xi'anO = defaultOU = webseverCN = webserver.default.svc [v3_ext] authorityKeyIdentifier=keyid,issuer:alwaysbasicConstraints=CA:FALSEkeyUsage=keyEncipherment,dataEnciphermentextendedKeyUsage=serverAuth,clientAuth

Generate a certificate signing request based on the configuration file csr.conf:

Openssl req-new-key server.key-out server.csr-config csr.conf

Use ca.key, ca.crt, and server.csr to issue the generation server certificate (x509 signature):

Openssl x509-req-in server.csr-CA ca.crt-CAkey ca.key\-CAcreateserial-out server.crt-days 10000\-extensions v3_ext-extfile csr.conf

View the Webhook server-side certificate:

Openssl x509-noout-text-in. / server.crt

The generated certificate and key file are described as follows:

Ca.crt is the authority certificate, and ca.key is the authority certificate key, which is used for server certificate issuance.

Server.crt is the issued server certificate, and server.key is the issued server certificate key.

Method 2: issue using K8S CSR API

In addition to using solution 1 encryption tools to make self-signed certificates, you can also use K8s certificate authority system to issue certificates. Execute the following script to sign a trusted certificate user using K8s cluster root certificate and root key. Note that the user name should be the domain name of the Webhook service in the cluster:

USERNAME='webserver.default.svc' # set the user name to be created as the domain name of Webhook service in the cluster # generate self-signed certificate keyopenssl genrsa-out ${USERNAME} .key 204 using Openssl generate self-signed certificate CSR file using Openssl, and CN represents the user name O represents the group name openssl req-new-key ${USERNAME} .key-out ${USERNAME} .csr-subj "/ CN=$ {USERNAME} / object ${USERNAME}" # create Kubernetes certificate signature request (CSR) cat [cluster APIServer information] the clusters.cluster [] .certificate-authority-data field in the Kubeconfig content is obtained, which is already base64 encoded and does not need to be processed.

Copy the generated ca.crt (authority certificate), server.crt (HTTPS certificate), server.key (HTTPS key) to the project home directory:

Modify the Dockerfile in the project and add three certificate files to the container working directory:

Then use the docker command to build the Webhook server image:

Docker build-t webserver.

Deploy a Webhook backend service with the domain name "weserver.default.svc". The modified controller.yaml is as follows:

Register a resource with a type of ValidatingWebhookConfiguration. The Webhook trigger rule configured in this example is called when the pods type is created and the API version "v1" is created. The clientConfig configuration corresponds to the Webhook backend service created in the cluster, and the caBundle field content is the ca.crt content obtained by the certificate issuance method. Modify the admission.yaml file in the adaptation project as shown below:

Create a Pod type after registration. The test resources with API version "v1" are as follows:

The test code prints the request log. Looking at the Webhook server log, you can see that the dynamic admission controller triggers the webhook call, as shown below:

At this point, you can see that the created test pod is created successfully because the test Webhook server code is dead allowed: true, so it can be created successfully, as shown below:

For further verification, we change "allowed" to "false", and then repeat the above steps to re-image the Webserver server and redeploy controller.yaml and admission.yaml resources. When we try to create "pods" resources again, the request is blocked by dynamic admission, indicating that the configured dynamic admission policy is effective, as shown in the following figure:

This is the answer to the question on how to use the dynamic access controller in CCS TKE. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.