Hey all, playing around with Cerbos, very impresse...
# community
Hey all, playing around with Cerbos, very impressed so far and trying to prototype a few things 🙂 Is there a way to express that any principal with a particular role can take an action on all resources?
Hi @Matthew Ebeweber, currently you can only define actions per resource type in that resource’s policy. You can always add the following statement to each resource, (assuming the role is called
Copy code
    # If the principal`s role is `admin` then all the actions are allowed.
    - actions: ["*"]
      effect: EFFECT_ALLOW
        - ADMIN
Can you please tell us little more about your requirement? What becomes easier for you when you have a blanket allow on everything?
To give you an idea of the shape. Similar to the above, I’ve got a couple roles (system level) that I want to be able take a couple of actions on a number of resources. I wanted to avoid having these duplicated across multiple resource definitions for reasons like maintenance.
Thanks for the clarification.
It's a good point about avoiding repetition for maintenance reasons. Currently we don't have a native solution for it. You could potentially use templating to achieve it, but, I realise that it's an additional pre-processing step that you might prefer not to do. We have tried to avoid a lot of magic in the policies with the assumption that policies are read a lot more than they are edited. Being able to read a single policy file and figure out everybody that has access to that resource is quite powerful. It also acts as a natural barrier to accidentally giving people more access than necessary because every new resource starts off being off limits to everybody until you define the access rules for it.
Tenplating is something I explored here. Specifically, creating a simple scoped hierarchy with ”system” at the top. Then manually written policies can be written with the scope “system.xxx”. I wrote a quick bash script that takes a template and a list of resources and spits out the policies under ”policies/generated”.
I think the preprocessing step / maintenance can be softened with some commit hooks/simple checks to make sure things stay consistent
Certainly! There are also lots of YAML templating solutions available thanks to Kubernetes. Something like ytt could probably be used as well.
I’ll give this a look, thanks!