In here: https://docs.cerbos.dev/cerbos/latest/policies/resource_policies.html It says

a resource can be as coarse-grained as a full employee record or as fine-grained as a single field in the record.

The question is, how do I really define field-level policies? am I supposed to create a new

.yaml

file for each field I want to have specific access policies for? Also, how would I ever use that really? Ideally, I should be able to pass

post

and the

user

that's trying to read it to Cerbos, and Cerbos should look, does

post

contain some sensitive data that

user

should not access? then maybe either deny that or... or not sure. But I mean like if I really have to define a new resource policy and manually use that (like

post:photo

) or something like that, then it means I have to manually make sure my back-end does indeed make use of every policy defined as Cerbos

@Yousef Sultan it is up to you to define what a resource policy represents in Cerbos. You can think of Cerbos as a super "if-then-else" engine where the "if-then-else" rules and conditions are written in YAML.

Hi Yousef, although defining a resource policy per field is fine, I wonder if in your case it might make sense to use actions? It doesn't make too much difference as far as Cerbos is concerned, the question is more what would be more manageable for authoring policies (breaking up into lots of very small policies vs having one policy that grows larger as the number of fields on the resource grows). The

post

resource policy could have actions like

view:photo

, and you can submit all the actions in a single check resources call then filter the fields that you return in your GraphQL response. I'd imagine that if you had a naming convention for the actions corresponding to fields, you could add a layer to your GraphQL stack that handles setting the denied fields to null automatically?

@Andrew Haines (Cerbos) oh using actions, this is actually a good point but I have one concern: my application layer is unaware for which fields policies are defined at Cerbos... which... means that if the back-end were to implement a new field in a GraphQL model... that'd automatically mean the field is denied until I happen to explicitly allow that at Cerbos This can be thought of a security practice but really, considering like 95% of the fields are allowed if the entire parent model is allowed, this is a LOT of policies giving practically no value

If you want to go with allowing new fields by default, then you could use a wildcard rule like

view:*

with

EFFECT_ALLOW

and just create rules with

EFFECT_DENY

to control which fields should be omitted. Obviously this is a bit riskier than denying by default but whether that's acceptable for your use case is up to you 🙂

oh got it