https://cerbos.dev logo
Powered by
Title
r

Ryan Killeen

03/01/2023, 10:30 PM
Looking for some guidance around modeling policies for nested resources! There was an excellent answer here some time ago, but it looks like it was swallowed by Slack history. Imagine a resource named 
config
. Config is made up of several different properties, with granularly permissions. Imagine someone might have permission to 
view
or 
edit
all of the config, or may only have the ability to view or edit 
config.branding
, or 
config.someOtherResource
. Currently our principal permissions are attribute-based, eg 
["config:branding:*", "config:view"]
What would be an ideal way to author resource policies without a ton of repetition? Many actions on a single resource 
config
? Separate resource policies for nested parts? Using scopes? Any guidance is appreciated, happy to provide more context and examples.
In short, I can see that having policies like this will be very cumbersome and easy for folks to get wrong over time: 
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  importDerivedRoles:
    - common_roles
  resource: "config:fields"
  rules:
    - actions: ["*"]
      effect: EFFECT_ALLOW
      condition:
        match:
          any:
            of: 
            - expr: ("config:*" in P.attr.permissions)
            - expr: ("config:fields:*" in P.attr.permissions)
c

Charith (Cerbos)

03/02/2023, 10:37 AM
Is this the thread you're referring to? https://community.cerbos.dev/t/2419909/A-quick-question-around-when-to-use-scopes-vs-hierarchal-nam If you're trying to control access to parts of config, I think that probably having a single policy for 
config
and then defining hierarchical actions such as 
config:branding:view
or 
config:branding:edit
might be the easiest way to model it because then you can use wildcards like 
config:branding:*
or 
config:*:view
to define rules for swathes of stuff. There are some guidelines here that you might find helpful as well: https://docs.cerbos.dev/cerbos/latest/policies/best_practices.html
r

Ryan Killeen

03/02/2023, 3:41 PM
@Charith (Cerbos) I had not seen the community portal, very cool! That's the exact post 😅 thank you for your help, and what you say makes sense. Being able to take full advantage of our own attribute wildcards to drive wildcards in Cerbos is definitely a primary goal!
s

sdktr

03/22/2023, 11:33 PM
Double checking here: actions can use wildcards?
c

Charith (Cerbos)

03/23/2023, 3:14 PM
Yes, they can.
5 Views
#helpJoin Slack
Powered by