https://cerbos.dev logo
#help
Title
# help
d

David Nilsdotter

06/15/2023, 12:45 PM
Hi Cerbos team. I have the following configuration in Cerbos:
Copy code
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: default
  resource: feature
  scope: A
  importDerivedRoles:
    - derived_roles
  rules:
    - actions:
        - feature:**
      effect: EFFECT_ALLOW
      derivedRoles:
        - ADMIN
        - USER
In the default scope I setup all effects to DENY, to switch them on for the child scopes. This scope,
A
currently has access to all features if you are associated with the project. But now we have a single feature that we would like to disable based on condition (something like this)
Copy code
- actions:
        - feature:viewer:toolbar:design
      effect: EFFECT_DENY
      derivedRoles:
        - ADMIN
        - USER
      condition:
        match:
          expr: P.attr.projects.filter(t, t.id == R.attr.projectId).all(t, t.hasDesignSeat == false)
But that generates contradicting rules, and it returns ALLOW for the action
feature:viewer:toolbar:design
I understand where it comes from, but how do I a address this? I see two options, both with the same issue. Either I define all of the actions instead of using wildcards except
feature:viewer:toolbar:design
for the standard case, which would make the ALLOW list quite large. Or I swap the default scope to ALLOW instead of DENY, which would allow me to just DENY
feature:viewer:toolbar:design
in this scope (and the rest is allowed in the default scope. But that introduces the issues in the other scopes, where I would need to block all the action not allowed there, which also ends up being quite a lot of action lists. And logically, (in our case at least) it is easier to grasp the access scope when listing allowed actions instead of the blocked. Is there a way to prioritize actions? One suggestion would be to make more specific actions trump loosely defined actions (
a:b:c
>
a:b:*
), within the same scope, if that could be possible.
c

Charith (Cerbos)

06/15/2023, 12:59 PM
Hey, DENY rules always take precedence when there's a conflict so your rule should work. Are you sure the condition is actually satisfied?
d

David Nilsdotter

06/15/2023, 1:15 PM
You are right, of course 🙂 I was not handling undefined / missing value correct. Now it works as intended.
But, in the opposite case, where I block all but one action, it would still be DENY?
c

Charith (Cerbos)

06/15/2023, 1:16 PM
Yes, DENY takes precedence
d

David Nilsdotter

06/15/2023, 1:17 PM
Okay, thank you 👍
4 Views