ArgoCon – Vendor-neutral Argo-focused Event

It seems there's an expectation that ordinary ArgoCD users don't have (write) permissions to the cluster, and handling permissions is delegated to the checks you have on your git repos.

It does feel like a shortcut that limits the situations where ArgoCD can be used, but I can see how this could have been justified during the design process.

- `Application` is a special CRD. You can define one application to control namespaced resources in more than one namespace, cluster-wide resources, or even resources in another cluster if the controller have access to that cluster. So how to implement secure access to applications is a difficult organization/management problem (and not necessarily a technical problem).

- I don't know why the project decided to implement its own RBAC, but I like that I can give some users limited visibility in some clusters without implementing k8s native RBAC for them. From a pure GitOps perspective, I treat it as an anti-feature because it enables a lot of imperative operations via its own API, bypassing git. But not all organizations are so comfortable to be 100% gitops, I think it's an acceptable middle ground. And I think you can deploy ArgoCD with reduced permission just fine. I heard some folks do that, although there might be some gotchas.

If it's up to me, I would completely lock down its own API's access and just do everything from git, leaving the UI as read-only for informational purposes.

I think in the early days Argo was more intended to be interacted with via the UI, they put quite a bit of work into ACLs between their Projects, Applications, Clusters, and Repositories which would let a team pretty easily self-manage their environment. I don't think it was as common as today, with the app-of-apps pattern, to use Argo itself to manage Argo; so while the applications themselves were a gitops workflow, the bootstrap into that workflow was UI-based.

My favorite install method is per-cluster, run as something that might fit better in kube-system, we use the UI primarily for status info with a few users having permissions to run actions like restart and delete. With autohealing, deleting resources is often a great way to get things "unstuck".

Every other interaction with the cluster is via our gitops repo. We bootstrap a pretty vanilla argo install and then basically `kubectl apply -f clusters/primary/appofapps.yaml`. Included is an Application that takes ownership of the argo install and manages its configuration from the repo as well.

The Argo configuration basically has one cluster(local), one repo, and one project(default), so we don't really use Argo's ACL system much at all as all config happens through our standard PR approval workflow.

Its config is pretty flexible though, it's based on kustomize, so it's fairly easy to tailor it as you see fit. It doesn't need full access to the cluster and in fact even supports a namespaced install that has no cluster access at all (often running many instances on a control cluster with k8s ACLs giving users access to their own).

Ultimately, I think what you're seeing are some growing pains, but primarily features that make Argo flexible enough to target multiple types of control, ACL, repo, and cluster topologies. Them adding the ability to put Applications in other namespaces feels like a continuation down that path, just adding one more option (which I think will be pretty popular, like you mentioned, in multitenant situations).