Verifying signed Git commits in Argo CD

Blocking unsigned commits from syncing with Argo CD

A platform team that must show only reviewed, approved commits reach production clusters needs a control that acts at sync time, not only a policy in the Git host. In Argo CD, Source Integrity Verification lets an AppProject declare the criteria that sources must meet before they are applied. The criterion currently available is GnuPG-signed Git commits. An application syncs only when every check passes. If a commit on the tracked revision lacks a signature from a key the project trusts, the application does not sync and reports a ResourceComparison error. That error is the signal your on-call engineers and auditors will look for, so plan how it reaches your alerting before you turn the rule on.

This control is worth the effort when a Git branch is the change record for production, when the Git host allows direct pushes or weak branch protection, or when a compliance assessment expects evidence that a change was approved by a named key holder. It is usually not the right first step if your team does not yet enforce pull request review and protected branches, because a signature proves who signed a commit, not that the change was reviewed. Also check the topic's constraints early: commits created by the Source Hydrator are not signed, so verification on a hydrated branch fails, and local syncs need separate handling. Confirm both behaviors against the Source Integrity Verification guide and the Source Hydrator guide for your Argo CD version before you commit to a design.

How the signature check decides whether a sync runs

Source Integrity Verification is an AppProject setting, so the decision is made per project and per source before any sync starts. The cards below follow the order in which Argo CD evaluates a sync: the project criteria, the source each application pulls from, the GnuPG keys it trusts, and the result the application reports.

AppProject signature criteria

The AppProject is where you declare that its sources must meet a signature requirement. Today the only criterion is GnuPG-signed Git commits, so a project either requires signed commits from its repositories or it does not. Decide which projects are production-facing and enable the check there first, because every application in the project inherits the requirement. Check the project spec in your own environment after applying it, since a project that is not configured this way will sync unsigned commits without any warning.

Per-source rules within a project

A project can pull from several repositories, and each source can be a different trust zone. Map every repository URL in the project to its own verification expectation, so a shared configuration repository and a vendor chart source are not judged the same way. A source that is not covered by a rule is a gap to close during review. Document which repositories are in scope for signing so that new sources added later do not slip past the check unnoticed.

The trusted GnuPG key set

The check is only as strong as the keys it trusts. Build a short, named list of the GnuPG public keys that may sign commits for each project, and assign an owner and a rotation process for each key. Remove keys when people leave or when a key is compromised. Confirm in the official guide how keys are stored and referenced in your Argo CD version, and test that a commit signed by a key outside the list is rejected before you rely on the control.

Sync outcome when a check fails

When any criterion fails, the application does not sync and reports a ResourceComparison error. Teams often read that status as a generic drift problem, so add it to the runbook as a signature failure first. Check whether your alerting or notifications surface the status, and whether the on-call engineer can tell an unsigned commit from a repository outage. Do not treat the error as a reason to disable the project check without reviewing the commit that caused it.

Hydrated branches fail the check

Commits created by the Source Hydrator are not signed, so a hydrated branch will fail signature verification even when the source commits were signed. Decide whether hydrated output is in scope for the project check, and if it is, plan how hydrated commits will be trusted or whether the check should apply only to the source branch. Confirm this behavior in your Argo CD version before you enable hydration on a protected project.

Verification options per project and per source

This table compares the two places Source Integrity Verification can be configured, the AppProject as a whole and each individual source, and the key-trust choices that go with each. Read it by matching your repository layout to a row, then checking which keys the project should trust. The main takeaway is that a shared platform repository with several sources needs narrower rules than a single application repository, so the scope of trust should follow repository ownership rather than project convenience.

Option	How it is scoped	Trade-off	When it fits
Project-wide criteria	Source Integrity rules set once on the AppProject apply to every application in that project	Simple to review, but any source in the project inherits the same key set, including sources owned by other teams	One team owns all repositories in the project and signs commits with the same key policy
Per-source rules	Criteria are attached to a specific source, so each repository can trust its own keys	More precise trust, with more configuration to keep in step as repositories are added or renamed	A shared platform repository sits beside application repositories with different signers
Single application repository	One repository, one signing group, one project	Lowest key-management overhead, and a compromised key affects only that repository	Dedicated app team with a clear list of committers and signing keys
Shared platform repository with several sources	Multiple sources in one application, each with its own trusted key list	Requires a mapping of source to signer group that reviewers must maintain	Platform or base manifests are signed by a central team while app overlays are signed locally
Keys held by a single group	Trusted key list limited to the people or automation that own the repository	Clear accountability, but key rotation depends on that group being reachable	Regulated change control where each repository has a named owner
Keys shared across repositories	One trusted key list reused by several sources or projects	Less to maintain, but one leaked key can satisfy checks in every repository that trusts it	Small teams with a single signing identity, where the cost of separate keys outweighs the risk
Hydrated or generated branches	Verification is attached to the source branch, because hydrator commits are not signed	Hydrated output is not verified on its own, so the source commit must carry the signature	Teams using the Source Hydrator should confirm the verification point before enabling enforcement
Local or Helm-only sources	Confirm in your Argo CD version whether the check applies to the source type you use	Some source types may not be covered, so a sync can pass without a signed Git commit	Use only after testing in a non-production project and confirming behavior with the Argo CD documentation

Setting up signed commit verification step by step

This sequence turns on signed-commit verification for one AppProject so that its applications sync only from commits signed by keys you approved. Each step closes with a check you can run before you move to the next one.

Confirm the Argo CD version and feature support
The platform owner checks the installed Argo CD version against the Source Integrity Verification guide and the release notes for that version. Confirm which versions include the feature, which source types it covers, and which Git hosts and signing setups you can use. Apply current patch releases within the supported window before you enable new controls. Done when you have recorded the exact version and the guide section you followed.
Collect the GnuPG public keys for approved signers
Ask each committer, or the owner of each signing service, for the public key they use to sign commits to the deployment repositories. Confirm that every key belongs to a named person or a defined automated identity. Record each fingerprint and its owner in your change system, and agree who approves additions and removals before any key is loaded. Done when the list of fingerprints matches the signing identities your Git host shows for those accounts.
Register the public keys in Argo CD
A cluster administrator adds the approved public keys to Argo CD using the method described in the guide for your installed version. Keep the key store under the same change control as the AppProject, and limit who can edit it. Load public keys only, and keep every private key on the signer's own workstation or signing service. Done when Argo CD lists the imported keys and their fingerprints match the reviewed list from the previous step.
Add verification criteria to the AppProject
Edit the AppProject that owns the applications and add the source integrity criteria that require GnuPG-signed Git commits. Start with one project whose repositories you can test without touching production workloads. Commit the change to the Git repository that manages your Argo CD configuration so the project definition has a reviewable history. Done when the project manifest applies cleanly and the project view shows the criteria as active.
Bind the rules to the right sources
Map each criterion to the sources it should guard, since one AppProject can contain repositories with different owners. Check any application that reads from Source Hydrator output, because the Source Hydrator guide states that hydrator commits are not signed. A rule on the hydrated branch will therefore fail, so verify the source branch instead or exclude that path. Confirm how local syncs behave, since they do not originate from a signed Git commit. Done when each application in the project shows the verification status you intended.
Test with one signed and one unsigned commit
Push a commit signed by an approved key to a test application's source path and confirm that the application syncs. Then push an unsigned commit, or one signed by a key that is not on the list, and confirm that the application does not sync. The failing application should report a ResourceComparison error in its status. Done when both results match your expectations and you have saved the output in your change record.

Managing GnuPG keys for commit verification

Platform engineers own the trusted key set that Argo CD uses when Source Integrity Verification checks a commit. Their work is to decide which GnuPG public keys are accepted for each project and source, to import and record them, and to change that set when people join, leave or rotate keys. Argo CD does not generate keys for anyone, so key generation ownership must be assigned in writing before the first sync is gated.

Key ownership: Record who created each key, which repository and project it may sign for, and who approves its addition to the trusted set.
Rotation sequence: Add the new public key to the trusted set first, confirm that signed commits from the new key sync, then remove the old key.
Revocation: When a key is lost or a person leaves, remove it from the trusted set promptly so that new commits signed with it are blocked.
Blocked syncs: A commit signed by a key that is no longer trusted fails verification, and the application reports a ResourceComparison error instead of syncing. Plan who responds to that alert.
Audit record: Keep the change history of the trusted key set alongside your Git history so reviewers can see when each key was accepted or removed.

Before you go live, confirm with your Argo CD version's documentation exactly how the trusted keys are stored and reloaded in your environment.

What breaks for local syncs and hydrated commits

Commits created by the Source Hydrator are not signed, so once Source Integrity Verification is enabled on a project, any application that reads the hydrated branch fails its signature check and reports a ResourceComparison error instead of syncing. The failure is not a sign that the hydrator is compromised. It is a gap in the design: the check expects a GnuPG signature from an approved key, and the hydrator does not add one. Before enabling the rule, list every source the project uses and mark which ones are hydrated branches. Those sources need a different answer, either a path that keeps verification on the human-authored commits or a signing step you control, and the choice should be written down before the check goes live. The Source Hydrator guide describes how the hydrated branch is produced, which helps when you map the flow.

Local syncs are the second group that breaks. Engineers who run argocd app sync from a workstation against an unsigned working tree, or who point an application at a path they have not committed, will fail verification, because the check evaluates the commit that Git serves, not the files on disk. Pipelines have the same problem when a bot commits image tag updates, Helm values changes or rendered manifests back to the repository on the team's behalf. Those commits need either a signing key the pipeline can use without exposing the private key to build logs, or a rule that the project's sources do not include the branches the bot writes to. Confirm which identity signs each automated commit, where its private key is stored, and who can rotate it, before you allow the bot to write to a branch that an enforced project reads.

Security considerations for trusted signing keys

The trusted key list decides which commits Argo CD will sync, so it carries as much weight as the verification itself. The cards below cover who owns that list, how broad it should be, how the AppProject holding it is protected, and how Argo CD's RBAC and project boundaries keep those criteria from being edited quietly.

Own the trusted key list

Every GnuPG key placed in an AppProject becomes a principal Argo CD will accept as the author of a commit to that project's sources. Name one accountable owner for the list, usually the platform or security team, and record who approved each key and why. Ask whether your Git host ties signing keys to individual accounts, because a key that outlives an engineer's departure keeps its trust. Review the list on a set schedule and when people change roles.

Keep the key set narrow

A broad key set weakens the control because any key on the list can approve changes to every source the project covers. Scope keys per project and per source where Argo CD allows it, so a key trusted for a staging repository cannot approve production manifests. Illustrative example: a team key for an application repo should not also be trusted for a shared platform repo. Check each key against the paths and branches it actually needs to sign.

Protect the AppProject definition

The AppProject is where the verification criteria live, so changing it is equivalent to changing the security control itself. Store project manifests in a Git repository with its own review rules, and have Argo CD manage them only from that protected source. Confirm that no application or tenant can write to the project object directly. A removed or weakened signature rule should show up as a reviewed change, not a silent edit.

Limit who can edit projects

Argo CD RBAC controls who can update AppProjects, and the security documentation treats project boundaries as a primary control. Restrict update and delete rights on projects to a small platform group, and keep application-level rights separate from project-level rights. Review the policy after SSO group mappings change, since a broad group mapped to a project admin role silently grants the ability to remove signature checks. Test the policy with a non-admin account before relying on it.

Watch for stale or unexpected trust

Verification only proves that a commit carries a signature from a listed key, so an attacker who obtains a trusted key can still pass the check. Plan key revocation and rotation as a runbook: remove the key from the project, confirm that affected applications report errors, and review commits signed by it since its last known good state. Ask your team how a compromised key would be detected and who can act within the same working day.

Separate the hydrated branch path

Commits made by the Source Hydrator are not signed, so a project that verifies signatures on a hydrated branch will fail to sync. Decide whether signing applies to the source commits that feed the hydrator, and keep the verification scope aligned with what Argo CD actually checks. Document this boundary in your change procedure so auditors can see which commits were verified and which were produced by the pipeline.

Questions teams ask before enabling signed commit checks

How much does it cost to enable signed commit verification in Argo CD?

The cost depends mostly on how many repositories, projects and signing keys the change touches, and on how much of the work your own team can absorb. The configuration itself is small: a GnuPG public key is registered in Argo CD and referenced from the AppProject that owns the applications. The larger costs are the time spent agreeing on who may sign, building the key workflow, and testing every application that will now be blocked if an unsigned commit arrives. Ask any partner for a fixed-scope quote built from a written list of repositories, projects and sync paths, and ask which parts recur, such as key rotation and review of new signers.

How long does a signed commit rollout take?

Duration is driven by the number of projects and sources, the state of your key management, and how many pipelines write to the branches Argo CD reads. A single project with one repository and a clear signer list is a short change. Many teams with several repositories, contractors committing under shared accounts, or automation bots that need signing keys take longer, because each identity must be assessed before enforcement starts. Plan a period where checks run against real history before they block syncs, and confirm the sequence with your change board.

What must our team provide before the work starts?

You need to provide the list of repositories and branches to protect, the GnuPG public keys of people and systems allowed to sign, and read access to those repositories for the engineers doing the work. You also need a decision on who owns key creation, storage and revocation, and a test environment where Argo CD can be configured without affecting production applications. Without these inputs, the rollout tends to stall at the point where someone asks whose key a commit should carry. The Source Integrity guide in the Argo CD documentation describes the criteria your project configuration will depend on.

Can our own platform team do this without a partner?

Yes, if the team already runs Argo CD, understands AppProjects and can manage GnuPG keys with an agreed process. The configuration is documented by the project, and a team with that background can test it in a non-production cluster first. A partner usually adds value where the rollout crosses several teams, where the key process has to be designed from scratch, or where you need documented evidence for an assessment. Decide based on whether your engineers have time to test the blocked-sync paths thoroughly, not only the happy path.

What breaks when we turn on signature checks?

The most common breakage is an application that syncs from a branch where some commits were never signed, such as merges created by a web interface, bot commits or older history. Argo CD reports a ResourceComparison error for the application and does not sync until the check passes. Local syncs, where an engineer applies a manifest from a working directory rather than from a verified commit, also fall outside what the check can confirm, so the team must decide whether that path stays allowed. Test each sync path your teams use before enforcing, and document the exceptions.

How do hydrated commit workflows change the plan?

Hydrated workflows change the plan substantially. The Source Hydrator creates commits that are not signed, so signature verification on the hydrated branch fails by design. You cannot simply add the hydrated branch to the same rule and expect it to pass. The practical approach is to verify the signed source commits that feed the hydrator, and then confirm that your team accepts the hydrated output under its own control. Check the Source Hydrator guide before you decide, because the verification point and the branch you protect must be chosen together.

How does signed commit verification affect audit evidence?

It gives you a stronger link between a change and an approved identity, because each synced commit must carry a signature from a key you have registered. It does not by itself satisfy a control, and it does not create an audit report. Auditors will ask how keys are issued, who may sign, how revoked keys are handled and how exceptions are approved and recorded. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the findings, so confirm the evidence format with your assessor before the rollout is designed.

What ongoing work follows the initial rollout?

Once checks are enforced, the recurring work is key rotation, onboarding and offboarding of signers, review of exceptions, and updating project rules when repositories or teams change. Keys held by departing staff or automation must be removed from the allowed list in the same change. Ask any partner which of these tasks sit inside the fixed-scope delivery and which would move to an ongoing support arrangement, and ask how the team will be notified when a sync is blocked.

How DeployOpen works on this

DeployOpen scopes signed commit verification for Argo CD around the repositories, AppProjects and key holders that matter in your environment. We then build, test and document the enforcement in the Argo CD instance you run in your own infrastructure, so your team can operate it after handover.

How we scope

Inventory the Git repositories, branches and sources each AppProject deploys from, and which need signature checks.
Agree which GnuPG keys are approved, who owns them, and how key rotation and revocation are handled.
Confirm the written scope covers local syncs, hydrated commits and any exceptions, before work starts, as engagements are fixed-scope.

How we build

Import approved public keys into Argo CD and apply Source Integrity rules per project and per source in a test instance first.
Test a signed commit that syncs, an unsigned commit that is blocked, and a commit signed by an unapproved key.
Document the sync error behavior and the commands your team uses to confirm which keys and rules are active.

How we hand over

Deliver the project manifests, key inventory, test results and runbook covering the sync failure triage path.
Walk your platform and security engineers through the rules, the key lifecycle and the known gaps for hydrated branches.
Record which pipelines, Source Hydrator flows and local sync workflows need separate handling outside Argo CD.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Support can cover Argo CD version changes that affect Source Integrity behavior and re-testing after key changes.
Confirm the support terms and response expectations in the written quote, since DeployOpen does not publish a price list.