Feature Overview

Propose and implement Source Integrity Policies in upstream Argo CD.

Proposal: https://github.com/argoproj/argo-cd/pull/25148
Implementation: https://github.com/argoproj/argo-cd/pull/25371

Goals

Source Integrity Policies are to replace the current GPG commit verification in Argo CD with a more modern and flexible approach. There are multiple issues with the current verification feature, most notably:

• Only the tip of any branch will ever be verified. Previous commits will be ignored. This allows for other (potentially malicious) unsigned commits to slip in.
• No support for multi-source applications
• No support for other sources other than Git (e.g. Helm and OCI)

The Source Integrity Policies are expected to implement some of these features in a first iteration (e.g. multi-source support, support for verifying all commits) while others (Helm support, OCI support) will be implemented later.

There is some prior art:

Outdated Proposal: https://github.com/argoproj/argo-cd/pull/14964

Outdated PoC PR: https://github.com/argoproj/argo-cd/pull/14966

Requirements

Use cases

• Users who use multi-source applications
• Users who use sources other than Git
• Users who have elevated security requirements

Out of scope

<Defines what is not included in this story>

Dependencies

< Link or at least explain any known dependencies. >

Background, and strategic fit

< What does the person writing code, testing, documenting need to know? >

Assumptions

< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

Customer Considerations

< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>

Documentation/QE Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
< Does this feature have a doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>

Impact

< If the feature is ordered with other work, state the impact of this feature on the other work>

Related Architecture/Technical Documents

<links>

Definition of Ready

• The objectives of the feature are clearly defined and aligned with the business strategy.
• All feature requirements have been clearly defined by Product Owners.
• The feature has been broken down into epics.
• The feature has been stack ranked.
• Definition of the business outcome is in the Outcome Jira (which must have a parent Jira).