Release Notes
Announcements
Release Notes

kube-apiserver -h | grep enable-admission-plugins
MutatingAdmissionWebhook and ValidatingAdmissionWebhook, the dynamic admission controller is already enabled in the cluster, as shown in the figure below:

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.ValidatingWebhookConfiguration and MutatingAdmissionWebhook use the clientConfig.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.ca.key with 2048 key digits.openssl genrsa -out ca.key 2048
ca.crt based on the ca.key.
"webserver.default.svc" is the domain name of the Webhook server in the cluster. The -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 = 2048prompt = nodefault_md = sha256distinguished_name = dn[ dn ]C = cnST = shaanxiL = xi'anO = defaultOU = webseverCN = webserver.default.svcsubjectAltName = @alt_names[ alt_names ]DNS.1 = webserver.default.svc[ v3_ext ]authorityKeyIdentifier=keyid,issuer:alwaysbasicConstraints=CA:FALSEkeyUsage=keyEncipherment,dataEnciphermentextendedKeyUsage=serverAuth,clientAuthsubjectAltName=@alt_names
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
ca.crt: the CA certificate.ca.key: the CA certificate key, used to issue a server certificate.server.crt: the issued server certificate.server.key: the issued server certificate key.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 keyopenssl 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 nameopenssl req -new -key ${USERNAME}.key -out ${USERNAME}.csr -subj "/CN=${USERNAME}/O=${USERNAME}"# Create a Kubernetes CSRcat <<EOF | kubectl apply -f -apiVersion: certificates.k8s.io/v1beta1kind: CertificateSigningRequestmetadata:name: ${USERNAME}spec:request: $(cat ${USERNAME}.csr | base64 | tr -d '\\n')usages:- digital signature- key encipherment- server authEOF# Approve the certificate as trustworthykubectl certificate approve ${USERNAME}# Obtain the self-signed certificate CRTkubectl get csr ${USERNAME} -o jsonpath={.status.certificate} > ${USERNAME}.crt
${USERNAME}.crt: the Webhook server certificate${USERNAME}.key: the Webhook server certificate keyValidatingWebhookConfiguration 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:
The Webhook triggering rule configured in this sample is as follows: when an API of 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:

Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback