https://cerbos.dev logo
Join Slack
Powered by
does the resource field in a cerbos policy support...
# help
j
does the resource field in a cerbos policy support wildcards?
i'm trying to write a policy where cerbos will only return EFFECT_DENY if a field in a database is to be blocked. all other fields are allowed by default.
if i submit a check to cerbos for a resource that does'nt have a corresponding policy, cerbos returns EFFECT_DENY at the moment.
i have a way of modeling this right now and that is to use the negative form of a verb in the 
action
field
so instead of 
action
= 
read
, i write a policy for 
action
= 
hidden
and return EFFECT_ALLOW. so when my code sees EFFECT_DENY it means the field SHOULD NOT BE hidden but if it sees EFFECT_ALLOW then it means the field should be hidden.
c
Are you asking whether it's possible to define a single resource policy that matches anything? Like, you define a policy for 
foo*
and that matches 
foo
, 
foobar
,
football
and so on? Unfortunately, that's not possible. However, you can emulate that behaviour using lenient scope search. If I am trying to model your use case and trying to define rules for tables in my database 
x
, I'd define a base resource policy for 
database_x
with my default rules. In my application, when I am making the request to Cerbos, I'd set the resource kind to 
database_x
and the 
scope
to the table name (say, 
table_a
). With lenient scope search enabled, if there's no policy defined for scope 
table_a
, Cerbos would fall back to the base policy -- which is similar to the behaviour you want.
👍 1
j
I see. Many thanks Charith.
I went with the negative verb in the end to simplify policy authoring. The default behaviour is to return a EFFECT_DENY is there is no policy that matches the request to Cerbos API. This means only if I have a policy that says field_x and field_y should be obfuscated will I get a EFFECT_ALLOW response from Cerbos. My API code then processes that appropriately.
using the scope approach still required me to write policies for all the tables in the database. This can go out of synch if the database team introduces new tables, which increases operational overhead of keeping Cerbos up-to-speed with the database.
c
Glad you found a solution that works for you. I am curious why you'd need to write a policy for every table with the scope approach? If lenient scope search is enabled (it's not the default behaviour), you only need to create policies for tables that you want to define rules for.
14 Views
Open in Slack
PreviousNext
Powered by