Improve GitOps Service multi-tenancy stance and tenant isolation

Goals

Argo CD provides means to host multiple tenants within a single Argo CD instance. However, these multi-tenancy mechanisms are rather “soft”, as they don’t properly isolate tenants from each other and assume a certain level of trust between the tenants.

The multi-tenancy in Argo CD mainly revolves around the mechanism of an AppProject. Each Application in Argo CD is assigned to such an AppProject, which sets up some governing rules and restrictions around what Applications assigned to this AppProject is allowed to do, for example:

• Which source repositories is the Application allowed to access (source control),
• Which clusters (and namespaces) is the Application allowed to sync to (destination control),
• Which kind of resources (and in which scope) is the Application allowed to access and deploy (content control),
• When are the applications allowed to deploy (time control),

At the time this mechanism was designed in Argo CD, there was a strong assumption that each of the tenants trust each other to a certain extent - for example, that they all belong to the same top-level organization. However, in a (more or less) public service model, this assumption holds no longer true.

There are a few gaps in the multi-tenancy model that we need to address in order to confidentially share an Argo CD instance between tenants that do not trust each other, and potentially malicious tenants in between.

The major goals for this feature-level issue are:

• Ensure that a GitOpsDeployment can only perform those actions as intended, even if it would be created declaratively by a user
• Isolate tenants properly from each other, so that
  • they cannot interfere with each other in terms of stability (i.e. one possibly malicious tenant bringing down the instance for everyone else),
  • their crown-jewels are properly protected from the prying eyes of possible malicious tenants
• tbd...

In Stone Soup, we currently have an architecture that shares an Argo CD instance between tenants. There are plans to move away from this architecture, but we’ll likely have shared Argo CD instances at least for the free-tier users until they decide to be moved to a paid plan.

Requirements

• • (Optional) 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 Considerations

< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >

What does success look like?

< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>

QE Contact

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

Done Checklist

• Acceptance criteria are met
• Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
• User Journey automation is delivered
• Support and SRE teams are provided with enough skills to support the feature in production environment