Hi Eric, thanks for your interest in Cerbos. Our c...
# community
c
Hi Eric, thanks for your interest in Cerbos. Our current model is to provide an API for access decisions based on contextual data provided by the application. This is purely to ensure that the surface area is small and Cerbos doesn't have access to your internal systems. So we currently don't do JWT validation. We expect the application to have already identified the user as valid and provide us with the information it thinks we need to evaluate the access policies. Your use case is quite interesting and we can definitely have a think about how Cerbos could help you there. Your feedback would be very welcome.
e
Thx @Charith (Cerbos) I plan to test Cerbos as alternative in the coming weeks. The JWT signature validation is a strong argument, but would not be a blocker if not available. One awesome feature for me would be that Cerbos would provide a caching python client library (with configurable eviction time between 0 and ...). IMHO That would be a great feature for the Jupyter case.
c
Cool! We are still working on our client SDKs and hope to get a Python one out soon. In the mean time, there's a primitive client implementation in use at https://github.com/cerbos/demo-python that might be helpful for testing.
Caching is an interesting issue. Because our decisions are based on dynamic context data, the caching strategy has to be very clever to make sure that we don't give you a bad answer. The Cerbos server has some internal caching and the decisions are quite fast, so you might not even need any caching at all.
It's an area we are working on actively.
e
Understand the danger of caching. In the Jupyter case, I imagine a “read” action is less critical than an “execute” action. In that case, a 5 minutes eviction time for “read” could be acceptable, whereas no cache would be tolerated for “execute”.
👍 2