Centralized Admission Control

The Centralized Admission Control feature allows platform admins to enforce webhook configurations (both validating and mutating) referencing the host cluster or external policy services from within the vCluster.

These configurations will be read-only within the vCluster and can only be set from the vCluster CLI or Helm values upon creation. This provides assurance to platform admins that vCluster admins will not be able to bypass or alter the hooks they set for a vCluster.

Without this Centralized Admissions Control feature, the alternative would be to manually map the host policy service into the vCluster. In this case, the vCluster admin would have the ability to modify or delete the webhook configurations.

Configuration

You can enable or disable Centralized Admission Control by using the centralAdmission helm value. This can either be applied to new vClusters or existing ones by the platform admin.

To enable it, set the centralAdmission fields (mutatingWebhooks or validatingWebhooks) in the vCluster configuration with a list of the {validating/mutating} webhook configuration objects (in string format).

For example, to ensure that all new ConfigMaps are sent to a mutatingWebhook on the host cluster, you can define centralAdmission as follow within the vCluster configuration:

pro: true
centralAdmission:
  mutatingWebhooks:
    - apiVersion: admissionregistration.k8s.io/v1
      kind: MutatingWebhookConfiguration
      metadata:
        labels:
          webhook.kyverno.io/managed-by: kyverno
        name: kyverno-resource-mutating-webhook-cfg
      webhooks:
      - admissionReviewVersions:
        - v1
        clientConfig:
          service:
            name: kyverno-svc
            namespace: kyverno
            path: /mutate/fail
            port: 443
        failurePolicy: Fail
        matchPolicy: Equivalent
        name: mutate.kyverno.svc-fail
        namespaceSelector:
          matchExpressions:
          - key: kubernetes.io/metadata.name
            operator: NotIn
            values:
            - kyverno
        objectSelector: {}
        reinvocationPolicy: IfNeeded
        rules:
        - apiGroups:
          - ""
          apiVersions:
          - v1
          operations:
          - CREATE
          resources:
          - configmaps
          scope: '*'
        sideEffects: NoneOnDryRun
        timeoutSeconds: 10

In the above configuration, any time a ConfigMap is created, the vCluster API server will forward the admission request to a proxy, which in turn will call the actual admission hook running in the host cluster in the kyverno namespace.

Note that the service providing the webhooks should not rely on the real names of the objects if they are synced on the host cluster (for example pods). The requests that will reach the host admission service will hold the objects from the vCluster, so your policies need to be able to handle those objects.

The hook services need not require authentication as the proxy does not have access to the AdmissionConfiguration object or the files it references. Most policy engines (like jsPolicy, Kyverno, or Gatekeeper) do not set authentication by default so it should work with most installations.

If a user inside the vCluster (admin or not) tries to delete one of your admission hooks, they will be prompted with the following error message:

kubectl delete kyverno-resource-mutating-webhook-cfg
error: the resource kyverno-resource-mutating-webhook-cfg is protected

Configuration​

Configuration