Unrelated to ArgoCon but related to ArgoCD:<p>I’ve been working on implementing ArgoCD and I am surprised by some design choices, so I wonder if someone could shed some light as to why they were made:<p>- `Application` resources can only be created in the `argocd` namespace (argocd >=2.5 tries to address this, but it is not a stable feature[0] and has bugs). This is surprising since in Kubernetes resources are generally Namespaced, or, offered in 2 flavors: `ClusterResource` and `Resource`. This is a problem on multi-tenant clusters where you do not want users to have any permissions to the `argocd` namespaces. I would have expected ArgoCD to offer `Application` and `ClusterApplication` resources.<p>- The ArgoCD controller has full admin access to the cluster, and authorization is implemented directly by ArgoCD with its own RBAC system[1]: why didn’t ArgoCD rely on the native Kubernetes RBAC system instead?<p>[0] <a href="https://argo-cd.readthedocs.io/en/stable/operator-manual/app-any-namespace/" rel="nofollow noreferrer">https://argo-cd.readthedocs.io/en/stable/operator-manual/app...</a><p>[1] <a href="https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/" rel="nofollow noreferrer">https://argo-cd.readthedocs.io/en/stable/operator-manual/rba...</a>