What is GitOps? Extending DevOps to Kubernetes and Beyond

GitOps is an operational framework that applies DevOps practices—version control, collaboration, continuous integration/continuous delivery (CI/CD)—to infrastructure automation. Instead of treating infrastructure as a sequence of imperative commands or one-off scripts, GitOps models the complete desired state of an environment as declarative configuration stored in a Git repository. That repository becomes the single source of truth, and the live environment is continuously aligned to it.

The framework is built on four core principles established by the CNCF GitOps Working Group:

• Declarative description: The entire system—applications, networking, security policies—is expressed as code files, such as Kubernetes manifests or Terraform HCL.
• Versioned and immutable: Configuration is committed to Git with immutable tags and commit hashes, enabling precise rollback and a complete audit history.
• Pulled automatically: A software agent (for example, Argo CD or Flux) retrieves the desired state from Git and applies it to the environment.
• Continuously reconciled: The agent repeatedly compares live state to desired state and corrects any drift.

This differs from conventional CI/CD, in which a pipeline executes imperative steps against a live environment. In GitOps, CI typically builds a container image and updates the configuration repository; a separate controller then pulls that desired state into the cluster. The pull-based model means cluster credentials need not be exposed inside CI runners, reducing the blast radius of a compromised build system.

Consider a practical example: an autoscaling policy stored in config/autoscaler.yaml is changed through a pull request. After review and merge, the controller detects the new revision and applies it automatically. If the live cluster drifts because of manual changes or node failures, the controller reverts to the Git-declared state. The pull-request history provides a deterministic record of who changed what and when, producing change-management evidence that can support audits under frameworks such as SOC 2 and ISO 27001, both of which require documented change control and access review processes.

A GitOps implementation treats a Git repository as the authoritative declaration of an environment's desired state. This includes both application workloads and the infrastructure that hosts them. The system's actual state is then continuously compared against this declaration. Any difference is not an exception to investigate manually; it is a condition the system must correct automatically. To make this comparison possible, the desired state must be expressed declaratively. A user writes a manifest that describes the expected outcome—for example, a Kubernetes Deployment YAML that specifies the image tag, replica count, and resource limits—rather than writing an ordered list of imperative commands.

Declarative configuration is a prerequisite, not an implementation detail. Without it, the Git repository contains instructions for how to reach a state, but the state itself cannot be computed or verified directly. The reconciliation model used by Kubernetes-native tooling relies on controllers that continuously watch both the live cluster state and the Git repository. When they diverge, the controller applies the difference defined in Git. This yields several operational properties:

• Reproducibility: because the desired state is versioned, an environment can be rebuilt or inspected at any commit.
• Auditability: every change is a commit with an author and a timestamp, supporting change-management and access-control requirements associated with frameworks such as SOC 2 trust services criteria or ISO 27001 information security controls.
• Atomic reviews: a merge request can update an entire environment as a single reviewed operation.
• Automatic rollback: reverting the desired state is a Git revert, and the reconciliation loop executes the rollback automatically.

As a practical example, consider a manifest stored at infra/apps/checkout/deployment.yaml. A developer updates the image tag in that manifest and opens a pull request. After approval and merge, a GitOps agent running inside the cluster—such as Flux or Argo CD—detects the commit, fetches the new manifest, and applies it. The same agent also corrects drift: if an operator manually scales the Deployment to five replicas while Git declares three, the controller resets it to three.

The engineering recommendation is to convert all systems to declarative state before introducing GitOps tooling. The tooling automates the comparison and application loop; it cannot retroactively make an imperatively managed system observable or recoverable through Git history. Defining the full desired state in Git is therefore the foundational step on which every other GitOps practice depends.

Kubernetes is declarative by design. The control plane continuously reconciles the desired state expressed in resource manifests (Deployments, Services, ConfigMaps) against the observed state in the cluster. This reconciliation loop is the foundation on which GitOps builds a deployment workflow.

GitOps applies the same declarative principle to the entire delivery pipeline. In a GitOps model, a Git repository holds the complete desired state of the cluster as versioned YAML manifests. The cluster runs an operator (e.g., Argo CD or Flux) that watches the repository, detects drift between desired and observed state, and applies the necessary changes. The operator pulls changes from Git rather than receiving push-based deployment requests from CI/CD tools.

• Git is the single source of truth for cluster configuration.
• Every change is a pull request, providing auditability and peer review.
• The operator performs automatic drift correction, reverting manual changes to the declared state.
• Rollbacks are performed by reverting Git commits, not by executing imperative commands.

Practical example: an application manifest in Git specifies replicas: 3 for a Deployment. If an operator scales it manually to 5, the GitOps controller detects the mismatch and scales it back to 3. To change the replica count, an engineer updates the manifest in Git, merges the change, and the controller applies it. This pattern makes the cluster self-healing with respect to configuration.

For enterprise adoption, GitOps supports compliance objectives by making the change history immutable. Access control is enforced through branch protection rules rather than cluster credentials. If an organization seeks alignment with frameworks such as SOC 2 or ISO 27001, the Git repository serves as the auditable record of change; however, these standards do not mandate GitOps, and organizations must map their specific control requirements. A secure implementation also addresses the OWASP-recommended practices of secret management — Git repositories must not contain plaintext secrets; use Sealed Secrets or external secret controllers to inject credentials at runtime.

GitOps functions as an operational framework that leverages version control systems as the single source of truth for infrastructure and application configurations. By utilizing a declarative model, the state of the system is stored in a repository, where automated agents continuously reconcile the live environment with the versioned definition. This methodology shifts infrastructure management from imperative manual intervention toward a declarative, reproducible process.

Adopting this workflow provides several distinct technical advantages for enterprise environments:

• Enhanced Auditability: Every configuration change is captured as a commit in Git. This provides a granular historical record of who initiated a change, when it occurred, and the exact delta applied. This inherent logging assists in meeting compliance frameworks such as SOC 2, which requires robust access control and monitoring of system changes.
• Standardized Infrastructure Changes: Engineers utilize familiar Git workflows—such as pull requests, code reviews, and merge approvals—to manage infrastructure. This allows teams to apply CI/CD principles to infrastructure-as-code (IaC), ensuring that testing, linting, and security scans are executed before changes reach production.
• Operational Transparency: Because the repository serves as the definitive reference for the cluster state, engineers gain immediate visibility into the configuration. This eliminates "configuration drift," where manual, undocumented changes diverge from the intended design.

For example, implementing GitOps with Kubernetes typically involves a controller (such as Argo CD or Flux) running within the cluster. When an engineer commits a YAML manifest to a Git repository, the controller detects the discrepancy between the repository state and the cluster state. It then pulls the manifest and updates the cluster resources automatically to match the desired configuration. This approach reduces the reliance on manual CLI access to production environments, significantly narrowing the attack surface and minimizing human error during complex rollouts. By treating infrastructure as software, teams ensure that all modifications are version-controlled, reversible, and subject to automated verification.

The core GitOps pattern—a git repository as the declarative source of truth, a controller that reconciles live state toward that repository, and a pull-based delivery mechanism—is not inherently specific to Kubernetes. Kubernetes simply provides a convenient runtime for implementing controllers. The same pattern can be applied to cloud infrastructure, networking, and SaaS configuration by replacing custom resource watches with provider adapters.

In practice, a GitOps control plane for infrastructure runs inside Kubernetes but delegates to external APIs. Crossplane, for example, extends the Kubernetes API with managed resources and composites. A team can declare an RDS instance or an IAM policy in Git; the Crossplane provider controller continuously reconciles the AWS API against that declaration. Similarly, a Terraform controller (such as the open-source tf-controller) can execute Terraform plans in a sandboxed pod, store state in a remote backend, and require a pull request to apply plan changes. Both approaches retain the core benefit: no operator applies infrastructure changes directly; every mutation passes through review and version control.

Practical uses include:

• Declaring cloud networking (VPCs, subnets, NAT gateways) as YAML composites in a Git repository.
• Managing database instances, user roles, and backups through Git pull requests with automated drift detection.
• Enforcing policy with Open Policy Agent (OPA) or Gatekeeper before reconciliation to reject invalid or non-compliant resource definitions.

Extending GitOps introduces additional concerns. Secrets must not be stored in plaintext; use SOPS, sealed secrets, or an external secrets operator that fetches from a vault. Terraform state needs a shared remote backend and locking. Multi-environment promotion should be staged via branches or commits, not direct updates, so that production changes are traceable. Drift handling must be explicit: a controller that overwrites out-of-band changes can conflict with manual emergency fixes.

The model also strengthens auditability. A git-based change log with signed commits and required approvals supports controls in SOC 2 (security, availability, and change management attestation), ISO 27001 (information security management and controlled changes), and NIST SP 800-53 (configuration management controls). OWASP guidance applies to the pipeline itself—protecting credentials, validating input to prevent injection, and securely handling artifacts.