Argo-cd: Locking "App Of Apps" to a single project and namespace

[sadovnikov]

Summary

In AppProject we can limit Applications' possibilities using destinations, clusterResourceWhitelist and namespaceResourceBlacklist. For example, an Application can create any resources, as long as they are created within a particular namespace. However this does not allow creation of new Applications (App of Apps) because only Applications from argocd namespace are being managed.

If we allow creation of Applications in 'argocd`, then other resources can be created there too. Pods and Jobs get access to a very powerful service account of ArgoCD.

Motivation

We'd like to give development teams freedom to manage Applications, however

• they should belong to the same ArgoCD project and
• all applications' resources should be created in the same kubernetes namespace.

Proposal

I would consider

• letting ArgoCD to manage Applications, which are created by other Applications, regardless of their namespaces and
• (optionally) enforcing sub-apps to inherit project from the parent

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[chrisbulgaria]

Yes, this would indeed be an important enhancement for using argocd in a multitenant environment, i.e. giving project teams freedom in their own namespaces (and not always needing to resort to a central function when a new app is created).
Chris

[OmerKahani]

Why limit this to app of apps, and not just enable to create application objects in any namespace?
There might be a verification that the application uses a project that can deploy to the namespace, so we don't have application object in namespace a with project b that sync things to namespace c (project b is not allowed to namespace c)

[davidkarlsen]

This is the biggest weakness of argocd. Why not just stick to normal K8s rbac and control access to application resource - and let that deploy to the namespace it is defined in?

[sadovnikov]

@davidkarlsen, I can see this working if Project becomes like a "subject" in RoleBinding. Regular roles get assigned to projects. Argo could even create a service account for each Project and use that SA to render Applications

[davidkarlsen]

A far easier model would be to let argo act on Applications defined in _any_ namespace, but limit the resource created by the Application to that namespace - then the k8s RBAC would act as normal - limiting where folks can create Application resources.

[davidkarlsen]

Any thoughs on this - this would help a lot on the multi-tenancy.

[storm1kk]

Still relevant, it can help us to reinforce security in the multi-tenancy environments.

[davidkarlsen]

Related: https://github.com/argoproj/argo-cd/issues/3474

[davidkarlsen]

Also see https://blog.kintone.io/entry/production-grade-delivery-workflow-using-argocd#Multi-tenancy which describes the same problem.

[andrewm-aero]

My team has recently started bumping up against this as well. While not a perfect solution (and we must remember not to let the perfect be the enemy of the good), we had the following thought on how to fix this issue:

1. Allow "child" apps (i.e. apps created by apps) in a project to be restricted to a set of projects
2. Allow "child" projects (i.e. projects created by projects, or projects created by apps created by projects) to be limited to a set of permissions, including those set in (1)
3. Allow "child" apps and projects in a project to be restricted to a set of names (either a static list, prefix/suffix, or maybe even a regex)

The basic idea is to guarantee that as you descent the parentage tree of Applications and Projects, that no new privileges are added, only removed.

This would still work with the assumption that all Applications and Projects are in the argocd namespace, but would still have some measure of safety against name collisions between tenants (one could scan for all such top-level restrictions, and calculate if there is possible overlap), as well as allow tenants to freely create apps and even whole sub-projects without providing any access to the underlying cluster not granted by the original project.