Kong Ingress Controller ships with an Admission Controller for KongPlugin
and KongConsumer resources in the configuration.konghq.com
API group.
The Admission Controller needs a TLS certificate and key pair which you need to generate as part of the deployment.
Following guide walks through a setup of how to create the required key-pair and enable the admission controller.
Please note that this requires Kong Ingress Controller >= 0.6 to be already installed in the cluster.
If you are using the stock YAML manifests to install and setup Kong for Kubernetes, then you can setup the admission webhook using a single command:
curl -sL https://bit.ly/install-kong-admission-webhook | bash
This script takes all the following commands and packs them together.
You need kubectl
and openssl
installed on your workstation for this to
work.
Kuberentes API-server makes an HTTPS call to the Admission Controller to verify if the custom resource is valid or not. For this to work, Kubernetes API-server needs to trust the CA certificate that is used to sign Admission Controller's TLS certificate.
This can be accomplished either using a self-signed certificate or using Kubernetes CA. Follow one of the steps below and then go to Create the secret step below.
Please note the CN
field of the x509 certificate takes the form
<validation-service-name>.<ingress-controller-namespace>.svc
, which
in the default case is kong-validation-webhook.kong.svc
.
Use openssl to generate a self-signed certificate:
$ openssl req -x509 -newkey rsa:2048 -keyout tls.key -out tls.crt -days 365 \
-nodes -subj "/CN=kong-validation-webhook.kong.svc"
Generating a 2048 bit RSA private key
..........................................................+++
.............+++
writing new private key to 'key.pem'
Kubernetes comes with an in-built CA which can be used to provision a certificate for the Admission Controller. Please refer to the this guide on how to generate a certificate using the in-built CA.
Next, create a Kubernetes secret object based on the key and certificate that
was generatd in the previous steps.
Here, we assume that the PEM-encoded certificate is stored in a file named
tls.crt
and private key is stored in tls.key
.
$ kubectl create secret tls kong-validation-webhook -n kong \
--key tls.key --cert tls.crt
secret/kong-validation-webhook created
Once the secret is created, update the Ingress Controller deployment:
Execute the following command to patch the Kong Ingress Controller deployment to mount the certificate and key pair and also enable the admission controller:
$ kubectl patch deploy -n kong ingress-kong \
-p '{"spec":{"template":{"spec":{"containers":[{"name":"ingress-controller","env":[{"name":"CONTROLLER_ADMISSION_WEBHOOK_LISTEN","value":":8080"}],"volumeMounts":[{"name":"validation-webhook","mountPath":"/admission-webhook"}]}],"volumes":[{"secret":{"secretName":"kong-validation-webhook"},"name":"validation-webhook"}]}}}}'
deployment.extensions/ingress-kong patched
If you are using Kubernetes CA to generate the certificate, you don't need
to supply a CA certificate (in the caBunde
param)
as part of the Validation Webhook configuration
as the API-server already trusts the internal CA.
$ echo "apiVersion: admissionregistration.k8s.io/v1beta1
kind: ValidatingWebhookConfiguration
metadata:
name: kong-validations
webhooks:
- name: validations.kong.konghq.com
failurePolicy: Fail
sideEffects: None
admissionReviewVersions: ["v1beta1"]
rules:
- apiGroups:
- configuration.konghq.com
apiVersions:
- '*'
operations:
- CREATE
- UPDATE
resources:
- kongconsumers
- kongplugins
- apiGroups:
- ''
apiVersions:
- 'v1'
operations:
- CREATE
- UPDATE
resources:
- secrets
clientConfig:
service:
namespace: kong
name: kong-validation-webhook
caBundle: $(cat tls.crt | base64 -w 0) " | kubectl apply -f -
Create a KongConsumer with username as harry
:
$ echo "apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
name: harry
username: harry" | kubectl apply -f -
kongconsumer.configuration.konghq.com/harry created
Now, create another KongConsumer with the same username:
$ echo "apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
name: harry2
username: harry" | kubectl apply -f -
Error from server: error when creating "STDIN": admission webhook "validations.kong.konghq.com" denied the request: consumer already exists
The validation webhook rejected the KongConsumer resource as there already exists a consumer in Kong with the same username.
Try to create the folowing KongPlugin resource.
The foo
config property does not exist in the configuration definition and
hence the Admission Controller returns back an error.
If you remove the foo: bar
configuration line, the plugin will be
created succesfully.
$ echo "
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: request-id
config:
foo: bar
header_name: my-request-id
plugin: correlation-id
" | kubectl apply -f -
Error from server: error when creating "STDIN": admission webhook "validations.kong.konghq.com" denied the request: 400 Bad Request {"fields":{"config":{"foo":"unknown field"}},"name":"schema violation","code":2,"message":"schema violation (config.foo: unknown field)"}
With 0.7 and above versions of the controller, validations also take place for incorrect secret types and wrong parameters to the secrets:
$ kubectl create secret generic some-credential \
--from-literal=kongCredType=basic-auth \
--from-literal=username=foo
Error from server: admission webhook "validations.kong.konghq.com" denied the request: missing required field(s): password
$ kubectl create secret generic some-credential \
--from-literal=kongCredType=wrong-auth \
--from-literal=sdfkey=my-sooper-secret-key
Error from server: admission webhook "validations.kong.konghq.com" denied the request: invalid credential type: wrong-auth