Create a ConstraintTemplate YAML with apiVersion: templates.gatekeeper.sh/v1, kind: ConstraintTemplate, and spec.crd.spec.names.kind matching the constraint CRD name you want (e.g., K8sRequiredLabels).
Under spec.targets, declare target: admission.k8s.gatekeeper.sh and a code block with engine: Rego and source.version: v1 to use Rego v1 syntax without needing an import rego.v1 statement.
Write your Rego policy inside source.rego; use violation contains {"msg": msg} if ... pattern and reference input.review.object for the admission request object.
Create a corresponding Constraint resource (the CRD generated by the template) with a match block scoping it to the desired resource kinds and namespaces.
Use the gator CLI (gator verify) with a test suite YAML to run unit tests against the ConstraintTemplate locally before applying to a cluster.
Apply both the ConstraintTemplate and the Constraint to the cluster and verify enforcement with kubectl describe constraint <name> to inspect violations.
Known gotchas
Rego v1 syntax support was added in Gatekeeper 3.19; on older versions the source.version: v1 field is ignored and v0 rules are required.
The Constraint schema section must be structural (no x-kubernetes-preserve-unknown-fields at the root) for v1 ConstraintTemplates; unstructured schemas cause the CRD to be rejected.
Gatekeeper runs in dry-run mode by default for new constraints until enforcementAction is set to deny; always check the mode before assuming policies are blocking requests.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp