Feature Overview

One of the design goals of argocd-agent is that the topology does not need to be known to the principal. That is, the agent is given the principal's network address and the principal doesn’t care where exactly the agent is running. However, the agent must be uniquely identifiable by the principal, and the agent must securely authenticate to the principal.

A promising approach to this kind of securely establishing identity is the SPIFFE (Secure Production Identity Framework For Everyone) protocol, and its runtime implementation SPIRE. SPIFFE basically allows workloads, such as the agent, to securely establish identity in zero-trust environments - much like oAuth and OIDC allow for humans. By integrating SPIRE as the authentication layer, agents could successfully establish their identity to the principal.

Both SPIFFE and SPIRE are under the umbrella of the CNCF as graduated projects. However: 

• We do not have a product based on SPIRE (yet) as far as I know,
• We do not have any prior knowledge of SPIFFE or SPIRE.

If SPIRE is not viable, we at least need some mechanism to manage users (agents) on the principal, which must be well-integrated into the agent’s deployment/distribution method we chose. Maybe we can leverage the OCM/ACM handshake for that.

Goals

• Provide simplified deployments for customers with large network topologies
•  

Requirements

Use Cases

<What are we making, for who, and why/what problem are we solving?>

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).

• …