GitOps Security

The Git repository is the single source of truth for declarative infrastructure and application configuration. All changes must be made via pull request, never through direct cluster access. This eliminates configuration drift by continuously reconciling the live state with the desired state stored in Git. The commit history provides a tamper-evident audit log of who changed what, when, and why.

Every commit must be cryptographically signed using GPG keys or S/MIME certificates tied to verified developer identities. The GitOps operator rejects any unsigned commits, preventing unauthorized or spoofed changes from entering the reconciliation pipeline. This establishes a non-repudiable chain of custody from developer workstation to production cluster, satisfying compliance requirements for change management traceability.

The GitOps agent (e.g., Flux or ArgoCD) runs inside the target cluster and continuously pulls the desired state from the Git repository. This inversion of control is critical: the cluster initiates the connection inward, eliminating the need to expose cluster credentials to external CI/CD systems. No external system ever holds long-lived admin credentials, dramatically reducing the blast radius of a pipeline compromise.

The GitOps controller continuously monitors for configuration drift—any divergence between the declared state in Git and the actual running state. When drift is detected, the controller can either:

• Alert: Notify security teams of unauthorized changes
• Auto-remediate: Automatically restore the declared state This closes the loop on manual emergency fixes that bypass change control, ensuring every modification is eventually captured in the auditable Git history.

A Kubernetes-native plugin that intercepts API requests before objects are persisted. In a GitOps security model, tools like Open Policy Agent (OPA) or Kyverno act as admission controllers to enforce Policy as Code. They validate that every incoming manifest—whether applied manually or by a reconciliation agent—meets strict criteria such as requiring digest-pinned images, prohibiting privileged containers, and verifying In-Toto attestations.

A deploy-time enforcement mechanism that ensures only trusted, cryptographically verified container images run in production. Integrated with Sigstore or a private PKI, Binary Authorization evaluates attestations against a policy before the kubelet pulls the image. This breaks the kill chain of a supply chain attack where a malicious actor compromises a CI pipeline to push a tainted artifact, as the GitOps reconciler will be blocked from deploying the unauthorized binary.

A deployment paradigm where components are never patched in place but replaced entirely. In GitOps, this is enforced by digest pinning—referencing container images by their SHA256 hash rather than mutable tags like :latest. This guarantees that the declarative state in Git resolves to an exact, bit-for-bit identical artifact every time, eliminating TOCTOU (Time-of-check to time-of-use) vulnerabilities and preventing tag mutation attacks from injecting malicious code.

A metadata framework that cryptographically verifies the complete build chain of an artifact. In-Toto collects signed attestations for each step—source checkout, compilation, testing—creating a verifiable link between the Git commit hash and the final container. The GitOps agent can validate this provenance metadata before syncing, ensuring no step was compromised. This provides non-repudiable evidence that the deployed state matches the authorized source of truth.