Partial RBAC in a pack.

[davidan01]

Hi team, I was wondering if there is such feature in the current rbac system and if not, I wanted to see what should be correct workflow to achieve the goal.

Suppose I have a pack. Admin has full access to the pack and observer can only view the pack. There is a role between observer and admin (let's call it the 'contributor'). Contributor has most of the access in the pack but still needs to be restricted from 1 action, which is to delete an app. As an admin, I don't want a contributor to purposefully nor accidentally deletes it but still give the contributor access to the majority of the actions in the pack.

In the current document, I don't see a way to negate access that's already given in a simple manner. Is this possible?

[arm4b]

I didn't use RBAC for a long time and don't remember, but according to the docs https://docs.stackstorm.com/rbac.html#user-permissions

RBAC system uses a whitelist approach which means there is no possibility of conflicting and contradictory permission grants in different roles (e.g. one role granting a particular permission and another role revoking it).

you indeed can't have a "blocklist" of permissions, only "whitelist", as I understand.
So sounds like you want to list all the actions to whitelist, just don't mention the blacklisted action? There might be a lot to list in case when pack has lots of actions, perhaps autogenerating the whitelist would help?

@StackStorm/tsc and @StackStorm/contributors Any ideas from those who use RBAC?

[bishopbm1]

Sorry did not mean to close!

I agree with @armab. You will need to list all the actions with the abilities you want and leave out the action you do not want access to.

We have used RBAC in a few installations and it errors on the side of being very explicit. Which is good if thats what you want but can definitely be cumbersome.

A potentially easier fix that we have done is to move the actions that you want more restricted to a different pack with other restricted actions. You can even use the pack dependancies to include the original pack and check for it during install.

[davidan01]

So, I understand that stackstorm does not have 'blocklist' and that it is hard to give a permission and later take away. I've been doing some trial and errors to find the most feasible way to achieve it but couldn't test out @bishopbm1 's suggestion to have a separate pack of secured actions.

Is there any risks or conflicts in having multiple actions from all different packs to live in a single secret-pack?

@stackstorm/contributors

@bishopbm1 , also, could you tell me more about here? Is it also able to use lib files from the original pack?

You can even use the pack dependancies to include the original pack and check for it during install.

Documentation about it would be great as well! Thanks a lot.

[fdrab]

Hi team, I was wondering if there is such feature in the current rbac system and if not, I wanted to see what should be correct workflow to achieve the goal.

Suppose I have a pack. Admin has full access to the pack and observer can only view the pack. There is a role between observer and admin (let's call it the 'contributor'). Contributor has most of the access in the pack but still needs to be restricted from 1 action, which is to delete an app. As an admin, I don't want a contributor to purposefully nor accidentally deletes it but still give the contributor access to the majority of the actions in the pack.

In the current document, I don't see a way to negate access that's already given in a simple manner. Is this possible?

can't you, instead of giving access to contributors the whole pack, give only access to the specific actions within the pack and leave out the delete action?

[davidan01]

can't you, instead of giving access to contributors the whole pack, give only access to the specific actions within the pack and leave out the delete action?

That would work very well. However, I was concerned of a case where a pack has, for example, 99 accessible actions and 1 restricted action. It would be quite dirty to give same permission to all 99 actions, IMO