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:
- `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.
- 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?
Unrelated to ArgoCon but related to ArgoCD:
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:
- `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.
- 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?
[0] https://argo-cd.readthedocs.io/en/stable/operator-manual/app...
[1] https://argo-cd.readthedocs.io/en/stable/operator-manual/rba...