Who Needs Open Policy Agent?
Open Policy Agent makes it possible to create a single set of configuration rules and deploy them automatically across a large-scale environment.
![Who Needs Open Policy Agent? Who Needs Open Policy Agent?](https://eu-images.contentstack.com/v3/assets/blt07f68461ccd75245/blt27853f27be177eb0/661ce3637e0b4518918da2ce/Open_20Policy_20Agent.jpg?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
Open Policy Agent, or OPA, is one of the hot open source technologies du jour. Should your team consider it?
What Is Open Policy Agent?
Open Policy Agent, or OPA, is an open source tool that lets you write code to define how an IT resource should be configured. Then, OPA reads the rules and enforces the configurations automatically.
(For the record, OPA should not be confused with Oracle Policy Automation suite or the opa programming language, both of which are unrelated to Open Policy Agent.)
OPA became an incubating project at the Cloud Native Computing Foundation (CNCF), one of the major backers of open source development, in April 2019. It “graduated” from the CNCF in February 2021, which means the CNCF deemed the project mature enough to operate on its own (even though OPA remains a developing technology).
OPA has enjoyed increasing fanfare since its debut as a CNCF project, not least because it allows developers and IT engineers to apply an “everything as code” approach to all aspects of their workflows and environments.
What Problem Does OPA solve?
By allowing engineers to write policy-as-code files that define how a resource should behave, OPA makes it possible to create a single set of configuration rules and deploy them automatically across a large-scale environment. This approach, which is called policy-as-code, eliminates the need to configure and audit each resource manually.
The idea of using code-based policies to configure IT resources is not new. It’s what infrastructure-as-code tools like Terraform, Ansible and AWS CloudFormation have been doing for years. Similar approaches have been applied to managing identity and access control in the cloud or enforcing data security rules.
What makes OPA different from previous policy-as-code tools is that OPA can configure virtually any type of IT resource, rather than just a certain type of resource (like cloud infrastructure or cloud access-control rules). Whether you want to manage API requests in Kubernetes, control resource provisioning in your cloud environment or even configure a firewall, OPA provides a centralized platform for doing so.
Do Enterprises Need OPA?
Whether your company needs OPA depends in part on how scalable your workloads need to be, as well as how automated you aim to make your workflows.
For companies committed to scalability, OPA offers unparalleled benefits. By making it possible to write a single set of policy-as-code files and apply to hundreds or thousands of instances of a given resource--whether that resource is virtual servers, user accounts, CI/CD processes or something else--OPA helps companies achieve a level of scalability that would be more difficult to attain if they had to configure each resource instance manually or use a different type of configuration tool for each category of resource.
That said, it’s worth noting that most real-world OPA use cases to date fall into one of two categories. One is enforcing security and compliance rules, which OPA can do by comparing actual configurations to the rules that engineers define in policy-as-code files. The second is managing workflows like authorization and admission control in Kubernetes clusters via OPA rules. If your company faces either of these challenges, there’s a good chance that OPA will offer value.
You’ll also benefit from the fact that best practices for these OPA use cases have already been fairly well established by other organizations that have deployed OPA in the context of Kubernetes and security and compliance.
When Should You Adopt OPA?
For now, OPA remains under development, and has not yet had a 1.0 release. If you’re conservative about adopting new technologies, you may want to wait a bit before incorporating OPA into production workflows.
Nonetheless, a variety of large companies report already having adopted OPA. Many, like Atlassian, Netflix and Chef, are the sort of DevOps-leaning organizations that you would expect to be early adopters of a technology like this.
Whether OPA is a good fit for your business now depends in part on which kinds of skills and preferences your engineers have. Do they like using the latest and greatest DevOps tools? If so, OPA may be for you. On the other hand, if you prefer the tried-and-true over the bleeding-edge, you may want to wait for OPA to mature.
Which Skills Do You Need to Adopt OPA?
Adopting OPA will be straightforward for teams that are accustomed to using other policy-as-code frameworks, like the infrastructure-as-code tools described above. OPA works in more or less the same way as these tools.
The only big difference is that OPA uses a different configuration language, called Rego, to write policies. Rego is a pretty simple language to learn, but it’s likely not one that your engineers will have encountered before.
Learn More about OPA
The best place to learn more about OPA is to browse the tool’s documentation and check out its blog, where you’ll find news about the latest development milestones and integrations. Some useful OPA examples--as well as the code itself--are available on GitHub.
About the Author
You May Also Like