Project-style, AppProject-like RBAC model for Argo Workflows

[danielamar101-pton]

Today, Argo Workflows relies primarily on Kubernetes-native mechanisms (namespaces, RBAC, admission policies, etc.) for multi-tenancy and access control. This works well, but it’s quite different from the higher-level “project” abstraction that Argo CD provides via AppProject resources.

In Argo CD, AppProject gives you a single, declarative place to define:

• Which source repositories are allowed
• Which destination clusters/namespaces are allowed
• Additional constraints (e.g., sync windows)
• Project-scoped roles and permissions, with bindings to groups/JWTs
  This makes it easy to say “team X can only deploy these apps, from these repos, into these destinations” using a first-class, Argo-native abstraction.

For Argo Workflows, there is no directly equivalent concept today. Similar constraints can be achieved, but only by composing:

• Namespaces (per team or per project)
• Kubernetes RBAC on Workflow, WorkflowTemplate, ClusterWorkflowTemplate, etc.
• Admission policies (OPA Gatekeeper, Kyverno, etc.)
• Optionally separate controllers or clusters
  While powerful, this is more infrastructure-heavy and less discoverable for users than a project-style configuration.

I’d like to start a discussion around whether Argo Workflows should support a project-like model, for example:

A first-class “WorkflowProject” (or similar) resource that:

• Groups workflows/workflow templates under a logical project
• Defines allowed repositories, images, artifact repositories, or other external resources
• Optionally constrains allowed namespaces or clusters that workflows can target or affect
• Exposes project-scoped roles/permissions in a way that’s more ergonomic than raw Kubernetes RBAC
• Guidance on how this would coexist with and build on top of Kubernetes RBAC, not replace it
• Whether there are existing patterns or recommended practices in the community that already approximate this and could be standardized

Questions for maintainers and the community:

1. Is there interest in having an AppProject-like, project-scoped permission model for Argo Workflows?
2. Are there design constraints or prior discussions that would strongly favor (or rule out) a first-class “project” abstraction?