Self-service RBAC management UI for multi-team Argo CD (looking for feedback)

[M4ry4mR]

I'd like to build a small open-source panel that lets a platform super admin delegate Argo CD access management to team leads. Team leads could then create roles and assign users to them for their own applications through a UI, without needing admin access to Argo CD, Keycloak (or another IdP), or the Git repo.

This is not implemented yet. I'm posting the idea first to check whether it fits the project's direction and to learn about pitfalls before writing code.

Problem

In a multi-team cluster, giving someone access to specific applications today means:

1. Editing argocd-rbac-cm / AppProject roles (YAML, via PR or kubectl).
2. Adding the user to the right group in the identity provider (e.g. Keycloak).

Both steps usually need a platform admin, so admins become a bottleneck. Team leads know who in their team needs access to what, but they can't act on it. Giving them admin rights is too much; giving them nothing leads to a ticket queue.

What exists today

• Project roles plus SSO group mapping already provide the delegation model. The EKS docs even describe a pattern where team leads assign team members to project roles.
• What's missing is a way to operate that model without hand-editing YAML. Related requests I found: an API to update policy.csv (Let ArgoCD provide an API to update RBAC Config policy.csv. #16050) and better visibility of assigned roles in the UI.
• Keycloak's fine-grained admin permissions (v2) can scope group membership management to specific groups, which fits the identity side.

I couldn't find an existing tool that combines all of this (super admin, delegated team leads, name/pattern-based access, IdP and GitOps in one flow). If I missed one, please point me to it.

Proposed design

Actors

• Super admin: sees everything and grants each team lead a scope (projects and/or application name patterns, plus allowed actions).
• Team lead: has full access inside their scope. They can create roles and assign users within it.
• User: receives roles; never touches the panel or the IdP.

Flow 1: create role

1. The team lead enters a role name, then selects the applications the role can access (by exact name or pattern).
2. The panel checks that the requested access is a subset of the lead's scope (enforced in the backend, not only in the UI).
3. The panel creates a matching group in the IdP and writes the Argo CD policy mapping that group to the role.

Flow 2: assign user

• If Argo CD is integrated with Keycloak, the panel looks up the user in Keycloak and adds them to the role's group. If the user doesn't exist, the panel reports that.
• For local (non-SSO) users, the panel searches by username and assigns the role. If the user doesn't exist, it must be created first.
• The user never needs access to Keycloak.

GitOps compatibility

• Git is the source of truth for RBAC policy. After a role is defined, the panel pushes the change to Git using a dedicated bot credential (not the team lead's), either as a direct commit or as a PR, configurable.
• Policy is stored in separate files and applied through a dedicated policy.<name>.csv key, so the panel never edits the main policy.csv or writes to the cluster directly.
• Keycloak is the source of truth for group membership. The panel's own database holds only audit data.

Security principles

• "You can't grant more than you have", enforced server-side.
• The panel's IdP service account can manage only groups the panel created (marked with an attribute), with no realm-admin rights.
• The panel's Git credential is limited to the RBAC path of one repository, and all changes are validated before commit (format, scope, no wildcards beyond the lead's scope).
• Full audit log: who changed what, for whom, and when.

Diagrams

Architecture

flowchart LR
    SA([Super Admin]) -->|grants scope| P
    TL([Team Lead]) -->|creates roles / assigns users| P

    subgraph P[RBAC Panel]
        UI[Web UI] --> API[Backend API]
        API --> V[Scope & permission check]
    end

    V -->|create group, manage membership| KC[(Keycloak)]
    V -->|commit / PR with policy| G[(Git repo)]
    G -->|sync| A[Argo CD]
    KC -->|OIDC groups claim| A
    U([User]) -->|login via SSO| A

Loading

Create role and assign user

sequenceDiagram
    actor TL as Team Lead
    participant P as RBAC Panel
    participant KC as Keycloak
    participant G as Git
    participant A as Argo CD

    Note over TL,A: 1. Create role
    TL->>P: Role name + app access (project/app patterns)
    P->>P: Validate: within team lead's scope?
    P->>KC: Create group for the role
    P->>G: Commit / PR: policy for role -> group
    G-->>A: Sync (RBAC policy applied)

    Note over TL,A: 2. Assign user
    TL->>P: Select user + role
    alt Argo CD uses Keycloak (SSO)
        P->>KC: Search user
        P->>KC: Add user to the role's group
    else Local user
        P->>P: Search by username (must already exist)
    end
    P->>P: Write audit log
    Note over A: User gets access on next login

Loading

Out of scope for the first version

• Creating local users or Keycloak users from the panel.
• Regex-based matching (glob patterns first).
• Identity providers other than Keycloak (the design should stay OIDC-agnostic).

Questions for the maintainers and community

1. Is a standalone tool the right home for this (e.g. integrated through proxy extensions), or is there any appetite for part of it in core?
2. Is there a recommended way to manage RBAC programmatically other than writing the ConfigMap or Git? Would an API like the one requested in Let ArgoCD provide an API to update RBAC Config policy.csv. #16050 be considered?
3. Any concerns about a tool owning a dedicated policy.<name>.csv key?
4. Does anyone already run something similar internally, or would you use this? What would you expect from it?

Status

Idea and design stage; no code yet. Planned as an open-source project written in Go, with a small MVP (create role + assign user for Keycloak-backed setups) tested in a real multi-team cluster first. Feedback, especially on security and GitOps concerns, is very welcome.