Let's introduce an RBAC CRD-based API to manage RBAC-Config

[ggkhrmv]

Summary

The RBAC-Config currently can only be updated using the Kubernetes ConfigMap API.

This makes it very difficult to authorize permissions changes to the individual Casbin-based policies within the file.

Administrators usually receive permission to edit the entire argocd-rbac-cm object, where fine granular edits can not be distinguished by the Kubernetes ConfigMap API.

ArgoCD should provide interfaces for managing its RBAC settings, including write and read functionality.

Motivation

Especially when considering current operation patterns for managing access control: "editing in-line strig CSV via the k8s ConfigMap API" does come with a few limitations:

• Developing automation is hard and would be based on a component outside of ArgoCD itself
• Authorization pattern of current policies can not be extended to be fine granular (fine-grained access control on CSV content not possible)

Especially when using configuration automation tools such as Terraform, Ansible, Pulumi, cdk8s, and Crossplane the current Configmap Interface seems to be a blind spot.

Existing tools that rely on a real API can not be leveraged to administer the Casbin-based CSV for ArgoCD, often resulting in the necessity of manual operations.

After discussing the REST-based RBAC-Service implementation (#16638) with @crenshaw-dev we gained some insights on the design of the service. There are some worries in using a REST-service:

1. It would encourage the users to not use GitOps for managing the RBAC config
2. Not structured enough
3. Not scalable enough
4. Not stable enough

An approach to tackle the worries in REST-based service is introducing a CRD-based RBAC service. It allows config management with GitOps, offers better scaling and structure, as well as API stability. The policy and bindings will be validated prior to runtime. The CRD-based approach would also allow versioning of the API.

Some risks of a new API are:

1. unintuitive API that people could misunderstand and misapply
2. errors in transformation logic
3. to whom is the API exposed?

An RBAC CRD API would be great, as tools like can directly interact with an API and abstract the persistent data (CSV).

Furthermore, this extension would provide a basis for delegated administration, so that management of a subset of permissions could be delegated to respective subjects.

Proposal

The following changes are proposed:

• Extend the ArgoCD CRD API offering to allow management of RBAC
• Extend the current RBAC Implementation with write and delete functionality operating on the existing argocd-rbac-cm ConfigMap.
• Implement new controller and new CRDs

As the Project API also defines roles, it will remain untouched. Only the global policies defined in the argocd-rbac-cm ConfigMap are subject to this change. → Roles, RoleBindings

The REST API won't replace the ConfigMap solution and will be compatible with existing ConfigMaps, making it a non-breaking change.

Related issues: #16050 , #16638

Role

apiVersion: argoproj.io/v1alpha1
kind: Role
metadata:
	name: "org-admin" # subject
	namespace: "default"
spec:
	rules:
	- resource: "applications"
	   verbs: ["get", "create", "update"]
	   objects: ["*/*"]

RoleBinding

apiVersion: argoproj.io/v1alpha1
kind: RoleBinding
metadata:
	name: "org-admin" # subject
	namespace: "default"
spec:
	subjects:
                - kind: "sso" # "sso" or "local" possible
		   name: "user@example.org"
	roleRef:
		kind: Role
		name: "org-admin"

[leoluz]

Administrators usually receive permission to edit the entire argocd-rbac-cm object, where fine granular edits can not be distinguished by the Kubernetes ConfigMap API.

We have an alternative solution (maybe a viable for this use-case) to address rbac granular edits called Policy CSV Composition and is documented here. This way admins can provide independent patches. Was this approach considered? If it was, what were the problems identified with it?

[ggkhrmv]

Administrators usually receive permission to edit the entire argocd-rbac-cm object, where fine granular edits can not be distinguished by the Kubernetes ConfigMap API.

We have an alternative solution (maybe a viable for this use-case) to address rbac granular edits called Policy CSV Composition and is documented here. This way admins can provide independent patches. Was this approach considered? If it was, what were the problems identified with it?

We have considered that approach. We currently use ArgoCD with Crossplane, so the CRD would offer a way to automate the config, which is not given using the Policy CSV Composition. Moreover the suggested CRD would offer an easier, more stable way to config the RBAC with built-in validation before runtime. It would also reduce the risk of people misapplying and misunderstanding the config (e.g. "local user" RBAC), since it would be built similar to k8s' RBAC.

[leoluz]

@ggkhrmv Thank you for confirming. We discussed about this proposal in the Argo Contributor's meeting today. While we are not opposed to having a dedicated CRD/Controller to manage Argo CD RBAC, we agree that this can be implemented in an independent project. We can create a dedicated repository for this controller under the argoproj-labs github org if this is something that you would be willing to implement.

[ggkhrmv]

@leoluz You're welcome! I'd be happy to implement a dedicated CRD/Controller for RBAC-Management

[leoluz]

@ggkhrmv Great! I am closing this issue for now and please ping me directly on CNCF Slack if you want to have a dedicated repo in argoproj-labs to host controller's code.
Thank you!

[sbeginCoveo]

Where can I follow the progress/offer my help?
nvm its right there https://github.com/argoproj-labs/argocd-rbac-operator

[ggkhrmv]

Where can I follow the progress/offer my help? nvm its right there https://github.com/argoproj-labs/argocd-rbac-operator

You can reach out to me on Slack @sbeginCoveo :)