GitOps is the practice of using Git as the single source of truth for infrastructure and application state, with automated reconciliation between the desired state in Git and the actual state in the target environment. For federal systems, this pattern solves two persistent compliance challenges simultaneously: deployment auditability and change control traceability.
In traditional push-based deployment pipelines, the relationship between a code change and what actually ran in production can be difficult to reconstruct months later when an auditor asks for evidence. With GitOps, the answer is always in the Git history — every deployment is a merge commit, signed and timestamped, with an explicit review record attached.
Why GitOps Fits Federal Compliance Requirements
FISMA continuous monitoring requires that every change to a production system be logged and attributable to an authorized change. GitOps produces this record automatically — the Git commit history is the change log. Merging to the production branch requires pull request approval; the approver's identity, timestamp, and specific changeset are captured in the commit metadata.
RMF configuration management controls (CM-2, CM-3, CM-5, CM-6) require baseline configurations to be documented and changes to be controlled. In a GitOps model, the Git repository IS the baseline documentation. Any deviation between Git and the running system is detected and either auto-corrected (drift remediation) or alerted for human review.
STIG configuration enforcement requires that production systems run compliant configurations and that deviations are detected. ArgoCD's drift detection continuously compares the deployed state against the Git source of truth — any configuration drift (whether from an unauthorized change or an automated system update) is surfaced immediately.
Architecture: ArgoCD on GovCloud Kubernetes
ArgoCD is the most widely deployed GitOps tool for Kubernetes-based environments, including DoD Platform One deployments. The architecture has three components:
Git repository (desired state). The declarative configuration for all deployed resources — Kubernetes manifests, Helm values, Kustomize overlays — lives in a Git repository. For government systems, this repository is typically self-hosted (GitLab on GovCloud or a GovCloud-approved platform) rather than relying on commercial GitHub.
ArgoCD (reconciliation controller). ArgoCD runs inside the GovCloud Kubernetes cluster and continuously compares the live cluster state against the Git repository. When drift is detected, ArgoCD either auto-syncs (if configured) or flags the drift for operator review. ArgoCD itself is hardened to DISA STIG requirements and runs with minimal privileges.
Kubernetes cluster (actual state). EKS on GovCloud is the target cluster. All deployed resources are owned by ArgoCD applications — direct kubectl apply commands to production are blocked by RBAC policies that only allow ArgoCD's service account to modify production namespaces.
# ArgoCD Application manifest (simplified)
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: mission-system-prod
namespace: argocd
spec:
project: government-workloads
source:
repoURL: https://git.agency.gov/mission-system.git
targetRevision: main
path: k8s/overlays/prod
destination:
server: https://kubernetes.default.svc
namespace: mission-system-prod
syncPolicy:
automated:
prune: true
selfHeal: true # Auto-remediate drift
syncOptions:
- CreateNamespace=false
- PrunePropagationPolicy=foregroundSigned Commits and Supply Chain Security
GitOps produces an audit trail only if the Git history is trustworthy. For federal environments, this means requiring signed commits on all merges to production branches.
GPG/SSH commit signing. Every engineer merging to a protected branch must sign their commits. Branch protection rules on the production branch enforce: required pull request reviews (minimum 2 reviewers), required status checks (CI pipeline must pass), and required signed commits.
SLSA provenance. Rutagon's government GitOps pipelines generate SLSA Level 3 build provenance for every container image — a cryptographically signed attestation linking the final image to the specific source commit and build environment that produced it. ArgoCD verifies this provenance before deploying, ensuring that only images built from known, reviewed source code reach production.
# GitHub Actions: SLSA provenance generation (simplified)
- name: Build and sign container
uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v1
with:
image: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
digest: ${{ steps.build.outputs.digest }}Cosign image signing. In addition to SLSA provenance, each image is signed with Cosign. OPA/Gatekeeper admission policies in the production cluster verify Cosign signatures before allowing Pod creation — an unsigned image is rejected at the cluster admission layer.
For more on supply chain security patterns, see Software Supply Chain Security for Government Systems and OIDC: Eliminating Secrets from AWS Pipelines.
Approval Gates and Change Control
GitOps pull requests are the change control mechanism. For government systems with formal change control board (CCB) requirements, the pull request workflow maps directly:
Standard changes (pre-approved, low-risk configuration updates) can be merged with two approvals and automated CI gates.
Normal changes (application updates, dependency upgrades) require two technical reviewers plus a designated approver from the program's security team. The ArgoCD application is set to manual sync — a human must trigger deployment after the merge, creating a second explicit authorization record.
Emergency changes (critical security patches, production incidents) follow an expedited process: one reviewer, immediate merge and deploy, with an incident change record created in parallel and reviewed within 24 hours.
All three tracks produce a Git record showing exactly what changed, who approved it, and when — satisfying CM-3 change control documentation requirements without a separate ticketing system that must be manually kept in sync with actual deployments.
Rollback and Disaster Recovery
GitOps rollback is git revert — a new commit that returns the system to a previous known state, with full audit trail. This is substantially faster and more reliable than manual rollback procedures in traditional deployment models.
For time-sensitive production incidents, ArgoCD's rollback UI allows operators to target any previous sync from the ArgoCD history (not requiring a git operation) — giving operations teams a fast rollback path without waiting for a PR review cycle.
For the CI/CD approval gate patterns that feed the GitOps pipeline, see CI/CD Approval Gates for Regulated Pipelines. For STIG compliance in Kubernetes, see STIG Compliance Automation in Kubernetes.
Working With Rutagon
Rutagon implements GitOps pipelines for federal agencies and defense programs — ArgoCD on GovCloud EKS, signed artifacts, SLSA provenance, and deployment workflows mapped to FISMA change control requirements.
Frequently Asked Questions
What is GitOps and why does it matter for federal systems?
GitOps is the practice of using Git as the single source of truth for system configuration and application state, with automated reconciliation between the desired Git state and the live environment. For federal systems, GitOps produces an inherent change audit trail (Git history with signed commits and PR reviews) that satisfies FISMA CM controls, enables drift detection (ArgoCD detects and alerts on any configuration deviation from the Git baseline), and provides fast, auditable rollback without manual intervention.
What is ArgoCD and is it approved for DoD use?
ArgoCD is a declarative GitOps continuous delivery tool for Kubernetes. It is available as a hardened container image through the DoD Platform One Iron Bank and has been deployed in multiple DoD environments. ArgoCD supports STIG hardening, integrates with OIDC for identity-based access control, and generates audit events for all sync operations. It is a widely used component in DoD software factory implementations.
How does GitOps satisfy FISMA configuration management controls?
FISMA configuration management controls (CM-2 through CM-6) require documented baselines, controlled changes, and access restrictions for production modifications. GitOps satisfies these through the Git repository as the documented baseline (CM-2), pull request approvals as the change control process (CM-3), branch protection rules restricting who can merge to production (CM-5), and ArgoCD drift detection continuously comparing live state to the Git baseline (CM-6). The Git history provides the complete audit evidence required for ATO assessments.
What is SLSA provenance and why does it matter for government software?
SLSA (Supply chain Levels for Software Artifacts) is a framework for software supply chain security. SLSA provenance is a cryptographically signed attestation that links a deployed artifact (container image, binary) to the specific source code commit and build environment that produced it. For government systems, SLSA provenance provides verifiable evidence that production systems run software built from reviewed, authorized source code — addressing supply chain attack vectors that traditional security controls do not cover.
How does GitOps handle emergency production changes?
Emergency changes in a GitOps model follow an expedited review track — one reviewer and immediate merge/deploy, with a post-change review record created within a defined window (typically 24 hours). ArgoCD can be configured to allow emergency manual sync for time-critical incidents. The Git record of the change (what changed, who approved, when deployed) is created automatically regardless of the review track, satisfying audit requirements even for out-of-band emergency changes.