All Policies

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.

Allowed image repositoriesallowedreposAllowed Image Repositories
Automount ServiceAccount Tokenautomount-serviceaccount-tokenRestrict Auto-Mount of Service Account Tokens
CVE-2021-25740block-endpoint-edit-default-roleRestrict Edit for Endpoints CVE-2021-25740
Disallow Service LoadBalancerblock-loadbalancer-servicesDisallow Service Type LoadBalancer
Disallow Service NodePortblock-nodeport-servicesDisallow NodePort
Block Ingress with wildcards in hostblock-wildcard-ingressRestrict Ingress Host with Wildcards
Container limitscontainerlimitsRequire Limits and Requests1
Container requestscontainerrequestsRequire Limits and Requests1
Container resource ratioscontainerresourceratiosEnforce Resources as Ratio
Container resourcescontainerresourcesRequire Limits and Requests1
Disallow anonymousdisallowanonymousRestrict Binding System Groups
Allowed image tagsdisallowedtagsDisallow Latest Tag
Service with ExternalIPexternalipRestrict External IPs
Require Ingress with HTTPShttpsonlyRequire Ingress HTTPS
Image digestsimagedigestsRequire Images Use Checksums
Restrict ServiceAccount updatesnoupdateserviceaccountRestrict Pod Controller ServiceAccount Updates
PodDisruptionBudget with non-zero maxUnavailablepoddisruptionbudgetPodDisruptionBudget maxUnavailable Non-Zero
Replicas don’t match PDB minAvailablepoddisruptionbudgetCheck PodDisruptionBudget minAvailable
Replica rangereplicalimitsRequire Multiple Replicas2
Require annotationsrequiredannotationsRequire Annotations3
Require labelsrequiredlabelsRequire Labels3
Metadata regexrequiredannotations and requiredlabelsMetadata Matches Regex3
Require Pod probesrequiredprobesRequire Pod Probes
Require StorageClassstorageclassRequire StorageClass
Require unique Ingress hostsuniqueingresshostUnique Ingress Host
Unique Service selectoruniqueserviceselectorRequire Unique Service Selector

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


  1. 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.
  2. The Kyverno policy can easily be modified to accommodate a range rather than a greater-than-zero check.
  3. 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.