If we have resources that all have similar rules for authorization, should I just create a single Resource Policy that can apply to all resources of that type? or is it better to have a Resource Policy per resource instance (id)?

Hey! Resources policies are designed to have a single policy for each

kind

of resource in your system rather than each instance/id

thanks. does this also apply to Principal Policies?

Principal policies are a bit of an exception for a rule - designed for the use case when a specific principal ID needs special access (eg auditor, SRE etc) - this policy then overrides all other policies when the principal ID matches. In most systems there are very few (mostly none) of these.

ok so should we try to stay away from Principal Policies if it can be solved more generally with a Resource Policy?

Yes that is recommended

yes, i'm on it now 🙂 thanks.

Hey, you can have resource policies per instance if that's what you really want. We generally recommend writing policies for a whole class of resources (the resource

kind

) because that keeps things tidy and reduces the number of policies you have to deal with. If you want your tenants to create policies, the best way to do that would be through scoped policies.

thanks @Charith (Cerbos). so what we need to do is to provide authorization to API Clients (as in OAuth2 clients). These clients would be our Principals. And we need to have our customers be able to customize the authorization policies for each client. Not sure how you would solve this with scoped policies but I was thinking that we would instead use Principal Policies -- one for each API Client.

Ah I see. I suppose you could use the client ID as the scope name if you want to use scoped policies. However, principal policies sound like the better choice here.