Support wildcards in RBAC plugin casbin rule evaluation

[rgolangh]

What do you want to improve?

The definition and evaluation of RBAC rules

What is the current behavior?

Currently there is no way for plugins to create a rule that can automatically address objects by wildcars. The orchestrator plugin is using this role definition and it allow or deny a specific action for all the workflows object:

p, role:default/workflowAdmin, orchestrator.workflow.execute, use, allow

What will the new behavior be?

We would like to change the rule to deny a specific workflow ID but allowing all (or vice-versa) Here is how we can workaround that today:

p, role:default/workflowAdmin, orchestrator.workflow.execute, use, allow
p, role:default/workflowAdmin, orchestrator.workflow.ABC, use, deny

And for that to work we need to implement the wildcard behaviour in our plugin because those are 2 different objects, while with wildcards it can be:

p, role:default/workflowAdmin, orchestrator.workflow.*, use, allow
p, role:default/workflowAdmin, orchestrator.workflow.ABC, use, deny

and the permission check is with a single object orchestrator.workflow.XYZ (XYZ is a different workflow ID for that matter and should result an allow)

There is another scenario where the wildcards can be added to the subject section and with that capture a role in a way which is not only by using groups, but this is not my main interest, but was posted on #1994

I think this is doable with casbin https://casbin.org/docs/rbac-with-pattern#use-pattern-matching-in-rbac

[pkliczewski]

fyi @AndrienkoAleksandr @PatAKnight

[rgolangh]

What I am looking here is patterns on the policy and not the role definition, and I am not sure this is supported. Perhaps RBAC with patterns will not help here.

[rgolangh]

I took the model and worked with this casbin online editor and used the regexMatch function to match object on a request and I was able to get the behaviour I wanted.

So given this policy:

p, role:default/workflowAdmin, orchestrator.workflows, read, allow

p, role:default/workflowViewer, orchestrator.workflows, read, allow
p, role:default/workflowViewer, orchestrator.workflows.infra, read, deny

g, user:default/guest, role:default/workflowViewer
g, user:development/admin, role:default/workflowAdmin

This requests for the admin user are allowed:

user:development/admin, orchestrator.workflows.foo, read
user:development/admin, orchestrator.workflows.infra, read

This is allowed for guest

user:default/guest, orchestrator.workflows.foo, read

And this is denied

user:default/guest, orchestrator.workflows.infra, read

The concern here is how will this play with current policies with the behaviour changed from exact match to regex match.

[masayag]

@rgolangh can you explain why the guest user is allowed to read the foo workflow:

user:default/guest, orchestrator.workflows.foo, read

Shouldn't p, role:default/workflowViewer, orchestrator.workflows, read, deny deny all of the workflows for the guest? or should it be allow instead of deny so all workflows are allowed except of those that are explicitly denied?

[rgolangh]

@rgolangh can you explain why the guest user is allowed to read the foo workflow:

user:default/guest, orchestrator.workflows.foo, read

Shouldn't p, role:default/workflowViewer, orchestrator.workflows, read, deny deny all of the workflows for the guest? or should it be allow instead of deny so all workflows are allowed except of those that are explicitly denied?

that is a typo and should be 'allow' fixed it, thanks for asking