Hi Cerbos team. I have the following configuration in Cerbos:

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)

- 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.

Hey, DENY rules always take precedence when there's a conflict so your rule should work. Are you sure the condition is actually satisfied?

You are right, of course 🙂 I was not handling undefined / missing value correct. Now it works as intended.

Yes, DENY takes precedence

Okay, thank you 👍