Restrict Application.spec.project by Application.spec.source.repoURL

[dulltz]

Summary

Allow restricting the value of Application.spec.project to control tenants' authority.
In my knowledge, Application.spec.project can be set any project name.

Motivation

Let me explain my use case.
We're using ArgoCD for multi-tenant K8s.
To allow tenants to add Applications by themselves, I prepared the following AppProject resources:

• default: The project for the admin team. The apps belong to the project can deploy any kind of resources.
• tenant: The project for tenants. The apps belong to the project can deploy the resources in specified namespaces only.
• tenant-apps: The project for tenants' app-of-apps. The apps belong to the project can only deploy Application resources in argocd namespace.

Moreover, we prepared the app-of-apps that belongs to the tenant-apps project. The app's spec.source.repoURL points to the tenant's repository so that tenants can create their Applications by themselves.

However, in this system, tenants can create apps whose spec.project is default, so tenants can deploy pods with the admin's privilege.

Proposal

To solve this problem, we developed the admission webhook to validate app.spec.project according to app.spec.source.repoURL. Ref: neco-containers/validate_application.go

This validating webhook is working as expected, but in my opinion, this kind of validation feature should be support in upstream of ArgoCD.

This is the example configuration YAML for the webhook.
In this configuration, App whose spec.source.repoURL is https://github.com/example/tenant-apps.git can be set only tenant or tenant-apps as spec.project.

ArgoCDApplicationValidator:
    rules:
      - repository: https://github.com/example/tenant-apps.git
        projects:
          - tenant
          - tenant-apps

[jkleinlercher]

We plan to do these kind of validations as part of our gitlab pipeline to get rid of a manual merge of the app-of-apps repo by the platform team. There we will also check for some naming rules and so on. Maybe this would also help you in your situation.

[pbecotte]

There are definitely ways to work around it, but it seems silly to allow restricting the resources, namespaces, and clusters that a project can deploy... but allow it to just use a different set of permissions :)

[Woland2k]

This would be a great feature to add, as it will allow multi-tenancy with apps of apps approach.

[HumairAK]

+1 Our case is nearly identical, would love this feature.

[jessesuen]

This use case is intended to be solved by the "global project" feature. However, it currently does not merge allowed repositories.

https://github.com/argoproj/argo-cd/blob/master/docs/user-guide/projects.md#configuring-global-projects-v18

I think we can simply improve global projects to also merge the global allowed repos.