This next question is completely unrelated to question above. We're using scoped policies for multi-tenancy. I'm still not sure the best way to handle "default" policy rules. Let's imagine we take the approach that most people would likely take: default scope -> define default rules tenant scope -> define tenant specific rules Sticking with the JIRA analogy from the previous ticket. We might have a resource "ticket" and define some default rules, e.g. role "USER" can "update" a JIRA ticket if they belong to the project. A tenant might not want to inherit the default rules. But the only way they can do that is to create a tenant scoped resource policy that's exhaustive (e.g. it does EFFECT_ALLOW or EFFECT_DENY on all possible scenarios). It seems it would be more powerful and less dangerous if in combination with lenientScopeSearch, a tenant can optionally define a policy and choose to halt evaluating parent scopes.

resourcePolicy:
  version: default
  resource: ticket
  scope: tenantA
  evaluateParentScope: false  # defaults to true

Or conditionally:

resourcePolicy:
  version: default
  resource: ticket
  scope: tenantA
  evaluateParentScope:
    condition:
      match:
        expr: R.attr.someAttr in P.attr.someAttrs

I haven't really thought it through 100% and I'm not sure if scoped Principal policies matter. Just throwing this out there! 🙂

That's an interesting idea. We've approached it from the point of view that he default scope defines the base set of rules that apply to the entire system. Scopes are just exceptions to those rules and ideally there aren't that many of those. If you want the tenants to have their own custom policies that are not "inherited", then it's probably better to be explicit about that and use a different set of policies for each tenant . You can use the

version

of the policy as a tenant identifier in that case.

I think the problem with using the

version

is we need to know ahead of time at the call site (app) if they've decided to ignore the default set of rules for a specific resource.

I see. So I take it that the default policy is more permissive than you want? Otherwise, accidentally or intentionally falling back to the default policy shouldn't be a problem because most things would be denied anyway.

Yeah. For example, we may in our base policy say "JUNIOR_ASSOCIATE" can update this JIRA ticket when status is OPEN. But the client may only want a SENIOR_ASSOCIATE to update.

I see. Even if that feature existed, you still have to be aware of these special cases from the outset, don't you? So, maybe one way to solve this is to introduce a dummy scope in the middle that denies everything? You'd give the tenant a scope like

deny_all.foo

and make sure that the policy for

deny_all

scope has a wildcard rule that denies everything.

That sounds like a good option 👍 Thanks. I'm really trying to drill into this because I'm presenting Cerbos internally to two different groups today (one technical and one semi-technical). And these specific questions have already come up. "How does a tenant use the default resource policy". "How can a tenant override the default policy". And it's the latter that will be difficult to explain. But I think your suggestion works. We would just need to be consistent across all resources. Thanks!

Yeah, that would work too. If most of your tenants seem to require custom policies, you can always go back to the other method. (It would be a bit painful but can probably be automated.)