Argo CD for the public sector

How Argo CD fits public sector change control

An agency or defense program that must show controlled, reviewable change to systems inside its own enclave needs a delivery path where every change is traceable to an approved commit. Argo CD fits that pattern because it reconciles cluster state from Git, so the repository becomes the record of intended configuration and the cluster is compared against it. Projects restrict which repositories, destination clusters and namespaces an application may use, and RBAC scoped to those projects controls who can sync, override or delete. Those are the mechanics an assessor will ask to see when mapping the setup to configuration management requirements in NIST SP 800-53 or the CMMC Level 2 practices built on NIST SP 800-171. Argo CD does not produce that mapping for you. Your team does, and DeployOpen can prepare the configuration, runbooks and evidence that the mapping points to, but it does not issue audit reports or certifications.

The build has to be planned around the enclave itself. Confirm early whether the clusters and Git host will sit on isolated networks, because the installation, the Helm and Kustomize sources and every container image must be carried across the boundary in a controlled way. Plan that transfer alongside the software integrity checks that NERC CIP-013-2 describes for other sectors, so each artifact has a recorded origin. Licensing is simpler than in many open-source stacks: Argo CD is released under the Apache License 2.0 and the project offers no paid edition, so the licensing question for your procurement file is answered by the license itself, but support, hardening and upgrade work still need to be contracted separately. Confirm the release you intend to run against the project's current patch cadence, since only the three most recent minor versions receive patch releases.

Program boundaries are the decision that most shapes the design. Give each program its own Argo CD project, its own destination clusters or namespaces, and its own RBAC mapping from the identity provider, and decide whether one Argo CD instance may serve several programs or whether each needs a separate installation. Disable the built-in admin user with admin.enabled set to false once SSO is working, and document who holds break-glass access. Before go-live, test that a user in one program cannot sync, view logs or modify applications in another, because the upgrade notes for 3.0 changed update and delete permissions to apply to the application itself and require an explicit logs permission. Those tests, and their results, are the evidence an assessor will look for first.

Which public sector requirements shape the Argo CD build

This table maps the federal and defense requirements most likely to reach a GitOps delivery system, and what each one means for where Argo CD runs, what repositories may hold, and who can change what. Read each row as a question to settle before the design is fixed. The main takeaway is that the control plane, Git repositories and cluster placement are scoped by the data they touch, so confirm that scope first.

Requirement	What it asks for	What it means for the Argo CD build
NIST SP 800-53 Rev. 5 baselines	SP 800-53B selects 149 controls and enhancements for low, 287 for moderate and 370 for high. Release 5.2.0 of 27 August 2025 is current.	Confirm the impact level of each system Argo CD deploys to. The baseline sets the access control, audit, configuration management and contingency evidence the GitOps repositories and cluster destinations must support.
FISMA and Inspector General oversight	Agencies must secure their information systems, and Inspectors General assess those systems independently and report to OMB.	Expect assessors to test Argo CD as part of the agency system boundary. Keep sync history, role assignments and repository change records available for independent review.
FedRAMP scope under OMB M-24-15	FedRAMP covers cloud products that handle federal information on behalf of an agency. Systems used only for one agency's operations, not offered as a shared service, are out of scope.	A self-hosted Argo CD in the agency's own cloud account is usually scoped to the agency, not to FedRAMP. Confirm with the authorizing official whether any managed hosting or shared SaaS component is involved.
CJIS Security Policy v6.1	Criminal justice information in transit and at rest outside physically secure locations needs FIPS 140-3 modules or AES with at least 256-bit keys. Vulnerability scanning runs at least monthly.	If Git repositories, Kubernetes secrets or rendered manifests can contain CJI, encrypt them accordingly and scan the Argo CD images and cluster workloads monthly. Confirm the policy version with your CJIS Systems Officer.
32 CFR 2002.14 for CUI	Federal agencies use NIST SP 800-171 to set protection requirements for controlled unclassified information on non-federal systems, unless the CUI category prescribes other safeguards.	Treat any Git repository or Argo CD application carrying CUI as in scope. Decide whether manifests, Helm values and secret references are CUI before choosing repository hosting.
32 CFR 170.17(c)(5) cloud limits for CMMC	A defense contractor may store or process CUI in a cloud service only if it is FedRAMP Authorized at Moderate or higher, or meets equivalent requirements. Non-cloud providers are assessed inside the contractor's scope.	Hosting the Git server, container registry or cluster in a commercial cloud can bring that service into the CUI boundary. Run Argo CD in infrastructure you control and confirm the status of any hosted Git or registry service.
CMMC Level 2 and 110 requirements	32 CFR 170.14 ties Level 2 to NIST SP 800-171 Rev. 2, counted as 110 requirements across 14 domains. Assessments use the objectives of NIST SP 800-171A, and evidence must be final, not draft.	Map Argo CD configuration, RBAC, audit logs and change records to the relevant domains. Retain sync history and approval records in final form for the assessor.
July 2026 Phase II suspension	On 13 July 2026 the Department of War suspended CMMC Phase II and started a 60-day review. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place.	Design for the controls now, since obligations under DFARS 252.204-7012 continue. Confirm with the contracting office which CMMC phase and assessment type applies to your contract, because the eCFR text and the DoW CIO page differ.

Air-gapped, on-premises or authorized cloud: choosing where Argo CD runs

A fully disconnected enclave has no route to public registries, public Git hosts or vendor update servers, so every artifact Argo CD needs must be brought across the boundary on purpose. The Kubernetes side follows a known pattern: kubeadm can pre-fetch control plane images with kubeadm config images pull and point kubeadm init at an internal registry through --image-repository. Argo CD itself, its Helm charts and the workload images are mirrored the same way, and the transfer process becomes part of the evidence trail.

Image and chart mirroring: Build an internal registry inventory that lists every Argo CD image, Redis image, Helm chart and workload image, with digests recorded at import.
Offline checks: Scan mirrored images and packages with a scanner that uses an offline vulnerability database, and record each import decision.
Git inside the boundary: Host repositories on a Git server inside the enclave and register them as Kubernetes Secrets, since repository definitions no longer live in the argocd-cm ConfigMap in 3.0.
Cluster sizing: High availability manifests need at least three nodes because of pod anti-affinity rules, so plan the enclave capacity before the build.
IP stack: IPv6-only clusters are not supported, so confirm the addressing plan with the platform team first.

Confirm with the enclave owner how transfer media is approved and who signs off each import before you plan the mirror schedule.

In an agency data center, the cluster usually sits on networks the agency already governs, with some outbound access allowed through proxies or controlled egress. This model keeps the familiar Git and registry tooling but still requires explicit decisions about which sources the repo-server may reach. Because the repo-server runs Helm and Kustomize against repository content, the list of approved repositories and chart sources is a control in its own right, not a convenience setting.

Network path: Document which Git, registry and identity endpoints the Argo CD components reach, and keep TLS on all paths, including between Argo CD components.
Identity: Connect SSO through the agency's approved identity provider, either directly over OIDC or through bundled Dex, and disable the built-in admin user with admin.enabled set to false after configuration.
Repository allowlist: Restrict which repositories and chart sources the repo-server can read, and treat out-of-tree file access as a risk to close.
Operational resilience: Use high availability with controller sharding where cluster counts justify it, and keep Redis as a disposable cache.
Release currency: Track the Argo CD release cadence, since only the three most recent minor versions receive patches, and schedule upgrades inside change windows.

Ask the agency's network team to confirm which egress paths are formally approved before the design is frozen, because each one becomes an assessed boundary.

Argo CD settings that carry public sector controls

Most of the public sector evidence for an Argo CD install comes from a handful of settings: how people sign in, which accounts exist, where manifests come from and what each program may deploy. The cards below cover those settings and the checks to run on each before an assessor asks for proof.

Single sign-on through Dex or OIDC

Connect Argo CD to the agency identity provider, either through the bundled Dex with a SAML or LDAP connector or directly through an OIDC provider. Confirm that each user signs in with their own federated identity, that MFA is enforced at the identity provider, and that offboarding in the agency directory removes Argo CD access. Local accounts should be the exception, not the default path.

Disable the built-in admin account

The built-in admin user is meant for initial setup only. After SSO and local users are working, set admin.enabled to false and record the change as a configuration baseline item. Confirm that break-glass access is handled through a documented, separately approved procedure rather than a standing shared password.

Repositories defined as Secrets

Since Argo CD 3.0, repository configuration no longer lives in the argocd-cm ConfigMap, so repositories are declared as Kubernetes Secrets. Treat those Secrets as controlled configuration: restrict who can read or change them, limit each repository to approved sources, and keep their definitions in the same change record as the rest of the baseline. Confirm the upgrade path for any environment still using the older layout.

Projects bounded by agency or program

Use Argo CD projects to separate agencies or programs by allowed source repositories, destination clusters and namespaces, and permitted Kubernetes resource kinds. A project with wildcard sources or destinations undoes the separation. Review each project definition as part of access approval, and test that an application in one project cannot deploy into another program's namespace.

RBAC keyed to the federated identity

With Dex-based RBAC, policy matches the federated_claims.user_id claim, so role bindings should reference the identity the agency provider asserts. Since 2.14 to 3.0, update and delete permissions apply only to the application itself, and reading logs requires an explicit logs, get permission. Grant log access deliberately, because logs can reveal operational detail that a deployer role does not need.

Repo-server exposure to untrusted content

The repo-server runs Helm and Kustomize against repository content, so a chart or overlay from an unreviewed source can execute work inside the control plane. Limit configuration sources to approved repositories, restrict out-of-tree file access, and review third-party charts before they are added to a project. Confirm this control with the team that owns the repo-server settings.

TLS and signed commits as checks

Argo CD uses TLS for traffic between its components and authenticates API calls with JSON Web Tokens, so confirm that certificates, token lifetimes and the endpoints exposed to users are documented. Separately, decide whether commit signature verification is required for each project and which signing keys are trusted. Verify both behaviors against your own tooling and your assessor's test steps before relying on them as evidence.

How strict RBAC separates agencies and programs

One Argo CD instance can serve several agencies or programs only if projects, cluster registrations and RBAC keep each program's applications, repositories and namespaces apart. Treat the AppProject as the boundary: it limits which source repositories an application may use, which destination clusters and namespaces it may deploy into, and which cluster-scoped resources it may create. Each program should get its own project with its own repositories and destinations, and no project should be granted a wildcard destination. Confirm that the separation model matches the program's authorization boundary before any shared instance is approved, because an assessor will test the boundary as written, not as intended.

The RBAC model also changed in the 3.0 line, and the change matters for multi-program use. Update and delete permissions now apply only to the application itself, not to the resources it manages, so a role that could delete an application in one program does not automatically reach the workloads beneath it. Access to pod logs now requires an explicit logs, get permission, which means a team that needs to troubleshoot its own workloads must be granted that right on purpose. Review the upgrade notes for Argo CD 2.14 to 3.0 against your existing policy.csv before relying on inherited roles, and test each program's roles with a non-administrative account rather than assuming the old behavior carried over.

The main design decision is whether programs share one control plane or each run a namespace-scoped install. A shared instance is simpler to operate, patch and back up, and it gives one audit trail, but a fault or privileged role in the shared instance affects every program. A namespace-scoped install isolates the control plane per program at the cost of more instances to patch, monitor and upgrade on the same schedule. Ask the program owner which risk the authorization boundary tolerates, and record the choice with the admin account disabled, SSO groups mapped to roles, and the reasoning for the decision in the design record.

Rolling out Argo CD inside a federal or defense boundary

This sequence takes Argo CD from a scoped authorization boundary to a handed-over, recoverable installation in clusters you control, with each step producing a record an assessor can test. Durations and staffing come from the written scope agreed before work starts.

Define the boundary and authorization scope
DeployOpen works with your security office to list the systems, clusters, Git hosts, registries and identity sources that Argo CD will touch, and to mark which of them hold controlled information. The output is a written boundary diagram and a data-flow list that names every component inside the assessed environment. The step is done when your authorizing official or system owner has accepted the boundary in writing, because every later control decision depends on it.
Mirror images, charts and repositories offline
In an air-gapped or on-premises environment, the team builds an internal path for container images, Helm charts, Kustomize bases and Git repositories, and imports them through a controlled transfer process. Each imported artifact is checked for integrity and provenance against a recorded source, which supports the software verification expectations in NERC CIP-013-2 where that standard applies. Done means a manifest of mirrored artifacts with hashes exists, and the cluster can pull everything it needs without reaching the internet. Confirm the exact transfer procedure with your cross-domain or accreditation team before work starts.
Design identity and RBAC for each program
DeployOpen maps your agencies or programs to Argo CD projects, decides whether SSO runs through the bundled Dex or directly through your existing OIDC provider, and translates identity groups into Argo CD roles. The team disables the built-in admin account once SSO works, following the user management guidance. The deliverable is an RBAC matrix that shows which group can sync, override or delete applications in each project, and a test record showing a user from one program cannot see another program's applications. Confirm your identity provider's group claim format before this step closes.
Install Argo CD with high availability
The team deploys Argo CD inside the boundary using the high availability manifests on a cluster with at least three nodes, since the pod anti-affinity rules require them. They confirm the cluster is IPv4-capable, because IPv6-only clusters are not supported, and enable TLS on traffic between components and at the ingress. The output is a running installation with health checks passing, recorded version numbers and the exact manifest or Helm values used. Confirm which patch release is current and supported at install time, because the project patches only the three most recent minor versions.
Configure projects, repositories and sync controls
Each program gets its own Argo CD project with allowed source repositories, destination clusters and namespaces, and resource allowlists. Repository credentials are stored as Kubernetes Secrets, as Argo CD 3.0 requires, and the team restricts the repo-server from reading content outside the approved repositories, since Helm and Kustomize run on repository content. Done means a test application from an unapproved repository or destination is rejected, and each project's sync policy and any sync windows are documented.
Capture change and configuration evidence
The team sets up the change flow so that every deployment traces to a reviewed Git commit, with signed commits and protected branches where your policy requires them. Audit logs from Argo CD, Git and the cluster are routed to your central log store with retention that matches your records schedule. The output is an evidence map that links each control in your assessment scope to a configuration file, a log source or a test result. Confirm with your assessor which evidence form they accept, since a requirement is only considered met when its evidence is final.
Test backup and recovery
Argo CD keeps most state in Kubernetes objects, and Redis is a disposable cache, so the recovery plan centers on backing up the cluster objects, the Git source of truth and the mirrored artifact store. DeployOpen runs a documented restore into a separate cluster, then confirms that applications resync to their recorded state. The deliverable is a restore runbook with the measured results from the test. Recovery targets should come from your own continuity requirements, not from this page.
Hand over runbooks and operating controls
The engagement closes with a handover of the boundary diagram, RBAC matrix, install record, runbooks for upgrades and patching, and the evidence map. Your operators run a supervised change through the full flow, from commit to sync to evidence capture, while DeployOpen observes. Done means your team can reproduce the change path and the recovery test without DeployOpen present. Ongoing support, upgrades and continuous testing are available as retainers, and the terms are set out in the written scope.

What evidence auditors will ask Argo CD to produce

Assessors reviewing a public sector or defense system rarely accept a tool's configuration on its own word. They test whether each change is traceable, whether access is limited by design, and whether what enters the boundary can be verified. The five items below are the records we would prepare with you, and each one needs an owner who can explain it. DeployOpen prepares systems and evidence, but independent assessors and C3PAOs make the determinations.

Git history of approved changes

With Argo CD, the desired state of each cluster lives in Git, so the commit log and merge records become the primary change trail. Auditors will ask who proposed each change, who approved it, and whether the deployed revision matches an approved commit. Check that protected branches require review, that approvals are recorded in the Git host, and that the Argo CD sync history can be matched to specific commit identifiers. Confirm the retention period for Git and Argo CD history with your records office before the assessment starts.

Project and RBAC configuration

Argo CD projects define which repositories, destination clusters and namespaces each program may use, and RBAC defines who may act on them. Assessors will expect a written access model that matches the agency or program boundaries, plus exported configuration showing it is in force. Since Argo CD 3.0, RBAC for SSO users keys on the federated_claims.user_id claim, so the mapping must be tested again after any upgrade. Keep a dated export of the configuration as evidence.

Disabled built-in admin account

The built-in admin user is meant for initial setup only. The Argo CD user management documentation recommends setting admin.enabled to false once local users or SSO are configured. Auditors will ask for the configuration showing the account is disabled, and for a record of who holds break-glass access and how it is logged. Keep the procedure for temporarily re-enabling it under change control, so any use leaves a trail.

Audit and log access controls

Logs and event streams show who acted and what was deployed, so their own access must be restricted. In Argo CD 2.14 to 3.0, reading application logs requires an explicit logs, get permission, separate from update and delete rights. Assessors will look for that separation in the RBAC export, for log retention settings, and for a list of who can read or export logs. Confirm where audit records are forwarded and who protects them from changes.

Software integrity checks at the boundary

On an isolated network, every container image, Helm chart and manifest bundle carried across the boundary is a supply chain input. NERC CIP-013-2 requires utilities to verify software integrity and authenticity for vendor software and patches. That rule does not apply to public sector systems, but it shows the kind of record assessors respect. Keep signed artifact digests, a transfer log for each import, and a rule that only mirrored, verified sources reach the repo-server.

What do public sector teams ask before hiring a partner for Argo CD?

What drives the cost of an Argo CD deployment for a government or defense program?

The biggest cost drivers are the size of the authorization boundary, the number of programs or agencies sharing the instance, and how much of the supply chain must be mirrored into a disconnected network. Each boundary adds clusters, identity integrations, Git hosts, registries and separate RBAC designs to build and test. Authorization paperwork is a recurring effort: system security plans, control implementation statements and evidence packages must be kept current as the platform changes. Ask for a quote that prices each boundary, each program onboarding, the mirroring workflow and the documentation deliverables as separate line items. Costs for DeployOpen's work follow from the written scope, and DeployOpen does not publish a price list.

How long does an Argo CD rollout take in a disconnected or accredited environment?

Duration depends on how many clusters are in scope, whether the environment is air-gapped, how many programs onboard, and how quickly the agency can approve artifacts and access. Disconnected builds usually add time for image and chart mirroring, offline verification of signed artifacts, and review of each package before it crosses the boundary. Authorization steps add review cycles that depend on the agency's own assessors, not on the build itself. A written timeline should name each milestone, the approvals it waits on and the staff who must be available. DeployOpen does not publish durations, so ask for a schedule tied to the agreed scope.

What must the agency provide before a partner starts work?

Most of the dependencies sit inside the agency's environment. Plan to provide:

An identity provider for SSO, such as an existing OIDC or SAML service, with group claims that map to Argo CD roles
A Git hosting service inside the boundary, with branch protection and access groups
An approved list of container images, Helm charts and other artifacts, with the approval process that admits them
Named staff for security, network, cluster operations and program owners, with time set aside for reviews
Access to the target clusters, network paths and the accreditation documents the build must satisfy

Confirm each item with the owning team early, because waiting on identity or approvals is a common source of delay.

Can our in-house platform team deploy and run Argo CD without a partner?

Often yes, if the team already runs Kubernetes in restricted networks and has people who understand GitOps, RBAC and TLS. The harder parts are the ones specific to government work: mirroring every dependency without internet access, separating programs with projects and scoped RBAC, and producing evidence that an assessor will accept. Run a short internal review against the official user management, high availability and security documentation to see where skills are thin. Many agencies use a partner for the design and build, then operate the platform internally with a documented runbook. Either model should end with a written handover.

How do the CMMC phase changes affect an Argo CD scope?

The phase changes affect when and how assessments are required, not the technical controls themselves. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start on 10 November 2026, and started a 60-day review. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because the CMMC Level 2 requirements are identical to NIST SP 800-171 Revision 2, and the Department of War says it will enforce that revision in the interim, the configuration management evidence you build now still applies. Confirm the current status with your contracting officer and the DoW CIO's About CMMC page before fixing the scope.

What should a quote for an Argo CD public sector engagement list?

A quote should follow from a written scope and list each deliverable separately. Ask for:

The boundaries covered, with the cluster count, network zones and whether the build is disconnected
The identity, Git and artifact-mirroring work, including who approves each artifact
Hardening and high availability items, such as admin disablement, RBAC design and recovery planning
Evidence deliverables mapped to the control families your assessor will test
Assumptions, exclusions and the agency responsibilities listed above
Support or retainer terms after handover, if you want them

DeployOpen does not pre-quote and does not issue audit reports or certifications, so ask your assessor to confirm which evidence they will accept.

How do we keep programs separated inside one Argo CD instance?

Use Argo CD projects to set which repositories, destination clusters and namespaces each program may use, then grant roles only to the groups that belong to that program. Since Argo CD 3.0, update and delete RBAC apply to the application itself, and logs access needs an explicit logs, get permission, so review those grants when you design roles. Disable the built-in admin account with admin.enabled set to false once SSO is configured. For strict separation, consider one instance per boundary, which removes shared controllers and Redis from the trust path. Test the boundaries with negative cases before any program goes live.

What DeployOpen needs from an agency or program to start

Before we scope an Argo CD engagement for a government or defense program, we need the authorization boundary written down: which systems, networks, clusters and people fall inside it, and which sit outside. The boundary decides whether Argo CD runs in the same accreditation package as the workloads it deploys, whether the Git server and container registry are inside or outside the boundary, and whether any cluster can be reached from a network that is not part of the same authorization. Ask your ISSO or security office to confirm the boundary in writing, including any cloud account, enclave or air-gapped network that the cluster depends on for images and packages.

Next we need the control baseline and the evidence the program already owes. Confirm whether the system is assessed against the NIST SP 800-53 moderate or high baseline, or against the NIST SP 800-171 requirements that a CMMC assessment will test, and ask for the current system security plan and any existing control inheritance statements. We also need the identity provider the program must use (for example, an agency directory reached through SAML, OIDC or LDAP), the Git host and container registry locations with their access model, a cluster inventory listing each cluster, its network placement and who operates it, and the name of the person or board that approves production changes. That approver determines the sync and promotion design, so it has to be known before any RBAC is drafted. Scope, deliverables and timelines are agreed in writing before work starts. Expect the scope to name the Argo CD installation, the SSO and RBAC mapping, the project boundaries between agencies or programs, the backup and recovery plan, and the evidence pack the program will hand to its assessor. DeployOpen prepares these systems and records; independent assessors and certification bodies issue any assessment outcome.

How DeployOpen scopes and supports Argo CD for government work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including air-gapped and on-premises networks. For Argo CD in public sector environments, we start from a written scope that names the controls, clusters and evidence your assessors will ask for.

How we scope

Confirm which agencies, programs or enclaves share the Argo CD instance and which must stay separated.
Map the clusters, Git hosts and registries that are in scope, including any air-gapped segments.
Agree in writing which control families and evidence artifacts the scope covers before work starts.

How we build

Configure SSO, RBAC and projects per program, with the built-in admin account disabled once SSO is working.
Define repository credentials as Kubernetes Secrets and restrict repo-server access to approved sources.
Test sync, rollback and access boundaries against the scoped requirements and record the results.

How we hand over

Document the configuration baseline, RBAC model, sync procedures and how change records are generated from Git history.
Provide runbooks for upgrades, patch intake, backup and recovery of Argo CD state, and access reviews.
Deliver evidence packages that your assessors can review, noting that DeployOpen prepares evidence but does not issue assessments.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer work can cover patch intake for supported Argo CD minor versions and re-testing after upgrades.
Ask for the support scope, response expectations and upgrade responsibilities in the written quote.