Skip to main content

Using the host cluster's Kyverno hooks

If you want to enforce policies using Kyverno, and don't want to manage as many Kyverno installations as you have vClusters, you can make use of the External Admission Enforcement feature to enforce policies inside your vClusters with a single Kyverno installation.

Install Kyverno​

For the purpose of this guide, you should have Kyverno installed on your host cluster. You can either install it by running the following command or head here to install it differently.

kubectl create -f https://github.com/kyverno/kyverno/releases/download/v1.10.0/install.yaml

Create a Kyverno policy​

After installing Kyverno, create the following (or the one of your chosing) policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-labels
  annotations:
    policies.kyverno.io/title: Add Labels
    policies.kyverno.io/category: Sample
    policies.kyverno.io/minversion: 1.6.0
    policies.kyverno.io/severity: medium
    policies.kyverno.io/subject: Label
    policies.kyverno.io/description: >-
      Labels are used as an important source of metadata describing objects in various ways
      or triggering other functionality. Labels are also a very basic concept and should be
      used throughout Kubernetes. This policy performs a simple mutation which adds a label
      `foo=bar` to Pods, Services, ConfigMaps, and Secrets.
spec:
  rules:
  - name: add-labels
    match:
      any:
      - resources:
          kinds:
          - Pod
          - Service
          - ConfigMap
          - Secret
    mutate:
      patchStrategicMerge:
        metadata:
          labels:
            foo: bar

Import the hook into the vCluster​

Once the policy is created, this will update the kyverno-resource-mutating-webhook-cfg (or the corresponding validatingwebhookconfiguration) with the relevant resources and namespaces. You will need to copy this configuration into your values files or your template for it to be applied inside the vCluster in the .admission.mutatingWebhooks as a string.

Once the vCluster is updated with that configuration, objects will have to go through the Kyverno hooks and will be modified (or validated) accordingly.

Caveats​

Make sure that your Kyverno hooks don't rely on the host cluster's namespaces or logic tied to the specifics of it, since the objects that are going to reach it will have the object's raw metadata (and will for example reference namespaces that are only present inside the vCluster)