Gatekeeper vs Kubernetes

3.22.0-rc.0 in February introduced two CLI subcommands that change how policies are handled rather than what they express: gator policy, a brew-inspired tool for discovering, installing, upgrading and uninstalling policies from the gatekeeper-library, and gator bench, which benchmarks Rego and CEL engines with latency percentiles, throughput, memory profiling and baseline comparison for CI regression detection. The same release enabled sync-vap-enforcement-scope by default and gave both CEL and Rego access to namespace context during admission and audit. Since then, 3.23.0-rc.1 added status resource routing for remote cluster mode, and 3.24.0-beta.0 made generated ValidatingAdmissionPolicy output deterministic to stop a reconcile loop.

The centre of gravity is moving from the admission controller to the tooling around it. Policies are becoming artefacts you install from a library at a version, benchmark against a baseline in CI, and test before they reach a cluster — which is the lifecycle application code already has and policy generally has not. Underneath, the ValidatingAdmissionPolicy path keeps maturing as Gatekeeper hands more enforcement to the Kubernetes-native mechanism it now generates.

Remote cluster mode gained status routing but the entries describe only that piece, so how far multi-cluster enforcement extends is unclear from these notes. The releases in this window are all beta and release candidates, so a 3.24.0 stable is the near-term milestone.