https://cerbos.dev logo
Join Slack
Powered by
hi, i'm trying out cerbos right now - does the act...
# help
h
hi, i'm trying out cerbos right now - does the actual check api cache its policies while the admin api doesn't? i've got 
watchForChanges
turned on with the disk storage, and when i update my policy i can see the changes immediately reflected in 
/admin/policy
, but 
/api/check
is still making outdated decisions based on the old policy. if this is the case, how can i change this behaviour? 
/admin/store/reload
didn't work, and even if it did i wouldn't want to be regularly needing to call that, obviously
a
Hey that's unexpected. How are you running the Cerbos instance?
h
hi alex - it's just included as service in our docker-compose.yml
policies in a volume (whoops, terminology update)
a
Great and do you happen to know which version you are running? The /api/check endpoint was deprecated a while ago now and replaced with this https://docs.cerbos.dev/cerbos/latest/api/index.html#check-resources
(That said it should still pickup the new policies)
h
ah sorry, the endpoint was just a mistake on my part - i'm using 
/api/check/resources
. version is 0.20.0
👍 1
a
No worries - you're all up to date. I'm just checking if we have any known issues with this as it's not something I've come across myself yet
h
my test is just having an EFFECT_ALLOW policy for role 1 on a resource - making a check request with role 1 and with role 2 results in the ALLOW/DENY as expected, but then changing the role in the policy to role 2 and making the same requests results in role 1 still being allowed and role 2 denied
(while /admin/policy will show the updated role)
it doesn't properly update its decisions until the container goes down and up again
a
can you share your config file please
c
h
can do shortly - stashed the branch right now as working on something else
👍 1
config file i can do though
Copy code
audit:
  accessLogsEnabled: true
  decisionLogsEnabled: true
  enabled: true
  backend: local
  local:
    storagePath: /data/audit_logs
auxData:
  jwt:
    cacheSize: -1
server:
  httpListenAddr: ":3592"
  playgroundEnabled: true
  adminAPI:
    enabled: true
    adminCredentials:
      [snip]
storage:
  driver: "disk"
  disk:
    directory: /data/policies
    watchForChanges: true
(auxData was just a shot in the dark - i'm not actually sending a jwt and it doesn't make a difference to the issue i'm seeing whether those config settings are there or not)
👍 1
c
Even restarting the Cerbos instance should be enough. My hunch is that your policy has an issue that fails compilation so Cerbos is using the cached copy that's valid
h
it's possible - i've been running it through playground occasionally and not seeing any problems but i'll definitely check once i'm back on that branch
hey, finally got back to this: compile runs fine on my policies
ran compile on a policy with role 1 allowed, all good. started cerbos, made two checkresources with role 1 and role 2 and got allow and deny as expected. updated policy to allow role 2 instead of role 1, saw it update in /admin/policy, ran compile on it, all good. made the same two checkresources again, role 1 is still allowed and role 2 is still denied
that's the full sequence i went through
c
Hmm.. that's very odd. Which operating system are you using?
h
right now testing on windows host w/ docker desktop
c
Ah! Unfortunately, I think that file watching doesn't work on Windows. There are some Windows oddities that break some of the Cerbos features.
h
hmmm, fair enough - it's really weird to me that it updates the policy correctly in the admin api but doesn't actually update its responses to requests, though
but i guess that is accurately described by "oddities"
c
The admin API reads policies directly from the store. Whereas, for the check API, once we compile a policy, we keep it in memory until it changes on disk. On Windows filesystem notifications don't quite work so the cache doesn't get flushed.
✅ 1
This seems to be a known issue because Docker on Windows uses CIFS volumes that don't support filesystem notifications. Some people suggest using this script but it seems to be a few years old. I also got the impression that WSL volumes are better. Unfortunately, none of us have Windows machines to test any of these solutions. One workaround I could suggest is to convert your policy directory into a Git repo. Cerbos supports local git repos that use the 
file
protocol so you don't have to push it to GitHub or anything like that. The only annoying bit is that you'll have to commit your changes in order for Cerbos to notice the changes.
5 Views
Open in Slack
PreviousNext
Powered by