Hi, sorry for bringing it up again, but I'm still ...
# help
s
Hi, sorry for bringing it up again, but I'm still a little confused if the implementation that we currently have is correct or not. Let me explain my current setup, this is what I use to check things locally: 1. I run a docker image as mentioned in the quickstart tutorial. Along with this I also run a posgress image, which is necessary to make changes to the policy via the admin API. 2. After this I run our Node.js backend where I have stored our policies, and then use the cerbos library to add the stored policies. (I could probably do this via the docker config file, but couldn't do it for some reason, so I resorted to this. I'll also have code that will enable policy updates and changes in the future, so I'm guessing this shouldn't be an issue.) 3. I finally run my frontend, where I use the cerbos library to check access to specific resources. Now currently, everything seems to run pretty smoothly, but I am not sure about how I should be deploying this to our dev environment, I have some questions regarding that. 1. Currently I am running a posgress image and creating the required db schema, so I can make changes to the schema via the admin API. Is it possible to use our internal db (SQL Server) for this? 2. When we deploy to dev, would we have to run the same cerbos docker image to enable the PDP? 3. Is this implementation correct and is it okay to read the policies like this using cerbos library or is adding the directory to the config file more efficient?
d
Hi Siddharth, Thanks for your question. We are happy to help. It sounds like you don’t need to store your policies in the database. A database is typically used as a policy storage when the application needs to update a policy as part of some workflow. The disk driver is widely used to store Cerbos policies. Did you have an issue configuring it? If so, can we revisit it? Otherwise, your implementation looks correct. Yes, you use the same Docker image. SQL Server is not supported, though. I recommend switching to disk driver storage because the deployment is simpler, since there is no need to run Postgres. If you decide to go with a database storage, it’s also efficient.
s
Hi Dennis, thank you so much for replying. Currently our implementation is extremely rudimentary. We just wanted to test a few basic things. Our primary goal is to enable custom roles for our clients. I'll be working on that after we deploy something basic to our dev environment. Correct me if I'm wrong, but I think, we will need to update policies via the code, once we start building custom roles functionality. I'm fine with using Postgres, I just wanted to know if I can use SQL server somehow, so I don't have to run the script db schema script every time. My policies are currently being stored along with my backend code, so the flow would be something like this: 1. Run Postgress image and then cerbos docker image. 2. Run the backend and add all the policies stored there. 3. Make updates to policies via Admin API based on the functionality needed. I am going to try deploying this to dev today. Let me know if you have any recommendations. Once again, thank you so much for your help! :D
d
Our primary goal is to enable custom roles for our clients. I’ll be working on that after we deploy something basic to our dev environment. Correct me if I’m wrong, but I think, we will need to update policies via the code, once we start building custom roles functionality.
Great! I didn’t know that. In this case, you do need a writable storage - a database. I assume that the flow you described sets up a new environment. That sounds right! Just a side note that SQLite seems to meet all your requirements, but it doesn’t need an external database service like Postgres.
… so I don’t have to run the script db schema script every time
I want to double-check here. You must run that script only when set up a new database/environment. If the database is up and running, you don’t need to recreate the schema; you can go straight to updating the policies.
s
Yes, I think you are correct, the database is probably being set up only the first time I run the script, after that I think it doesn't run the sql script every time. I'll try SQLite out, thank you so much for your advice! I'll keep you posted here, once I am done deploying it to our dev env.
🙌 1