How do you implement policy enforcement in a GitOps pipeline — OPA/Gatekeeper, Kyverno?

Policy enforcement in GitOps works on two levels: shift-left checks in the CI pipeline (before changes reach the cluster) and runtime admission controls in the cluster (enforced on every resource creation or update, including GitOps operator applies).

OPA/Gatekeeper: The gatekeeper-controller registers as a Kubernetes admission webhook. Policies are written in Rego and packaged as ConstraintTemplate CRDs, with Constraint CRs instantiating them with parameters. You store both in the GitOps config repo and sync them via Argo CD or Flux — policies are themselves managed as GitOps-first resources. In CI, use conftest to run the same Rego policies against manifests before they are committed, catching violations before merge.

Kyverno: Policy-as-code using Kubernetes-native YAML syntax — no Rego required. A ClusterPolicy CR can validate, mutate, or generate resources. Store ClusterPolicy CRs in Git; your GitOps operator applies them. Kyverno also supports a CLI (kyverno apply) for CI-phase pre-validation.

# Kyverno ClusterPolicy: every Pod must declare CPU and memory limits
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-container-limits
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Resource limits (cpu and memory) are required for all containers."
        pattern:
          spec:
            containers:
              - name: "*"
                resources:
                  limits:
                    memory: "?*"
                    cpu: "?*" 

The GitOps policy-as-code flow: write ClusterPolicy/ConstraintTemplate → commit to config repo → CI runs kyverno apply or conftest test to validate other manifests in the PR → GitOps operator syncs policies to cluster → admission webhook enforces on all future resource applies, including those from the operator itself. This means every deployment the operator makes is validated against the current policy set.