Migration from Gatekeeper to Kyverno

Refer to the following document for the policies implemented in Big Bang under Gatekeeper and the corresponding policy in Kyverno:

Kyverno Policies vs. Gatekeeper Policies in Big Bang

Kyverno can coexist with Gatekeeper as both these mechanisms extend admission control independent of each other. However, it must be noted that for each validation hook that is introduced into the admission control, it takes extra time to process the request by kube api server. As such, any performance degradation must be considered when running both Gatekeeper and Kyverno in a Kubernetes cluster.

If Gatekeeper is already running in the cluster and the intent is to replace it with Kyverno, it is recommended that Kyverno is enabled and Kyverno policies are installed before proceeding with Gatekeeper uninstall. This two pass approach has been tested to work reliably. Enabling Kyverno and disabling Gatekeeper during the same Helm upgrade often fails with retries exhausted error, especially in resource constrained environments, like k3d.

Enable Kyverno

Apply helm upgrade using the following BigBang Helm Chart values:

kyverno:
  enabled: true

kyvernopolicies:
  enabled: true

Verify that Kyverno pods are running

kubectl -n kyverno get pods

Verify that Kyverno policies are ready

kubectl -n kyverno get cpol

Ensure that all the policies listed by the command are ready i.e. all the policies have value true for the READY column.

Disable Gatekeeper

Apply helm upgrade using the following BigBang Helm Chart values:

gatekeeper:
  enabled: false

clusterAuditor:
  enabled: false

Note that when gatekeeper is disabled using the helm upgrade process, the Gatekeeper webhook (gatekeeper-validating-webhook-configuration), Gatekeeper CRDs, Gatekeeper Constraint CRDs along with any constraint resources are also removed automatically.