In here: <
# community
In here: 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
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
and the
that's trying to read it to Cerbos, and Cerbos should look, does
contain some sensitive data that
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
) 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
For context my back-end uses GraphQL, so what would be amazing is that if, say,
tries to
, except they don't have the permission to read only
... so that Cerbos would somehow tell that to the back-end to make just that specific field
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
or to not return the post at all
Like yes I know this kinda sounds like I'm trying to pull Cerbos in the favor of integrating in the best possible way with the tech stack I use, but I'm kind of merely inquiring to see if there's a neater way to do this without having to define a new resource for each field I want to define policies for
I hope my explanation is not too vague
oh errr maybe I should have asked in #help instead of here, but there we go
@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.
If you wish to use Cerbos as part of your back-end stack, you must have a point in the back-end stack that makes the call to Cerbos, gets a EFFECT.ALLOW or EFFECT.DENY response, and then take the appropriate action.
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
resource policy could have actions like
, 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
Do you think there's any sound way around this?
I also wonder if Cerbos allows passing a 'no participant' of some sort, like I mean for when rendering some data for an unauthenticated user
Not sure what this type of a user would have of roles
If you want to go with allowing new fields by default, then you could use a wildcard rule like
and just create rules with
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 🙂
re "no participant", Cerbos doesn't really care what the principal's ID is. So you can set it to
(or maybe a unique session ID if you have one) and set a role of
or similar.
oh got it
thanks a lot!