hi cerbos team i have a question regarding modelling our pol Cerbos Community #help

hi cerbos team, i have a question regarding model...

Theisz Eduard

03/17/2026, 1:45 PM

hi cerbos team, i have a question regarding modelling our policies. We started with a strict list of actions that were allowed for each entity, (the classic CRUD plus some extra ones that we thought would come handy). And it was working fine, each resource always had the same actions and we were able to map those actions both on the UI as well as in the backend. Now we are adding some commands on each resource that were not planned from the beginning and I found 2 ways of doing this. 1. We keep the list of actions locked just like before, but each command will now be modelled as a resource with Actions like Read and Execute. Towards the ui we can create a Tree of permissions now with the resource and its allowed actions and then for each such command. 2. We allow the list of actions to grow, each command being then an action on the resource. Are there any pitfalls that you guys might have encountered following one or the other solution?

Andrew Haines (Cerbos)

03/17/2026, 4:43 PM

Hi 👋🏼 I think either way is a reasonable approach. One advantage of modelling the commands as actions, though, is that actions can have a

delimiter, so you could have

some_command:read

and

some_command:execute

(or

read:some_command

etc depending on your preference 🙂). You can then author policies using wildcards (which respect the delimiter), so a resource policy rule with

*:read

could grant read access to any command on that resource.

Theisz Eduard

03/18/2026, 9:31 AM

amazing, so in the end I could have the basic CRUD actions and the commands as read / execute using the delimeter

Theisz Eduard

03/18/2026, 4:02 PM

following question on this regarding modelling our policies: Lets say we have an aggregate root that would allow or deny access based on some internal state. Example:

Copy code

Workflow
└── CreatorId
└── Task[]

Task
└── PerformerType
└── PerformerId

PerformerType(enum)
ROLE, INDIVIDUAL

So lets say we only have read and execute actions: We can create derived roles for both the owner of the workflow as well as a derived role for the performer of the task. now: If I am a performer of such a task i also want to have read rights on the Workflow. (pretty easy to build as Workflow could send a list to cerbos with all the available tasks) If I am an owner of a workflow, I want to have read rights on the Tasks. (I guess this is where my question comes in 😄) If I have 2 different resource policy files I dont have the context from workflow_policy, only if I pass the "security context" of the workflow inside of the task_policy. i.e.

Copy code

Workflow
└── CreatorId
└── Task[]

Task
└── PerformerType
└── PerformerId
└── RootCreatorId

PerformerType(enum)
ROLE, INDIVIDUAL

Is there something else that I could do (as it seems that we cannot have hierarchical resources at the moment).

Andrew Haines (Cerbos)

03/18/2026, 4:05 PM

The way you're solving it is correct; the policy decision point is stateless, so there's no way for it to infer the relationship between tasks and workflows and therefore you need to pass all the context in the request.

✅ 1

Open in Slack

Previous Next