Gatekeeper Migration Guide
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.
- 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.