From f09f866470331904fbaa20b131e479b955d35f6f Mon Sep 17 00:00:00 2001 From: Cao Shufeng Date: Thu, 8 Feb 2018 19:15:52 +0800 Subject: [PATCH] fix README for admission webhook test image This README is copied from somewhere else and it's out of date. --- test/images/webhook/README.md | 42 +++++------------------------------ 1 file changed, 5 insertions(+), 37 deletions(-) diff --git a/test/images/webhook/README.md b/test/images/webhook/README.md index d0b9263988..89b903566a 100644 --- a/test/images/webhook/README.md +++ b/test/images/webhook/README.md @@ -1,45 +1,13 @@ -# Kubernetes External Admission Webhook Example +# Kubernetes External Admission Webhook Test Image -The example shows how to build and deploy an external webhook that only admits -pods creation and update if the container images have the "grc.io" prefix. +The image tests MutatingAdmissionWebhook and ValidatingAdmissionWebhook. After deploying +it to kubernetes cluster, administrator needs to create a ValidatingWebhookConfiguration +in kubernetes cluster to register remote webhook admission controllers. -## Prerequisites - -Please use a Kubernetes release at least as new as v1.8.0 or v1.9.0-alpha.1, -because the generated server cert/key only works with Kubernetes release that -contains this [change](https://github.com/kubernetes/kubernetes/pull/50476). -Please checkout the `pre-v1.8` tag for an example that works with older -clusters. - -Please enable the admission webhook feature -([doc](https://kubernetes.io/docs/admin/extensible-admission-controllers/#enable-external-admission-webhooks)). +TODO: add the reference when the document for admission webhook v1beta1 API is done. ## Build the code ```bash make build ``` - -The Makefile assumes your cluster is created by the -[hack/local-up-cluster.sh](https://github.com/kubernetes/kubernetes/blob/master/hack/local-up-cluster.sh). -Please modify the Makefile accordingly if your cluster is created differently. - -## Explanation on the CAs/Certs/Keys - -The apiserver initiates a tls connection with the webhook, so the apiserver is -the tls client, and the webhook is the tls server. - -The webhook proves its identity by the `serverCert` in the certs.go. The server -cert is signed by the CA in certs.go. To let the apiserver trust the `caCert`, -the webhook registers itself with the apiserver via the -`admissionregistration/v1beta1/externalAdmissionHook` API, with -`clientConfig.caBundle=caCert`. - -For maximum protection, this example webhook requires and verifies the client -(i.e., the apiserver in this case) cert. The cert presented by the apiserver is -signed by a client CA, whose cert is stored in the configmap -`extension-apiserver-authentication` in the `kube-system` namespace. See the -`getAPIServerCert` function for more information. Usually you don't need to -worry about setting up this CA cert. It's taken care of when the cluster is -created. You can disable the client cert verification by setting the -`tls.Config.ClientAuth` to `tls.NoClientCert` in `config.go`.