Let ArgoCD provide an API to update RBAC Config policy.csv.

[fish0373]

Summary

Let ArgoCD provide an API to update policy.csv.

Motivation

I have multiple ArgoCD services in different k8s Clusters. I need to integrate these RBAC permissions into my own server, but currently I cannot update policy.csv through the API. It can only use k8s patch ConfigMap to update policy.csv.

Proposal

• now When ConfigMap been patched than update permision.
• add the update policy.csv API When call the new one API to update RBAC permission, and than update content to ConfigMap too.

[abacus3]

I am facing the same challenge. Especially when using configuration management tools such as https://github.com/crossplane-contrib/provider-argocd, https://registry.terraform.io/providers/oboukili/argocd/latest/docs, https://registry.terraform.io/providers/mediwareinc/argocd/latest/docs the logic for managing the underlying CSV based ConfigMap interface is missing. This results in a semi-automated configuration management approach, where AuthN/AuthZ is configured manually in the policy.csv ConfigMap and the rest can be pretty much managed via API. Other than the lack of structured configuration mechanisms the policy.csv does come with a few crucial limitations: scalability (we are limited to configmap size limits), validation/correctness (we can not validate the ConfigMap's content).

I am willing to write a proposal and provide implementation of a non-breaking extension: the Argo CD RBAC REST Service, which should allow the configuration of all relevant configuration measures that the policy.csv implements.

We could introduce multiple ConfigMaps to workaround the single ConfigMap/etcd size constraint and have them managed via the new RBAC Service.

[gnunn1]

We could introduce multiple ConfigMaps to workaround the single ConfigMap/etcd size constraint and have them managed via the new RBAC Service.

I split my roles between the argocd-rbac-cm and the projects, basically global roles go into the argocd-rbac-cm and team specific roles go into the team specific project (AppProject). I find when using this approach the number of global roles is quite small and changes pretty infrequently. Would this approach work in your use case?

[abacus3]

We could introduce multiple ConfigMaps to workaround the single ConfigMap/etcd size constraint and have them managed via the new RBAC Service.

I split my roles between the argocd-rbac-cm and the projects, basically global roles go into the argocd-rbac-cm and team specific roles go into the team specific project (AppProject). I find when using this approach the number of global roles is quite small and changes pretty infrequently. Would this approach work in your use case?

In fact it would solve the size limit issue partially in sime cases. Nevertheless, we do face two major challenges, where this limits us from further automating:

• Multi-Tenant Argo installations where multiple teams get onboarded onto it automatically, this will require dynamic changes to the argocd-rbac-cm
• Single-Tenant installation of new individual Argo CD instances which require an initial setup of dynamic roles/policies

In these cases we need to build an additional tool that allows the structured management of entries in the CSV. This tool would act as an adapter for the very weak structured CSV and expose a stable API to manage RBAC resources following a REST fashioned pattern.

Overall, the CSV based interface makes it super hard to manage access in a fully autmated fashion with a lot of users/groups.

We do seek for a stronger API integration of the RBAC settings in Argo CD core, instead of implementing the management logic into one of the automation tools mentioned earlier.