GitOps with Styra DAS and OPA
The practice of infrastructure as code (IaC) has enabled platform teams to control infrastructure using code stored in Git. This enables teams to apply standard development practices like code review and testing to infrastructure management. The practice of GitOps takes this a step further by:
- Using technologies where the “code” in the Git is a declarative definition of the infrastructure (no imperative, step-by-step instructions are allowed).
- Fully automating the deployment process, so a commit to Git modifies the infrastructure without further input. This requires a reconciliation process as new resources have to be created and existing ones have to be modified or deleted.
Open Policy Agent (OPA), thanks to its Rego policy language, enables organizations to manage their authorization policies as code (PaC). This in turn allows them to set up a GitOps process to deploy policy changes to production to enjoy the same benefits as with IaC. In this article, I’ll explain how such a process can be implemented using Styra Declarative Authorization Service (DAS).
GitOps in the Infrastructure as Code world
As a first step, let’s take a look at how GitOps has been successfully applied in the world of Kubernetes. Kubernetes has a built-in reconciliation process. A user can submit the desired state of the deployed applications in the form of declarative data, and Kubernetes will automatically take care of modifying the actual running resources to match the desired state. Tools like ArgoCD and Flux take care of monitoring Git repositories for changes and submitting the new desired state to Kubernetes. They will also monitor the cluster for any drift caused by manual actions or failed reconciliation.
Another successful application of GitOps in the world of infrastructure is provisioning resources with cloud providers. Here Hashicorp’s Terraform or AWS’s CloudFormation act as the technology that can reconcile the current state to a Git-storable declarative definition of the desired state.
How to apply GitOps to Policy as Code
Once our policies become code, they can easily be deployed to OPA agents running in our environment — and thus the road to GitOps with OPA is open.
Let’s see how policy as code would be deployed to OPAs with a GitOps workflow.
The goal of the process in this case is to get the code from the Git repo and deploy it to the running OPA agents in an automated way. Let’s work backwards from the OPA agent to understand.
OPA will pull the policy bundle from a remote endpoint using the Bundle API. This is simple when running a single instance, but in a production environment there will be dozens or hundreds of OPAs pulling policy. The Styra Local Plane (SLP) caches the policy bundle close to the OPAs and provides persistency in case a new instance needs policies but Styra DAS is not accessible. While it’s not as complex as reconfiguring infrastructure, we can look at this stage as similar to the reconciliation problem above. Basically, all our OPAs need to converge to a state where all have the right policy bundle loaded.
The final piece of the puzzle is what we can call the GitOps Controller. In our architecture, Styra DAS is playing this role (together with the SLP). It has the responsibility of detecting changes to the Git repo and making sure those changes make it to the actual environment where they are needed. The difference between Styra DAS and a tool like ArgoCD (or Flux) is that Styra DAS is outside of the policy deployment environment and relies on SLP and OPA to pull the final bundle.
This is a minor difference however and from the point of view of a policy developer it all works as one would expect from the OPA GitOps process:
- Commit changes to a new branch.
- CI runs automated unit tests and validations with the help of Styra DAS.
- After PR approval, the feature branch is merged into main.
- Styra DAS detects changes to the main branch and builds a new policy bundle.
- SLP detects a new bundle available in Styra DAS and downloads it.
- OPAs download the new bundle from the local SLP.
The developer doesn’t need to worry about what happens after the merge to main, the deployment process is fully automated.
When teams need more control over deployments and don’t mind breaking GitOps a bit — by adding a manual step into the deployment process — Styra DAS offers options too:
- Configure a System within Styra DAS to track a certain tag or commit hash. Once a deployment starts, the System can be modified to track a new tag or commit hash, adding an extra manual but potentially valuable step into the process.
- Configure a System for manual bundle deployment. Once enabled, Styra DAS will build new bundles but will only make them available to OPA once the user asks for the new bundle to be deployed, adding a manual step.
Enabling Git-based development with Styra Link
The Styra DAS UI supports writing Rego code and pushing directly to Git, but Styra DAS may be an unfamiliar environment for many engineers who prefer to work from their usual tools. Styra Link is an extension to the Styra DAS CLI and allows a developer to work locallly with Rego code while utilizing Styra DAS features like Stacks, Libraries and Validation. We also provide a VS Code extension that integrates all the functionality.
Conclusion
GitOps is a great way to deploy Rego code to OPA and Styra DAS fully enables this process. It’s actually the default way Styra DAS works when Git storage is enabled for a System.
Want to learn more about how you can utilize Styra DAS functionality from the CLI? Read our Styra Link blog post or, optionally, watch our YouTube video detailing the same.