Hi, I have a question about the storage drivers. W...
# community
w
Hi, I have a question about the storage drivers. We like the idea of our policies being managed in a git repo so that developers can collaborate and author policies independently. We also need to support the creation of dynamic policies via the Admin API, which seems to fit the db driver configuration. Is there a way for us to combine the two somehow (policies managed in git but also allowing dynamic creation of policies)? Thanks! https://docs.cerbos.dev/cerbos/latest/configuration/storage
d
Hi Will, No, you can’t combine storage drivers except for the overlay driver, which is used for redundancy - not your use case. You can import policies into the database in your CI/CD pipeline. Please check out cerbosctl put policy --recursive command.
d
This won’t handle the deactivate policy workflow though will it? Removing a file in a git commit would need to be reflected in the database. Like Will, I also had come to slack looking for the answer to this question, our data model has a lot of principal policies for various legacy but business critical reasons. Principal polices would be a nightmare to handle via gitops strategy, not to mention the latency would be quite notable - we integrate authn/authz into our react app and use zitadel as our IdP. We’ve hit a wall on the complexity you can get out of string based RBAC models zitadel can support so went out looking for a dedicated authz engine. That said we would need to be able to toggle some switches on a user management interface on the frontend, which would need to get back to zitadel if it’s user centric (username, email, etc) but also update the user grants given to the user (into something like cerbos). This lends itself to the postgres model, and minimise caching as much as we can if using the sidecar model, or just have a single relatively large single instance so the admin api cache bursts on changes. Lots to read and consider during this evaluation of Cerbos
d
Hi Daniel, Thanks for sharing your use case. I agree that it fits the database model. Talking about the GitOps model, instead of deleting a policy file, you can disable it by setting
disabled
to true in the policy file header. Perhaps surprisingly, it is not possible (yet) to delete a policy if you use a database driver. However, it is possible to disable a policy, and it has the same effect as deleting one, except that it can be enabled later.
👍 2