GitOps in Classified Environments: Patterns That Work

Introduction

GitOps, the practice of using Git as the single source of truth for declarative infrastructure and application deployment, has become the standard for cloud-native operations. Its benefits are well understood: auditability, reproducibility, rollback capability, and drift detection.

But what happens when your deployment target is a classified environment with no internet connectivity? When your Git repositories cannot span security domains? When the standard GitOps tooling assumes network access that simply does not exist?

This article presents patterns that adapt GitOps principles for classified and air-gapped federal environments.

The Core Challenge

Standard GitOps assumes a connected model: a Git repository triggers a reconciliation loop in a cluster agent (ArgoCD, Flux) that pulls the desired state and applies it. This model breaks in classified environments due to:

• Air gaps: No network connectivity between development (low-side) and production (high-side) environments
• Cross-domain solutions: Data can only cross classification boundaries through approved transfer mechanisms
• Registry isolation: Container registries on the high side cannot pull from public or even private low-side registries
• Tooling restrictions: Not all GitOps tools are approved for use in classified environments

Pattern 1: Split-Repository GitOps

Maintain separate Git repositories on each side of the classification boundary. The low-side repository contains the full development history. The high-side repository contains only the artifacts and manifests approved for deployment.

How It Works

Developers work normally on the low-side repository: branches, pull requests, code reviews, CI/CD

When a release is ready, the CI pipeline produces versioned, signed artifacts (container images, Helm charts, Kubernetes manifests)

Artifacts are packaged for cross-domain transfer, including cryptographic signatures and SBOMs

After cross-domain review and transfer, artifacts are imported into the high-side registry and Git repository

ArgoCD (or Flux) on the high side detects the new commit and reconciles the cluster state

Benefits

• GitOps reconciliation loop operates normally on the high side
• Full audit trail on both sides of the boundary
• Developers are not slowed by classification constraints during development

Challenges

• Manual (or semi-automated) cross-domain transfer step
• Repository synchronization requires disciplined processes
• Version tracking across repositories requires careful naming conventions

Pattern 2: Artifact-First GitOps

Instead of transferring Git commits across the boundary, transfer only signed artifacts (container images and deployment manifests). The high-side GitOps agent watches an artifact repository rather than a Git repository.

How It Works

Low-side CI/CD builds, tests, scans, and signs container images

Deployment manifests are rendered with specific image digests (not tags)

Images and manifests are packaged into a transfer bundle

The bundle crosses the air gap via approved cross-domain solution

An import automation script pushes images to the high-side registry and manifests to a high-side Git repo

ArgoCD reconciles from the high-side Git repo

Key Design Decision: Digests Over Tags

Always reference container images by digest (sha256) rather than tag. Tags are mutable; a "v1.2.3" tag could point to different images on different sides of the boundary. Digests are immutable and verifiable, ensuring that the exact image that passed security scanning on the low side is the exact image deployed on the high side.

Pattern 3: Declarative Transfer Manifests

Create a transfer manifest that declaratively specifies everything needed for a deployment: container images, Kubernetes manifests, configuration, and verification checksums.

Transfer Manifest Structure

Create a YAML manifest that lists every artifact, its digest, signature, and associated Kubernetes manifests. This manifest becomes the contract between the low-side release process and the high-side import process. It is versioned, auditable, and verifiable.

Tooling Considerations

ArgoCD is the most widely deployed GitOps tool in federal environments. Its application-centric model and RBAC capabilities align well with classified environment requirements.

Flux offers a lighter-weight alternative with strong multi-tenancy support.

Zarf deserves special mention as a tool specifically designed for air-gapped Kubernetes deployments. It packages everything needed for deployment into a single transferable bundle.

Conclusion

GitOps in classified environments requires adaptation, not abandonment. The core principles of declarative configuration, version-controlled desired state, and automated reconciliation remain valid. By implementing split-repository patterns, artifact-first transfers, and disconnected reconciliation, federal teams can achieve the reliability and auditability benefits of GitOps even in the most constrained environments.