Implement teams/organization concepts

[minsis]

Now that RBAC is released into 3.4 there should be a good way to be able to separate out specials actions, workflows, and rules to that team/org. This gives greater granularity for access control and separates team members from accessing other team member's rules.

Right now the only work around I can think of is to create a dummy pack or some kind that would belong to role(s), which I haven't really tested. While this is probably doable, its doesn't seem like a very clean way of doing it.

[blag]

Can you explain a bit more what you mean? What do you mean by "special actions, workflows, and rules"?

One thing I would like to see is integrating the list and view permission types. For example, let's say I give somebody permission to list rules and to read ruleA and ruleC. Right now, when they list rules, they see:

• ruleA
• ruleB
• ruleC

and when they go to view ruleA and ruleC everything works fine. But when they go to read ruleB, they get a permission error.

This can be extremely frustrating for users when they see an action that they might want to use in the action list, but can't view the action for details. This might be better modeled with ACLs than with RBAC?

[minsis]

So I think we're on similar a page here, but I'm aiming for broader way of separating resources from users while not allowing any cross contamination within those resources. And apologies in advance as I'm sometimes bad at trying to explain things in text.

Following your example we have have userA and userB.

To give userA permissions to manage ruleA and ruleC you would need to do something like:

resource_uid: "rule:somePack:ruleA"
resource_uid: "rule:somePack:ruleC"

And for userB:

resource_uid: "rule:somePack:ruleA"
resource_uid: "rule:somePack:ruleB"

The issues:

• I have to have the rule known before hand so I can even give any permissions out. So if userA creates a new ruleD but also wants to share this with userB some admin needs to intervene in order to make this happen.
• You can't just give access to somePack as that would now allow both userA and userB to access any rule in that pack
• RBAC creates roles for permissions but is assigned at the user level

The idea here is that you would create teams/orgs and assign people to those orgs. Then as userA creates a rule either CLI or UI and there's now another attribute here to assign it to a team/org. This would still allow both users to access somePack and create rules inside that pack but be able to separate who can use/view/etc each of the rules since they will be assigned to a team.

So your rule here would be something like:

---
name: "ruleC"
pack: "somePack"
enabled: true
team: "teamA"

Then your RBAC role would be assigned to a team instead of an induvial user. This also still allows you to use groups inside the role as well for things like LDAP management at the same time.

In all of this the only work around I can think of is creating two dummy packs dpackA and dpackB then the rules that get created would be then added to their respective pack pack:dpackA. This could be a good option, but the issue comes in the form of managing it all for things like HA. If you want to create a new "team" (aka packC) you would then need to make sure all your HA clusters are in sync with this.

Maybe another simpler way of doing this might be to do wildcards that would allow you to have some kind namespace that you would announce to your org. So you would end up with something like rule:somePack:teamA_*. But this could end up being confusing or messy in the long run.

I'm not sure how familiar you are with Ansible AWX/Tower, but my thought process is along those lines, but something simpler for StackStorm.

[stale[bot]]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically marking is as stale. If this issue is not relevant or applicable anymore (problem has been fixed in a new version or similar), please close the issue or let us know so we can close it. On the contrary, if the issue is still relevant, there is nothing you need to do, but if you have any additional details or context which would help us when working on this issue, please include it as a comment to this issue.