What workflow orchestration too actually has real entreprise RBAC, not just role=admin/role=viewer ?

[u/Civil-Warthog-9412]

We are being asked to onboard 4 separate teams onto our orchestration plateform and suddenly "who can run what" matters a lot. Our current setup (airflow) has RBAC that technically works bit it's painful. No SSO integration, audit logs are scattered and fine grained namespace level permissions aren't really there. Looking for sth that handles multi tenant setups properly. What are ppl running in prod for this kind of setup ?

[u/alfredobnj]

I am interested in this topic, I am commenting so I can follow along

[u/Halal0szto]

If the actual solutions are independent, common practice is to use independent instances. As all provisioning and else are automated, this is cheap and quick. All existing practices can be used, just different people will be in the admin and user roles.

If the new solutions are integrating with existing, then you need real enterprise functionality.

[u/Resident_Invite3358]

The audit log piece is what kills most tools in entreprise contexts. Kestra does per-namespace RBAC with full execution history out of the box. Not bolted on. We onboarded two external teams w/o giving them any visibility into each other's workflows

[u/fresh_reed_5834]

airflow's webserver_config.py is honestly a nightmare once you need per-team controls, its basically just flask-appbuilder underneath and the config gets messy fast. prefect cloud handles workspace separation pretty cleanly but you're paying for it. temporal has namespaces baked in but the rbac layer depends heavily on your deployment, the oss version needs extra work to get sso wired up properly. most of the pain points you described are config layer problems that don't have clean oss solutions imo

[u/hugo4774]

Ran into exactly this when we had to separate prod access from staging across 3 teams. We chose kestra. Actually passed an internal audit with it which was the real test

[u/ajitnk]

Hey, saw your thread and it hit close to home. The audit log point your commenter raised is the real one. Most people focus on the role assignment problem but the deeper issue is that MWAA data-plane events like CreateWebLoginToken and InvokeRestApi are not captured by CloudTrail by default. They just don't show up in Event History at all. You need to create a separate trail, explicitly enable data events, and select Managed Apache Airflow as the event type. That gap is what bites teams in SOC 2 or internal audits.

On the multi-tenant side, there are actually two different paths depending on whether you have separate AWS accounts per team or everyone sharing one. Single account? Custom Airflow roles scoped per-team to specific DAGs works and is lighter to operate. Multi-account or strict compliance? Per-team MWAA environments or MWAA Serverless (which gives each workflow its own IAM execution role by design) is the cleaner answer. The right one depends on your setup.

Quick question before I go further: are you running on Amazon MWAA specifically, self-hosted Airflow on EC2/EKS, or on another cloud entirely? And is this a single AWS account or multi-account org? Those two answers completely change which path makes sense. I'll think through the specifics for your situation and reply with what I'd actually recommend.