Support K8s API RBAC for user/group permissions

[wmgroot]

Summary

Rather than needing to configure RBAC explicitly to allow users and groups to perform actions such as deleting a Pod through the ArgoCD UI, it would be extremely helpful to enable ArgoCD to respect the RBAC permissions already configured for the user for certain actions (resource deletion, pod exec).

Motivation

A feature like this would allow us to use ArgoCD as more than a readonly dashboard, and enable users to perform restarts of their workloads through the ArgoCD UI in addition to using kubectl, without the need to configure additional duplicated RBAC in ArgoCD.

Some users find a UI (like ArgoCD) much more intuitive to work with when learning K8s, and right now we cannot easily grant them write permissions to their resources in the ArgoCD UI.

Proposal

Skooner is an alternative Kubernetes Dashboard that proxies requests through to the K8s API, allowing users to perform actions such as pod deletion or pod exec without any extra RBAC configuration necessary.
https://github.com/skooner-k8s/skooner#oidc

I understand that ArgoCD will still have its own need for it's own authorization scheme for resources that it controls, but we may be able to include a second OIDC integration to support proxying certain actions against the K8s API, with the RBAC configured on the cluster, rather than the RBAC configured in ArgoCD.

[scalen]

Alternative Proposal

Originally discussed in #3593: We could use k8s impersonation to allow ArgoCD to perform k8s-native actions on app-owned resources as if they are the logged in user, assuming that the ArgoCD username and the k8s username match for a given user.

Alternatively, for less volatile configuration, we could map ArgoCD groups to k8s groups, configure your k8s RBAC at the group level, and use --as-group when performing k8s-native actions on app-owned resources.

Supporting the second should be trivial once the first is implemented, so ArgoCD could support both mechanisms. If there is only the developer resource for one, I would personally prefer the group-level implementation 😛

[wmgroot]

I 100% agree with what's being suggested in the issue you linked as well as #7689.
User impersonation (so that we see the correct user instead of the ArgoCD SA in the audit log) is an ideal way to handle this.

[otherguy]

Now that our rollout of ArgoCD is expanding across many different applications on multiple clusters, this would be an essential feature for us.