Why moving from GnuPG signature keys to Source Integrity is an upgrade task now
If your Argo CD instance still verifies commits through the deprecated signatureKeys setting, the GnuPG path is on a removal schedule. Argo CD has deprecated GnuPG signature verification and will remove it in the next major version, with Source Integrity Verification as the replacement. That makes the switch a item for your upgrade plan rather than a later cleanup. The change is documented in the 3.4 to 3.5 upgrade notes, so the natural place to schedule it is alongside that minor version move, not after the instance has already crossed into a release where the old setting is gone.
The supported path is to define sourceIntegrity on each AppProject through manifests or the CLI, since the UI does not configure it. Today the check covers Git GnuPG commit signatures, and a source that fails verification blocks the sync with a ResourceComparison error. Before you enforce anything, list every project and application that depends on signed commits, confirm which signing keys each team uses, and run the new policy in a non-production instance against real branches. Confirm with your Argo CD release notes whether any further source types are covered in the version you target, and do not assume coverage beyond Git commits.
Plan the test window around the workflows that enforcement will break. Once Source Integrity is enforced, local syncs such as argocd app sync --local stop working, and templated Git generator ApplicationSets with a templated project field are not supported. Identify those workflows early, because they are often the ones developers rely on during troubleshooting. Record which projects you changed, who approved the change, and the test results, so the evidence trail for the move is ready when auditors or change managers ask for it.
What changes between GnuPG verification and Source Integrity
This table compares the deprecated GnuPG signature key setting with Source Integrity on AppProjects, row by row. Read the action column as the work your team must finish before the GnuPG path is removed in the next major Argo CD version.
| Aspect | GnuPG signature keys (signatureKeys) | Source Integrity (.spec.sourceIntegrity) | Action for your team |
|---|---|---|---|
| Status | Deprecated; removal is planned for the next major Argo CD version | Replacement named in the deprecation notice | Plan the migration now rather than waiting for the removal release |
| Where it is set | Configured on the project's signature key list | Set on the AppProject spec in manifests or with the CLI, not the UI | Export each project to YAML and keep the change in Git |
| What is checked | GnuPG signatures on verified commits | Git GnuPG commit signatures on the project's sources | Confirm every source commit is signed by a key you trust |
| Failed source behavior | Sync is blocked when verification fails | Sync is blocked with a ResourceComparison error | Alert on this error in your monitoring and runbooks |
| Multi-source apps | Applied at the application level | Rules are defined per source, so each source needs its own check | Review every source of each multi-source application |
| Local syncs | Not covered by this change | argocd app sync --local is not possible once enforced | Move any local sync workflow to a Git-based sync before enforcement |
| Templated ApplicationSets | Not covered by this change | Not supported for Git generator ApplicationSets with a templated project field | Hard-code the project name or redesign the generator before enforcement |
| Version timing | Deprecation notice in the 3.4 to 3.5 upgrade notes | Available as the replacement for the GnuPG path | Confirm the exact removal release with the Argo CD project before scheduling |
What the sourceIntegrity field checks and what it does not
The sourceIntegrity field in an AppProject tells Argo CD which Git sources it must verify before it renders or syncs anything from them. Today, the check covers Git GnuPG commit signatures: Argo CD looks at the signature on the commits it is asked to deploy and compares it against the keys you have trusted for that project. The old signatureKeys setting did something similar at the repository level, but the new field moves that decision into the project boundary, so the trust rule sits next to the RBAC and destination rules your teams already review. When a source fails the check, the sync is blocked and the application reports a ResourceComparison error. It does not fall back to deploying the unverified revision, so a bad commit stops the rollout instead of quietly reaching the cluster.
The field does not verify everything that reaches a cluster. It checks commit signatures on Git sources, so it says nothing about the contents of a Helm chart pulled from a registry, the images those manifests reference, or the integrity of a source type the current release does not handle. Before you write your policy, open the current Source Integrity guide and confirm which source types and verification methods are supported in the Argo CD version you run, and whether any of them apply to the multi-source setup you plan to use. Also confirm which keys can be trusted per project and how key rotation is handled, because a policy that cannot be maintained will be bypassed under pressure. Treat the field as one control in a chain that also includes branch protection and review, not as proof that every artifact is authentic.
Writing per-source rules for multi-source applications
A single-source application pulls manifests from one Git repository, so the rule set is the simplest to reason about. The project's sourceIntegrity configuration applies to that one repository, and the team needs to confirm which Git repository URL and path the project allows, then decide which signing keys are trusted for it. Start by listing every application assigned to the project and confirming that each one points at a repository you have already mapped to a signing policy.
- Map the repository once: Record the repository URL, the branch or tag pattern that deploys to production, and the expected signing identity for commits on that path.
- Check the project boundary: Confirm which applications belong to the AppProject, since a single rule covers every application that inherits it.
- Review branch behavior: Confirm that the branches used by each application are the ones your signing policy covers, not only the default branch.
- Plan the key list: Collect the GnuPG public keys that developers and automation are allowed to sign with, and retire keys for people who have left.
- Test with one application first: Sync a known-good commit and a commit signed with an untrusted key in a non-production project to confirm the block behaves as expected.
Before enforcing, check that every single-source application in the project resolves to a repository you have mapped, and that the test sync output matches what your change process expects.
A multi-source application pulls from several repositories, such as a Helm chart from one place and values files from another. Each source is evaluated, so one unsigned or untrusted source can block the whole sync even when the others pass. The team should map every repository in every multi-source application to an expected signing policy, then confirm how the running version handles a source that has no matching rule. Do not assume a missing rule means allow or deny. Test it in your environment.
- Inventory every source: Export the source list for each application, including chart repositories and values repositories, not only the main manifest repository.
- Assign a policy per source: Give each repository its own expected signers, even when two sources share the same team and keys.
- Handle shared values repositories: A values repository used by several applications may need different signers than the chart repository it feeds.
- Confirm the default for unmatched sources: Test an application with an extra source that has no rule and record whether it syncs, warns or blocks.
- Record exceptions: Document any source that cannot be signed, such as a third-party chart, and the approval that accepts that risk.
For illustrative purposes, an application with a signed chart repository and an unsigned values repository will be blocked if the values source has no permitted signer, so check the unsigned source first.
Many projects hold both single-source and multi-source applications. A project-level configuration applies to every application in it, so a rule written for the simple applications can silently cover, or fail to cover, the complex ones. The safer approach is to group applications by source pattern before writing rules, then confirm that each group's rules match the repositories it actually uses. Where a project mixes teams with different signing practices, consider splitting it so each team's rules stay separate.
- Sort by source pattern: Group applications into single-source and multi-source lists, and note which repositories appear in both.
- Avoid broad rules by accident: Check whether a project-level rule would also apply to a multi-source application you did not intend to cover.
- Split projects where practices differ: Move teams with different signing policies into separate projects so their rules do not interact.
- Track new sources: Make adding a repository to an application a change that also updates the signing map.
- Review on a schedule: Re-check the map after each application change, since new sources often appear in multi-source applications without a rule update.
Before relying on a mixed project, have a named owner confirm the complete application-to-repository map against the running configuration.
Limits that break existing workflows
Once Source Integrity is enforced, some habits that worked under GnuPG verification stop working. The cards below cover the sync paths, ApplicationSet patterns and team workflows that depend on local or unsigned input, so you can find them before cutover rather than during an incident.
Local syncs with argocd app sync --local
Once Source Integrity is enforced, local syncs are not possible. The argocd app sync --local path renders manifests from a working directory on someone's machine, which means there is no Git commit whose signature can be checked. Inventory every runbook and script that calls this command. Each one needs a replacement that pushes a signed commit and lets Argo CD sync it. Confirm the exact enforcement behavior in the Source Integrity guide before you rely on it.
Git generator ApplicationSets with templated projects
Source Integrity is not supported for Git generator ApplicationSets that use a templated project field. Teams that generate one Application per folder and assign each to a project from a template value will need to restructure. Options to evaluate include setting a fixed project per ApplicationSet or splitting generators by project. Test any change in a non-production instance and confirm current support with the vendor documentation.
Local developer testing workflows
Developers who preview changes by rendering manifests locally and comparing them to the cluster will lose that loop for enforced projects. Redesign it around branches or preview environments that sync from signed commits. Agree with engineering leads which checks stay local, such as Helm lint or Kustomize build, since those do not require Argo CD to sync. Document the new feedback path so developers know where to look when a sync is blocked.
Pipelines that depend on local syncs
CI jobs that push manifests into a cluster through a local sync bypass the Git commit history that Source Integrity checks. Such pipelines should commit to Git with signing keys held in your secrets store, then let Argo CD perform the sync and report the result. Confirm how your CI system signs commits and how the signing identity maps to the people and automation your audit trail must name.
Signing identities for commits
Source Integrity currently checks Git GnuPG commit signatures, so every committer whose changes reach an enforced project needs a valid signing key. Inventory contributors, bots and service accounts that push to those repositories, and decide who issues and rotates their keys. Missing keys will block syncs with a ResourceComparison error, so plan key distribution before the policy switches to enforcement.
How to move from signatureKeys to sourceIntegrity step by step
This sequence replaces the deprecated GnuPG signatureKeys setting with Source Integrity Verification one AppProject at a time, so each project is tested, enforced and reversible before the old setting is removed.
Inventory every signatureKeys reference
The platform team lists each AppProject that sets signatureKeys, each Application and ApplicationSet that uses those projects, and each Git source that is currently verified. Include projects in Git manifests, Helm values and any CLI scripts that create or patch projects, because a setting left only in the cluster will be lost on the next sync from Git. Confirm which signing keys are trusted today and who owns them. Done when you have a written list of projects, sources and key owners, and a note on which teams run local syncs. Keep this inventory with the change record so it doubles as evidence of what was verified before and after.
Define sourceIntegrity rules in a non-production project
In a non-production instance, add a sourceIntegrity block under the AppProject spec, using manifests or the argocd CLI rather than the UI, which the Source Integrity guide notes is not the configuration path. Start with one project that holds a representative Git repository whose commits are GnuPG-signed. Keep the old signatureKeys setting in place during this step so you can compare behavior. Done when the project manifest applies cleanly and reads back with the expected Git rules in the cluster.
Test a passing sync and a failing sync
Run two controlled tests against the non-production project. First, sync an application whose latest commit carries a signature the rule trusts, and confirm the sync completes. Second, sync from a commit that is unsigned or signed by an untrusted key, and confirm the sync is blocked with a ResourceComparison error that appears in the application status. A blocked sync is the expected result here, so record it as a pass. Done when both outcomes match what you expected and the test evidence is saved.
Review ApplicationSets and local workflows
Before enforcement, find every ApplicationSet that uses a Git generator with a templated project field, because Source Integrity is not supported for that combination. Move those ApplicationSets to a fixed project reference or plan a separate project for them. Also identify engineers or pipelines that run argocd app sync --local, since local syncs are not possible once Source Integrity is enforced. Agree on a replacement workflow with those teams. Done when each affected ApplicationSet and local workflow has a documented owner and target path.
Enforce in production one project at a time
Apply the tested sourceIntegrity rules to one production AppProject, starting with a project that has the fewest dependencies, and keep its previous manifest exported before the change. Watch the application sync results and the status of each application in that project for the first sync cycles. Confirm each source is still trusted and that signed commits from your normal release process still deploy. Repeat for the next project only after the previous one is stable. Done when the enforced project shows healthy syncs and no unexpected ResourceComparison errors.
Keep a rollback point and restore if needed
For every project, the rollback point is the exported manifest of the AppProject as it was before the change, stored in version control or your change system. If a legitimate release is blocked, restore that previous AppProject manifest, confirm the affected applications sync again, then investigate the signing or repository issue before reapplying the new rules. Note that restoring the old manifest does not remove signatureKeys from the Argo CD release you are running, so the removal work still needs a plan. Done when the rollback has been rehearsed in non-production and the restore steps are written down.
Confirm the removal plan before the deprecated setting is dropped
After all projects use sourceIntegrity, check the current Argo CD upgrade notes for the release you are moving to, because the GnuPG deprecation notice says the setting will be removed in the next major version. Remove signatureKeys from every project manifest in Git, then confirm no project still depends on it. Ask your DeployOpen or internal reviewer to read the relevant upgrade notes with you before the removal date is set. Done when your project inventory shows zero signatureKeys references and the upgrade notes have been checked against your remaining local sync and ApplicationSet work.
Testing enforcement and rolling back a blocked project
Test enforcement on a non-production AppProject before you change any production project. Pick a sandbox project that points at a Git repository you control, add the sourceIntegrity block to its .spec with the Git GnuPG check your team intends to use, and then push a deliberately unsigned commit to the tracked branch. Refresh the Application and confirm that the sync is refused rather than applied. The point of the test is to prove the block with your own repository, your own key set and your own Argo CD version, not to trust that the behavior matches the documentation.
Next, confirm the failure is reported where your operators will look for it. A failed source should surface as a ResourceComparison error on the Application, which you can check in the UI, with argocd app get, or in the Application's status conditions. Run the same check with a commit signed by a key that is in the allowed set, so you know a valid signature passes and the block is caused by the signature rather than by a misconfigured project. Also check any alerting you have wired to Application health or sync events, because a blocked sync may not look like a failed deployment to a dashboard that only counts sync failures.
Plan the rollback before you enforce anything. Store the previous AppProject manifest in Git so that rollback is a revert of the sourceIntegrity change followed by a sync of the project, and rehearse that revert in the sandbox. Decide in advance who may approve a rollback, how a blocked deployment is communicated to the application owners, and how a legitimate hotfix is signed or temporarily routed. Confirm the exact removal and sync behavior in the Argo CD version you run against the Source Integrity Verification guide, since the enforcement and recovery steps may differ between releases.
What makes a Source Integrity migration take longer
This table lists the factors that expand or shrink a move from signatureKeys to Source Integrity, and what each one means for scope. Read each row against your own estate: the more a factor applies, the more inventory, testing and sign-off time to plan and ask a partner to price.
| Effort driver | Why it changes the work | What to ask for in a quote |
|---|---|---|
| AppProjects and applications | Each AppProject that gets a sourceIntegrity policy must be reviewed, and every application under it may start failing syncs once enforced. | An inventory of AppProjects and applications by project, with the proposed policy for each. |
| Repositories and commit signing | Repositories whose commits are not GnuPG signed will block syncs once they fall under enforcement, so signing gaps must be closed or excluded first. | A repository list showing which ones sign commits today and who owns each signing fix. |
| Multi-source applications | Source Integrity rules are set per source, so each source in a multi-source application needs its own check and its own test. | A count of multi-source applications and a per-source verification plan for each. |
| Templated Git generator ApplicationSets | Source Integrity is not supported for Git generator ApplicationSets with a templated project field, so these must be redesigned or moved to a fixed project. | A list of affected ApplicationSets and the proposed redesign, with the owner who approves it. |
| argocd app sync --local in developer or CI workflows | Once enforced, local syncs are not possible, so every workflow that depends on them needs a replacement path agreed with the teams that run it. | An inventory of scripts and pipelines that call local sync, and the replacement workflow for each. |
| Teams that must agree on signing policy | Each team that owns a project or repository may need to approve the policy, and disagreements extend the timeline more than technical work does. | A named approver per project and a written signing policy signed off before enforcement. |
| Deprecation timing | Teams that remove signatureKeys before moving to Source Integrity may face sync failures during the gap, so the two settings must be planned together. | Confirmation of the Argo CD version in use and the plan for running both mechanisms during cutover. |
Questions buyers ask before moving off GnuPG verification
Can our own team make the switch from GnuPG signature keys to Source Integrity?
Yes, if you have people who own the Argo CD installation, the AppProjects and the Git repositories they point to. The change itself is a configuration task: you add a sourceIntegrity block to each AppProject's .spec through manifests or the CLI, not the UI. The harder part is knowing what the setting will affect. Your team needs to find every project that relies on signatureKeys, confirm which sources already carry valid GnuPG commit signatures, and agree on what happens when a source fails. A partner such as DeployOpen can run that inventory and test plan under a written scope, but the decision to adopt it stays with your team.
What drives the cost and effort of this change?
The main drivers are the number of AppProjects, the number of repositories and sources per application, and how many commits are unsigned or signed with keys that are not yet trusted. Multi-source applications need a rule for each source, so they take longer to review. ApplicationSets that template the project field need a different approach, because Source Integrity does not support that pattern for Git generators. Cost also depends on how many workflows rely on local syncs, since those must be redesigned. Ask any provider for a quote that lists the projects and repositories in scope, the test environments used, and who signs off on each sync policy change.
How long does moving off GnuPG verification take?
It depends on scope, so no fixed duration applies to every installation. The time is mostly spent on inventory, signing gaps and testing, not on editing YAML. Installations with a few projects and clean signing history move faster than those with many teams, shared repositories or ApplicationSets with templated projects. Ask for a timeline tied to a written list of projects, repositories and test cases, and check whether the plan includes a rollback path in a non-production instance before any change reaches production.
What does the team need to provide before the work starts?
Three inputs matter most. First, a complete inventory of AppProjects, applications, ApplicationSets and the signatureKeys settings currently in use. Second, named repository owners who can confirm which branches must be signed, who holds the signing keys, and how commits from outside contributors are handled. Third, a non-production Argo CD instance that mirrors production projects and repositories, so that you can see which syncs fail before enforcement. Your team should also confirm which automation depends on local syncs, because argocd app sync --local will not work once Source Integrity is enforced.
Can we still run local syncs after switching to Source Integrity?
No. Once Source Integrity is enforced, local syncs such as argocd app sync --local are not possible. Teams that use local syncs for debugging or pre-merge checks need another route, such as syncing from a Git revision that has passed signature checks, or a separate non-enforced environment for experiments. Identify these workflows during the inventory, not after cutover, and confirm the replacement process with the people who run them.
What happens if GnuPG verification is removed before we switch?
Argo CD has announced that GnuPG verification is deprecated and will be removed in the next major version, with Source Integrity Verification as the replacement. Once the removal ships, the signatureKeys setting will no longer provide the check your projects depend on, so syncs that relied on it may behave differently after an upgrade. Plan the switch before the upgrade that removes it, and read the 3.4 to 3.5 upgrade notes and the Source Integrity guide to confirm the version and behavior in your environment. Do not assume that an unsigned source is still blocked after removal.
Does Source Integrity cover every kind of source Argo CD syncs?
Not today. Source Integrity currently checks Git GnuPG commit signatures and blocks a sync with a ResourceComparison error when a source fails. It does not replace review of Helm chart sources or other repository types, so confirm coverage for each source type your projects use. For multi-source applications, define a rule for each source, because one unverified source can block the whole application. Check the Source Integrity guide for the current list before you write the policy.
How DeployOpen scopes and delivers the Source Integrity move
DeployOpen plans and implements the move from GnuPG signature verification to Source Integrity inside your own Argo CD installation and clusters. Engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before any change is made to your Git sources or AppProjects.
How we scope
- We inventory every AppProject, Git source and ApplicationSet that currently relies on the signatureKeys setting.
- We record which teams run local syncs or templated Git generator ApplicationSets that Source Integrity cannot cover.
- The written scope names the target Argo CD version, the signing keys to trust, and the projects in scope.
How we build
- We define sourceIntegrity rules in AppProject manifests, applied through version control and reviewed like any other change.
- We set per-source rules for multi-source applications so each repository is checked against the key it should use.
- We test blocked syncs in a non-production instance first, confirming the ResourceComparison error appears for unsigned commits.
How we hand over
- You receive the AppProject manifests, a list of verified and excluded sources, and the reasoning behind each exclusion.
- We document the replacement workflow for teams that used argocd app sync --local, including how they will deploy instead.
- We walk your platform and security engineers through the rules, the failure messages and the rollback steps.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover reviewing new Argo CD release notes before the GnuPG removal version reaches your environment.
- Ask any provider to confirm in writing who maintains the signing key lists after handover and how changes are approved.
