Yousef Sultan
02/04/2023, 3:22 PMa 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 Cerbosuser
tries to read
a post
, except they don't have the permission to read only post.photo
... so that Cerbos would somehow tell that to the back-end to make just that specific field null
Because then it'd be left for GraphQL to look at the GraphQL schema and the resolved data, and decide whether to return the post with the missing photo
or to not return the post at allJesum Yip
02/06/2023, 2:51 AMAndrew Haines (Cerbos)
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?Yousef Sultan
02/07/2023, 3:06 PMAndrew Haines (Cerbos)
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 🙂none
(or maybe a unique session ID if you have one) and set a role of unauthenticatedUser
or similar.Yousef Sultan
02/07/2023, 4:48 PM