Use OPA Gatekeeper when your organization already standardizes on OPA and writes policy in Rego. It fits the same platform contract as [Kyverno](/docs/hetzner/apalla/security/use-kyverno-policies): both run as admission webhooks, and both must live within the [webhook-guard](/docs/hetzner/apalla/security/control-admission) rules. Read [Control admission](/docs/hetzner/apalla/security/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](/docs/hetzner/apalla/security/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`:

```yaml
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](/docs/hetzner/apalla/security/control-admission), 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.