Gatekeeper Migration Guide

Migration guidelines with policy mappings

Migration Strategy

A strategy for migration from Gatekeeper is to run both policy engines for some period of time, and incrementally migrate policies over to Kyverno. The Kyverno policies can be initially introduced in Audit mode to assess results. Once ready, the Kyverno policies can be set to Enforce mode and the corresponding Gatekeeper policies can be removed.

Mutation policies may require additional consideration and testing, as running both engines may result in overwrites. For these, and for custom or complex policies, it is recommended that the Kyverno policies first be tested using the Kyverno CLI test command and then deployed into a cluster.

Gatekeeper to Kyverno Policy Mapping

The following table maps the Gatekeeper library policies to the Kyverno library policies. While there may be some minor variations in these mappings, anything more than tacit alterations are covered in the Notes section below the table.

Name	Gatekeeper	Kyverno
Allowed image repositories	allowedrepos	Allowed Image Repositories
Automount ServiceAccount Token	automount-serviceaccount-token	Restrict Auto-Mount of Service Account Tokens
CVE-2021-25740	block-endpoint-edit-default-role	Restrict Edit for Endpoints CVE-2021-25740
Disallow Service LoadBalancer	block-loadbalancer-services	Disallow Service Type LoadBalancer
Disallow Service NodePort	block-nodeport-services	Disallow NodePort
Block Ingress with wildcards in host	block-wildcard-ingress	Restrict Ingress Host with Wildcards
Container limits	containerlimits	Require Limits and Requests¹
Container requests	containerrequests	Require Limits and Requests¹
Container resource ratios	containerresourceratios	Enforce Resources as Ratio
Container resources	containerresources	Require Limits and Requests¹
Disallow anonymous	disallowanonymous	Restrict Binding System Groups
Allowed image tags	disallowedtags	Disallow Latest Tag
Service with ExternalIP	externalip	Restrict External IPs
Require Ingress with HTTPS	httpsonly	Require Ingress HTTPS
Image digests	imagedigests	Require Images Use Checksums
Restrict ServiceAccount updates	noupdateserviceaccount	Restrict Pod Controller ServiceAccount Updates
PodDisruptionBudget with non-zero maxUnavailable	poddisruptionbudget	PodDisruptionBudget maxUnavailable Non-Zero
Replicas don’t match PDB minAvailable	poddisruptionbudget	Check PodDisruptionBudget minAvailable
Replica range	replicalimits	Require Multiple Replicas²
Require annotations	requiredannotations	Require Annotations³
Require labels	requiredlabels	Require Labels³
Metadata regex	requiredannotations and requiredlabels	Metadata Matches Regex³
Require Pod probes	requiredprobes	Require Pod Probes
Require StorageClass	storageclass	Require StorageClass
Require unique Ingress hosts	uniqueingresshost	Unique Ingress Host
Unique Service selector	uniqueserviceselector	Require Unique Service Selector

The Gatekeeper pod-security-policy grouping maps roughly to the Pod Security Standard policies which they supersede.

Notes

The equivalent Kyverno policy does not enforce CPU limits as this is not a typical best practice, however this can easily be added. It also does not require those limits be under a certain threshold which the Gatekeeper policy defines. A separate rule can be added to ensure the values are under a given amount.
The Kyverno policy can easily be modified to accommodate a range rather than a greater-than-zero check.
The two Gatekeeper policies conflate the presence of labels and annotations with their values conforming to a specified regex. The Kyverno library has these as separate policies since the presence is more common than the regex.