OPA Gatekeeper as an alternative

Use OPA Gatekeeper when your organization already standardizes on OPA and writes policy in Rego. It fits the same platform contract as Kyverno : both run as admission webhooks, and both must live within the webhook-guard rules. Read Control admission first for the shared contract; this page covers what is specific to Gatekeeper.

Which tool to use#

• Gatekeeper if you have an existing Rego policy library or an OPA practice to reuse. Its model is ConstraintTemplate (the reusable rule, in Rego) plus Constraint (the rule applied with parameters).
• Kyverno if you want YAML-native policies and easy mutate and generate, with no Rego. See Use Kyverno policies .
• A native ValidatingAdmissionPolicy for any rule that must always block, because a webhook engine cannot guarantee that here, as explained below.

Install and write a constraint#

Install Gatekeeper with its Helm chart, then define a ConstraintTemplate and a Constraint:

		apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names: {kind: K8sRequiredLabels}
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels
        violation[{"msg": msg}] {
          not input.review.object.metadata.labels["team"]
          msg := "every workload must carry a team label"
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - {apiGroups: ["apps"], kinds: ["Deployment"]}
	

The webhook-guard contract applies#

Gatekeeper is a tenant admission webhook, so the same rules bind it as any other:

• Its ValidatingWebhookConfiguration may not target the admission-registration, authentication, or authorization APIs, cluster-scoped RBAC, or use an apiGroups: ["*"] wildcard. The guard rejects such a configuration at apply time.
• Prefer failurePolicy: Ignore on Gatekeeper's webhook. The platform permits either value and does not check this field. If Gatekeeper is down and its webhook is Fail, it blocks every matching request, including the platform's reconciliation of the cluster. Ignore means an outage skips the check rather than freezing the API.
• The syself-* policy names are reserved for the platform; do not create policies with that name prefix.

Why some rules need a native VAP#

With failurePolicy: Ignore, Gatekeeper's validation is best-effort: during a Gatekeeper outage, a policy violation can slip through, because the API server was told to allow rather than wait. That is the right trade for cluster availability, and it is why a rule that must never be bypassed, "no privileged pods, ever", belongs in a native ValidatingAdmissionPolicy , which runs inside the API server and cannot be taken offline. Use Gatekeeper for the broad policy set and a native VAP for the few rules that must always hold. Keep Gatekeeper highly available to shrink the best-effort window.