#general
Hey, RBAC question.
We run nested teams and want each team to self-manage its own agents/gateways/skills, with someone leading one team but a plain member in another.
Can't express that today:
*:team-admin is scoped by team membership, not by team_member.role, so leading one team gives the same authority in every team you're in (and their parents).Read-only live mirror of Archestra.AI Slack
👋Join the discussion withAI enthusiasts!Hey, RBAC question.
We run nested teams and want each team to self-manage its own agents/gateways/skills, with someone leading one team but a plain member in another.
Can't express that today:
*:team-admin is scoped by team membership, not by team_member.role, so leading one team gives the same authority in every team you're in (and their parents).4 replies
hey 👋 yes so the goal with #7807 is to greatly improve how we do "scoping" with RBAC.
Today we have these
:team-admin and :admin permissions. The idea here would be RBAC would support scoping in a way to allow you to express things like this (for all resources):<user|team|serviceAccount> can do <resource>:<action> (aka permission) on * (all objects) or <specific object(s)>
does that make sense?
this is how most other RBAC systems tend to work (and imo the proper/most-flexible way)
regarding your question on #5450, we would deprecate and migrate off of
:team-admin and :admin in favour of this new systemAlright yeah that is how i read that pr as well and sounds like a great feature. Any guess on when this would be added?
I'm hoping by the end of September at the latest 🙂