Hi, Hi Emre, I am Keerthi and I am an Engineering Manager of a platform team at UiPath. I am excited to evaluate cerbos and I have a few questions. I am trying to get some of the samples to run and I am facing some snags. I searched online and at https://github.com/cerbos/cerbos for help, could not find it.  Can I get some help here ? Also, where do we go look for help for such issues in cerbos. I am sure I might be missing something. Quick Start: https://docs.cerbos.dev/cerbos/latest/quickstart.html Docker run command: docker run --rm --name cerbos -d -v C/dump/cerbos-quickstart/policies:/policies -p 3592:3592 ghcr.io/cerbos/cerbos:0.10.0 1. /api/check is failing with "failed to extract auxData" for the request from the "Fill Example" a. {"log.level":"error","@timestamp":"2021-12-04T093515.955Z","log.logger":"cerbos.grpc","message":"Failed to extract auxData","grpc.start_time":"2021-12-04T093515Z","system":"grpc","span.kind":"server","grpc.service":"cerbos.svc.v1.CerbosService","grpc.method":"CheckResourceSet","http":{"x_forwarded_for":["172.17.0.1"],"x_forwarded_host":["localhost:3592"]},"cerbos":{"call_id":"01FP2CRDZKT37Z5YTMP0JGA5Z3"},"peer.address":"127.0.0.1:58686","error":"keyset not found: string"} 2. I was able to work around by removing the entire auxData part from the request, but despite the policy files present in directory, I do not see them getting picked up a. the response is always EFFECT_DENY, with or without the yaml files in the directory. I am trying out the playground now but would prefer running it locally on my windows machine for further evaluation.

Hi @keerthi kiran -I'm looking into this now - give me a few minutes

Hi Keerthi, Thanks for reaching out. This is the right channel for help 🙂 Would you be able to share the policy and the Cerbos config file you are using? (if you are not comfortable sharing it publicly in this channel, we can create a private one). The easiest way to share the policy would be sharing your playground URL after saving it.

The your first point about the auxData - if you are just getting started and not need JWT verification, you are correct to remove the auxData block I've made a note for us to update the quickstart docs to make that clear - thanks for raising it. The example request should then look something like this:

{
  "requestId": "c2db17b8-4f9f-4fb1-acfd-9162a02be42b",
  "actions": [
    "view:public",
    "comment"
  ],
  "principal": {
    "id": "bugs_bunny",
    "policyVersion": "default",
    "roles": [
      "user"
    ],
    "attr": {
      "beta_tester": true
    }
  },
  "resource": {
    "kind": "album:object",
    "policyVersion": "default",
    "instances": {
      "XX125": {
        "attr": {
          "owner": "bugs_bunny",
          "public": false,
          "flagged": false
        }
      },
      "XX225": {
        "attr": {
          "owner": "daffy_duck",
          "public": true,
          "flagged": false
        }
      }
    }
  },
  "includeMeta": false
}

Is it because there's no colon after

C

in the volume mount point? Does this work?

docker run --rm --name cerbos -d -v C:\dump\cerbos-quickstart\policies:/policies -p 3592:3592 <http://ghcr.io/cerbos/cerbos:0.10.0|ghcr.io/cerbos/cerbos:0.10.0>

Thanks for the prompt suggestions ! I was able to update the docker run to the following and now I see PDP returning allows. I am guessing the casing matters here and also the C: docker run --rm --name cerbos -d -v C/dump/cerbos quickstart/policies/policies -p 3592:3592 ghcr.io/cerbos/cerbos:0.10.0 The includemeta=true is neat and useful. It will be good to include the guidance for windows docker. Also, if you can make the jwt part optional as part of fill example or prepopulate it with an sample token, it will make the getting started experience snag free.

Is there a way to turn off includemetadata on the server side? I don't want this information leaked.

No there isn't. What is your concern about specifically? It does not contain any sensitive information that'd be useful to an attacker.

Policy name. Just as a matter of hygiene. I guess you are right. I just have to make my policy names obscure.

The check API is meant to be only accessible to trusted applications and they already know what the policy is anyway (

resource.kind

).

Hmmm my check api endpoint is currently exposed over the internet. I guess it would be prudent to hide that behind an API gateway to protect it.

I don't think I can answer that question because it all depends on a lot of variables and attitudes to risk. If it were me, I would try very hard not to expose any API to the internet. If VPC is not an option because you have different cloud providers then consider something like Tailscale which works across any kind of network.