Another question I've been mulling over, around custom permissions: Right now we enable tenants to heavily customize roles and permissions. Trying to model this the Cerbos way, I believe that custom "roles" are a user-facing label around sets of attributes that we can then derive roles from in Cerbos policies, rather than trying to make Cerbos custom-role aware or updating policies. Does that sound like the right approach? If there's any exceptions or gotcha or "you might want to update policies if" type thoughts, would love to hear them! (So much for not having questions 😄 )

Yes for anything that is ‘dynamic’ and set by end users passing these in as attributes on the principal and then using derived roles to reference them in resource policies is the cleanest approach. The derived roles give you a level of indirection where the logic can be defined once for mapping these principal attributes in a single place to then be consumed across policies.

What we'd love to do is have a single source of truth for those attributes. Am I right in assuming that our best bet is to generate JSON Schema from our code to be used in Cerbos?

If you can generate that schema then you’re in a great position as you pull those into your policies and turn on schema enforcement

We'll definitely need to work in that direction, but we can start there with new attributes as we try to support legacy ones!