When treating policy as code, policy rollout will be part of the Software Development Life Cycle (SDLC). In order to treat policies as code, we would utilize the Git integration feature.
The below is an example of how one might roll the defined policy to the production environment as part of the SDLC.
For simplicity, we will assume there are two environments: development and production.
Follow the steps in the Git integration page and review how to configure the directory in which the policies will be stored in the selected Git repository, and how to define the Git branch, in the Commit Project to Git page.
We would like to commit our policy in the development stage to a branch which is not
main - let us call this development branch
develop and make sure that we commit to that branch.
We will create a new PDP which we will use for development purposes - such a PDP will be deployed in our development environment.
When deploying the PDPs, we may set the BUNDLE_COMMIT environement variable (see PDP Deployments), but since the development phase of a policy is an interative one (policies are constantly edited, refined, tested and published) it can be more efficient to deploy the PDP without setting the Git SHA in the BUNDLE_COMMIT, otherwise we will need to redploy the PDP each time with a new commit SHA to see our changes take effect.
We can still continue to commit our changes to Git when editing the policy, but we will also Publish our changes to the PDPs that are not deployed with the BUNDLE_COMMIT environment variable that holds a commit SHA.
Note that when we would Publish to such a PDP, a build.security logo will appear next to the Revision value - this means that the Revision is taken directly from the build.security control-plane rather from Git.
We would then continue to iteratively author the policy, test it and Publish it until we are satisfied - we would then Perform a Git commit operation from the build.security console to store the changes in Git.
Now that we are satisfied with our policy, we would like to have our changes approved before rolling-out the policy to production - our integration with Git will allow us to do so.
We would likely want to merge our policy to the
main branch - we would therefore open a pull-request for our changes for merging the changes from branch
main. This will allow our peers to review the changes in the Rego files and approve them.
Once the pull request has been approved, we can merge it to branch
After the merge of the pull-request to branch
main, we will have a new commit SHA that we can use for deploying the changes to production.
We can configure our GitOps processes to take the latest commit SHA on branch
main and use it to deploy one or more PDPs in our production environment - we shall do so by utilizing the BUNDLE_COMMIT environment variable which will force the PDP to pull the policy bundle for this exact commit.
We shall create a new PDP configuration and call it
The deployment command for the PDP may look similarly to the following (assuming it is deployed as a standalone PDP):
docker pull buildsecurity/pdp;docker run \-p 8381:8181 \-d \-e BUNDLE_COMMIT="a068cf8952a599395b3e1e18f379d1d7dbd3aaee" \-e API_KEY="neYqBqN9c4EpeCAyV6HZRWXXFjtk7haC" \-e API_SECRET="CEKF***Yzo9Z1JkyfbyHHHkrvk2uy982SuvPPWq668U6TawVhXFi3sumNgWK9Vj8" \-e CONTROL_PLANE_ADDR="https://api.dev.build.security/v1/api/pdp" \buildsecurity/pdp
If we will examine our PDP instances, after the deployment of the PDP, then we will see that the Revision field now holds the commit SHA (short form) and next to it a Git icon.
In the Policy Decision Points page, we can see that the Development PDP configuration is using publish policies while the Production PDP configuration is using a Git commit which was taken from the
main branch, as mentioned above.
We have demonstrated above how one may develop policies on a development environment while not affecting the policies running in production environments.
We have also demonstrated how the Git integration feature allows us to treat policies as code and by so allow us to control the changes that are intended to reach production (by using pull-requests).
Finally, we proposed a method for automatic deployments (continous deployment) by utilizing Gitops processes for taking the latest commit SHA from a production branch (
main in this case) and deploying PDPs in production using that specific commit SHA.