The dynamic admission controller Webhook can change the request object or completely reject a request during access authentication. The way it calls the Webhook service makes it independent of cluster components.
The dynamic admission controller has a high degree of flexibility and allows you to configure various custom admission control settings. The following figure shows the position of dynamic admission control in the API request call chain. For more information, visit the official Kubernetes website.
As shown in the figure, dynamic admission control is divided into two phases: Mutating and Validating. During the Mutating phase, incoming requests can be modified. Subsequently, during the Validating phase, the dynamic admission controller validates incoming requests to determine whether to allow them to pass. These two phases can be used independently or in combination.
This document introduces a simple use case for calling the dynamic admission controller in TKE. You can refer to this document and take your actual requirements into consideration when performing the relevant operations.
The existing TKE cluster versions (1.10.5 and later) enable the validating admission webhook and mutating admission webhook APIs by default. If your cluster version is earlier than 1.10.5, you can run the following command to check whether the plug-in has been enabled in your current cluster.
kube-apiserver -h | grep enable-admission-plugins
If the returned result includes MutatingAdmissionWebhook
and ValidatingAdmissionWebhook
, the dynamic admission controller is already enabled in the cluster, as shown in the figure below:
To ensure that the dynamic admission controller calls a trustworthy Webhook server, it needs to call the Webhook service (TLS certification) via HTTPS. Therefore, you need to issue a certificate to the Webhook server. During registration of the dynamic admission controller Webhook, you need to bind the caBundle
field (caBundle
field in the resource list of ValidatingWebhookConfiguration
and MutatingAdmissionWebhook
) with a trustworthy certificate authority (CA) to verify whether the Webhook server certificate is trustworthy. This document introduces two recommended methods for issuing certificates: making a self-signed certificate and using the K8S CSR API to issue a certificate.
Note:
When
ValidatingWebhookConfiguration
andMutatingAdmissionWebhook
use theclientConfig.service
configuration (and the Webhook service is in the cluster), the domain name of the certificate issued to the server must be<svc_name>.<svc_namespace>.svc
.
This method is not dependent on Kubernetes clusters and is relatively independent. It’s similar to the way in which websites make their own self-signed certificates. Currently, many tools can be used to make a self-signed certificate. This document uses OpenSSL as an example. The procedure is as follows:
ca.key
with 2048 key digits.openssl genrsa -out ca.key 2048
ca.crt
based on the ca.key
.-days
parameter is used to specify the validity period of the certificate.openssl req -x509 -new -nodes -key ca.key -subj "/CN=webserver.default.svc" -days 10000 -out ca.crt
server.key
with 2048 key digits.openssl genrsa -out server.key 2048
csr.conf
used to generate a certificate signature request (CSR). See the sample below: [ req ]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn
[ dn ]
C = cn
ST = shaanxi
L = xi'an
O = default
OU = websever
CN = webserver.default.svc
[ v3_ext ]
authorityKeyIdentifier=keyid,issuer:always
basicConstraints=CA:FALSE
keyUsage=keyEncipherment,dataEncipherment
extendedKeyUsage=serverAuth,clientAuth
csr.conf
.openssl req -new -key server.key -out server.csr -config csr.conf
ca.key
, ca.crt
, and server.csr
to issue the generated 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
openssl x509 -noout -text -in ./server.crt
The generated certificates and key files are described as follows:ca.crt
: the CA certificateca.key
: the CA certificate key, used to issue a server certificateserver.crt
: the issued server certificateserver.key
: the issued server certificate key
You can also use the Kubernetes CA system to issue a certificate. You can execute the following script to use the Kubernetes cluster root certificate and root key to issue a trustworthy certificate user.
Note:
The username must be the domain name of the Webhook service in the cluster.
USERNAME='webserver.default.svc' # Set the username to be created to the domain name of the Webhook service in the cluster
# Use OpenSSL to generate a self-signed certificate key
openssl genrsa -out ${USERNAME}.key 2048
# Use OpenSSL to generate a self-signed CSR file, with CN indicating the user name and O indicating the group name
openssl req -new -key ${USERNAME}.key -out ${USERNAME}.csr -subj "/CN=${USERNAME}/O=${USERNAME}"
# Create a Kubernetes CSR
cat <<EOF | kubectl apply -f -
apiVersion: certificates.k8s.io/v1beta1
kind: CertificateSigningRequest
metadata:
name: ${USERNAME}
spec:
request: $(cat ${USERNAME}.csr | base64 | tr -d '\n')
usages:
- digital signature
- key encipherment
- server auth
EOF
# Approve the certificate as trustworthy
kubectl certificate approve ${USERNAME}
# Obtain the self-signed certificate CRT
kubectl get csr ${USERNAME} -o jsonpath={.status.certificate} > ${USERNAME}.crt
${USERNAME}
.crt: the Webhook server certificate${USERNAME}
.key: the Webhook server certificate keyThis document uses ValidatingWebhookConfiguration
resources to illustrate how to call the dynamic admission controller Webhook.
To ensure accessibility, the sample code is forked from the original code library to implement a simple API for dynamic admission Webhook requests and responses. For the detailed API format, see Webhook request and response. The sample code can be obtained in Sample Code. This document uses it as the Webhook server code.
caBundle
content corresponding to the actual certificate issuance method.base64
to encode ca.crt
and generate the caBundle
field content.cat ca.crt | base64 --wrap=0
caBundle
field content. The procedure for obtaining it is as follows:clusters.cluster[].certificate-authority-data
field in "Kubeconfig" in the "Cluster APIServer Info" module. This field has been encoded in base64
, and no further processing is needed.ca.crt
(CA certificate), server.crt
(HTTPS certificate), and server.key
(HTTPS key) to the main directory of the project, as shown in the figure below:docker build -t webserver .
controller.yaml
, as shown in the figure below:ValidatingWebhookConfiguration
type, and modify the admission.yaml
file in the adapted project, as shown in the figure below:pods
type and version "v1" is created, Webhook is triggered. The configuration of clientConfig
corresponds to the above Webhook backend service created in the cluster. The caBundle
field content is the content of the ca.crt
obtained in method 1.allowed: true
configuration item, the test pod has been created successfully, as shown in the figure below:controller.yaml
and admission.yaml
resources. If the request of your reattempt to create pods resources is intercepted by the dynamic admission controller, then the configured dynamic admission policy has taken effect, as shown in the figure below:This document mainly introduces the concept and functionality of the dynamic admission controller Webhook, as well as how to issue certificates needed by the dynamic admission controller in a TKE cluster. This document also describes a simple use case for configuring and using the dynamic admission Webhook feature.
Was this page helpful?