Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support wildcards in RBAC plugin casbin rule evaluation #2025

Open
rgolangh opened this issue Aug 7, 2024 · 5 comments
Open

Support wildcards in RBAC plugin casbin rule evaluation #2025

rgolangh opened this issue Aug 7, 2024 · 5 comments
Assignees
@rgolangh
Labels
jira kind/enhancement New feature or request status/triage

Comments

@rgolangh
Copy link
Contributor

rgolangh commented Aug 7, 2024 •
edited
Loading

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
@rgolangh rgolangh added kind/enhancement New feature or request status/triage labels Aug 7, 2024
@github-actions github-actions bot added the jira label Aug 7, 2024
@pkliczewski
Copy link

fyi @AndrienkoAleksandr @PatAKnight

@rgolangh
Copy link
Contributor Author

rgolangh commented Aug 7, 2024

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.

@dasari008 dasari008 mentioned this issue Aug 8, 2024
Open
@rgolangh
Copy link
Contributor Author

rgolangh commented Sep 11, 2024 •
edited
Loading

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.

rgolangh added a commit that referenced this issue Sep 13, 2024
@rgolangh
WIP: feat(rbac): pattern on rbac policy objects
be28c73 
Motivation:
There is no way to capture multiple objects in a single policy today and
match against it. The outcome is that policies for basic permission,
where the object are not catalog entities, are not fine grained. Either
you have permission on an action on all the category, or not.
For example the workflows that the orchestrator plugins exposes are not
a catalog entity. They only have a workflow ID the plugins exposes and
there is no way today to deny or allow some of the workflows usage.
It has today this permission:

    orchestrator.workflow.read, read, allow

Modification:
The only modification for the rbac plugin is to use a regexp match:

    [matchers]
    m = g(r.sub, p.sub) && regexMatch(r.obj, p.obj) && r.act == p.act

Result:
With this change we have the permission be matched by a regexp:

    orchestrator.workflow ,       read, allow  // catches all workflow
    orchestrator.workflow.banned ,read, deny   // catches banned workflow

Resolves: #2025

Signed-off-by: Roy Golan <[email protected]>
@rgolangh rgolangh mentioned this issue Sep 13, 2024
Closed
@rgolangh rgolangh self-assigned this Sep 13, 2024
rgolangh added a commit that referenced this issue Sep 13, 2024
@rgolangh
WIP: feat(rbac): pattern on rbac policy objects
8da2e76 
Motivation:
There is no way to capture multiple objects in a single policy today and
match against it. The outcome is that policies for basic permission,
where the object are not catalog entities, are not fine grained. Either
you have permission on an action on all the category, or not.
For example the workflows that the orchestrator plugins exposes are not
a catalog entity. They only have a workflow ID the plugins exposes and
there is no way today to deny or allow some of the workflows usage.
It has today this permission:

    orchestrator.workflow.read, read, allow

Modification:
The only modification for the rbac plugin is to use a regexp match:

    [matchers]
    m = g(r.sub, p.sub) && regexMatch(r.obj, p.obj) && r.act == p.act

Result:
With this change we have the permission be matched by a regexp:

    orchestrator.workflow ,       read, allow  // catches all workflow
    orchestrator.workflow.banned ,read, deny   // catches banned workflow

Resolves: #2025

Signed-off-by: Roy Golan <[email protected]>
rgolangh added a commit that referenced this issue Sep 13, 2024
@rgolangh
WIP: feat(rbac): pattern on rbac policy objects
5289c2a 
Motivation:
There is no way to capture multiple objects in a single policy today and
match against it. The outcome is that policies for basic permission,
where the objects are not catalog entities, are not fine grained. Either
you have permission on an action on all the category, or not at all.
For example the workflows that the orchestrator plugin exposes are not
a catalog entity. They only have a workflow ID the plugin exposes and
there is no way today to deny or allow some of the workflows usage.
It has today this permission:

    orchestrator.workflow.read, read, allow

Modification:
The only modification for the rbac plugin is to use a regexp match:

    [matchers]
    m = g(r.sub, p.sub) && regexMatch(r.obj, p.obj) && r.act == p.act

Result:
With this change we have the permission be matched by a regexp:

    orchestrator.workflow ,       read, allow  // catches all workflow
    orchestrator.workflow.banned ,read, deny   // catches banned workflow

Resolves: #2025

Signed-off-by: Roy Golan <[email protected]>
rgolangh added a commit that referenced this issue Sep 13, 2024
@rgolangh
WIP: feat(rbac): pattern on rbac policy objects
ef8056c 
Motivation:
There is no way to capture multiple objects in a single policy today and
match against it. The outcome is that policies for basic permission,
where the objects are not catalog entities, are not fine grained. Either
you have permission on an action on all the category, or not at all.
For example the workflows that the orchestrator plugin exposes are not
a catalog entity. They only have a workflow ID the plugin exposes and
there is no way today to deny or allow some of the workflows usage.

I.e, this is the permission a workflow have for read:

    orchestrator.workflow.read, read, allow

Modification:
The only modification for the rbac plugin is to use a regexp match:

    [matchers]
    m = g(r.sub, p.sub) && regexMatch(r.obj, p.obj) && r.act == p.act

Result:
With this change we have the permission be matched by a regexp:

    orchestrator.workflow ,       read, allow  // catches all workflow
    orchestrator.workflow.banned ,read, deny   // catches 'banned' workflow id

Resolves: #2025

Signed-off-by: Roy Golan <[email protected]>
@masayag
Copy link
Contributor

masayag commented Sep 15, 2024 •
edited
Loading

@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
Copy link
Contributor Author

rgolangh commented Sep 15, 2024 •
edited
Loading

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rgolangh rgolangh

Labels
jira kind/enhancement New feature or request status/triage
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

feat(rbac): patterns on rbac policy objects janus-idp/backstage-plugins
3 participants
@masayag @pkliczewski @rgolangh