https://cerbos.dev logo
Join Slack
Powered by
<https://github.com/cerbos/cerbos/tree/feat/role-p...
# help
m
https://github.com/cerbos/cerbos/tree/feat/role-policies I'm having some issues building and running this branch. • When i run 
make lint
it complains about missing types in some role-policy related files • When i run 
make build
it complains about something with docker-format for 
generate-api-docs
. • When i run 
make build
(commenting out documentation, and linting) it fails several tests • When i run 
make build
(commenting out above plus testing) I get a docker image I can run. ◦ it recognizes a rolePolicy document, but I cannot make it return an 
EFFECT_ALLOW
I'm sure i'm missing something in my process. Can anyone enlighten me?
my role policy looks like this:
Copy code
---
apiVersion: api.cerbos.dev/v1
rolePolicy:
  role: myrole
  rules:
    - permissibleActions: 
        - comment
      resource: "myresource"
my check request payload looks like this:
Copy code
{
  "actions": ["comment"],
  "principal": {
    "id": "bugs_bunny",
    "roles": ["myrole"],
  },
  "resource": {
    "kind": "myresource",
    "instances": { 
        "one":{
        "attr": {}
        }
    }
  },
  "requestId": "quickstart",
}
The response:
Copy code
{
  "requestId": "quickstart",
  "resourceInstances": {
    "one": {
      "actions": {
        "comment": "EFFECT_DENY"
      }
    }
  }
}
What could i be missing?
a
Hey bare with us on this one - as we spoke about this still isn't released or documented yet - appreciate your enthusiasm to try it though!
m
Absolutely. I'm thinking I probably missed something in the build process.
For additional info, i tried debugging with the cerbosctl decissions this is the output:
Interestingly while the comment action has 
no match
under policy, the update and view have 
not_allowed_by_role_policies
s
Hi Mads! This branch is in a bit of a state of flux and will continue to evolve in the coming weeks (hence some of the tooling is broken at present). It’s worth noting that the role policy schema is also likely to change, so keep that in mind if generating any in a large quantity. In terms of the evaluation, if a role policy issues an ALLOW for a resource/action combination, it’ll still evaluate against the underlying resource policies (role policies behave a little differently to existing types). So you’ll need to define rules in resource policies to also return an ALLOW. 
NOT_ALLOWED_BY_ROLE_POLICIES
is communicating that a resource/action mapping was not defined in the role policy, hence implicitly is a DENY.
m
Hi Sam, and thank you, It sounds like rolepolices have implicit ALLOWs then? As i understand what you write. A rolepolicy with an ALLOW needs an underlying resource policy that has an ALLOW. So a rolepolicy with no action definition would relegate the evaluate to the resource, which would be an ALLOW. Is this understood correctly?
Ahh now i see. If I define:
Copy code
apiVersion: api.cerbos.dev/v1
resourcePolicy:
  version: "default"
  resource: "roleresource"
  rules:
    - actions: [ 'comment' ]
      effect: EFFECT_ALLOW
      roles: [ "myrole" ]
and then define
Copy code
apiVersion: api.cerbos.dev/v1
rolePolicy:
  role: myrole
  rules:
    - resource: "roleresource"
      permissibleActions: [ "none" ]
then I get a DENY for myrole. Because while the resource policy allows the role policy doesn't explicitly allow. But changing the permissableAction to "comment":
Copy code
apiVersion: api.cerbos.dev/v1
rolePolicy:
  role: myrole
  rules:
    - resource: "roleresource"
      permissibleActions: [ "comment" ]
Makes it an ALLOW.
s
Yes, role policies can only implicitly DENY (by not specifying the resource/action pair), or ALLOW through to later evaluation in resource policies.
Open in Slack
PreviousNext
Powered by