![]() ![]() yes hooks directories in repos are links. yes Repo paths access is drwxrws-? default. yes Repo storage directories are symlinks? default. OK (5.0.0) Repo base directory exists? default. ![]() Now, we need to run our webhook locally, but tell it to use the certificates we've generated.Checking GitLab Shell. Configure the Operator/webhook code to use the certificates This way, I've added a make target that kuztomize build config/local | kubectl apply -f - 3. In my project, I created another config directory config/local, where I've created a custom kustomization.yaml file, to import webhook and crds, and apply patches to webhook manifests. We also need to provide the base64 encoded CA file to the clientConfig.caBundle property.īe careful that if you write this config to config/webhook, it will get overwritten everytime you run make. Īs you can see here, we're removing the rvice (as we're not using a k8s service since the webhook runs locally, not in the cluster) and instead providing a url that points to our local enpdoint. v1beta1 # - THIS IS THE IMPORTANT PART - # You need to remove rvice, and instead use clientConfig.caBundle (paste your base64 encoded CA), and clientConfig.url clientConfig: Name: mutating-webhook-configuration webhooks: You'll need to copy the rootCA.pem file and encoded it to base64, you can use the following commands:ĪpiVersion: /v1 kind: MutatingWebhookConfiguration metadata: Now, we want to create the WebhookConfiguration K8s resources, to tell the API Server how to communicate with the Webhook running locally. Configure the WebhookConfiguration resources in K8s Now, you should have a directory certs with rootCA.pem (the PEM-encoded CA that we'll need later on), rootCA-key.pem, tls.crt and tls.key (the key pair needed for the webhook locally). Mkcert -cert-file= $CAROOT/tls.crt -key-file= $CAROOT/tls.key 172.17.0.1 # then, generate SSL certificates # here, we're creating certificates valid for both "" for MacOS and "172.17.0.1" for Linux # and put them inside the certs/tls.crt and certs/tls.key files (by default the operator/webhook will look for certificates with this naming convention) # then, install a new CA # the following command will create 2 files rootCA.pem and rootCA-key.pem # export the CAROOT env variable, used by the mkcert tool to generate CA and certs export CAROOT= $(pwd )/certs # run these commands inside your operator project directory # first, create a directory in which we'll create the certificates Generate a CA + TLS certificate/key pairįor this, you can use whichever tool you prefer, but for simplicity reason and 0-configuration experience, I like to use mkcert. Add a few lines of code in the operator/webhook set up, to use the certificates we generatedġ.Configure the K8s WebhookConfiguration resources for your Operator to use your local webhook endpoint.Generate a CA with a local CLI tool, then generate the self-signed certificate/key pair.In order for the API server to authorize the use of self-signed certificates (signed by unknown authority), we'll need to provide the CA that signed the certificate/key pair to the API Server. Now, for point n 2, it is possible to use self-signed certificates, ideal for local development as it's quite easy to get and set up. So, we'll be able to configure the API Server to send requests to on MacOS and on Linux. On Linux, you can reach the host from inside your docker containers by using the IP Address 172.17.0.1 (this might change depending on your docker network configuration, but by default this is the one).On MacOS, you can reach the host from inside your docker containers by using the hostname. ![]() With KinD, as the K8s Control plane (and thus, the API Server) run inside a docker container (kind-control-plane), it is possible to reach your local development environment (where your operator + webhooks are running when you develop locally):
0 Comments
Leave a Reply. |