Why Styra Open Sourced OPA
As founders and maintainers of the Open Policy Agent project (OPA), Teemu Koponen, Torin Sandall and I are pleased to be looking back at the project’s first three years and recognizing a significant milestone. At KubeCon in Barcelona, we were overwhelmed by support—many people and companies that we have had no interaction with were extolling the virtues of OPA Policy and claiming that OPA “was everywhere.” This followed the announcement on April 2, when OPA moved from the Cloud Native Computing Foundation (CNCF)’s sandbox to the incubating stage. This benchmark signals OPA’s progress and the contributions of others: proof of concepts and integrations, successes of production users and new participants joining the project. It also provides an exciting opportunity to reflect on OPA’s journey—from how we first envisioned it to how it now solves practical and critical security and policy challenges every day in the cloud-native ecosystem.
What is OPA?
Software developers are not always security experts. In the rapidly evolving world of Kubernetes security and compliance, DevOps and DevSecOps teams are detecting security challenges and compliance issues later in the development and deployment cycles. We expect a paradigm shift in the enterprise development life cycle as developers detect issues and ensure compliance much earlier.
Our goal was to enhance security by shifting security left.
OPA—pronounced “OH-puh!”—is a general-purpose policy engine with uses ranging from authorization and admission control to data filtering. OPA provides local enforcement, with greater flexibility and expressiveness than hard-coded service logic or ad-hoc domain-specific languages. With tooling to help users get started, it empowers administrators with flexible, granular control across an entire stack. Among the projects it facilitates are Kubernetes admission control, HTTP API authorization, remote access and data filtering with partial evaluation.
Said simply, every product and service on the planet has its own way of handling policy and authorization (who can do what and what can do what). In the cloud-native world, authorization and policy are wildly more complex than ever before. More people and machines are performing more actions in production, using more powerful software to manipulate more dynamically changing resources.
Why Open Source?
At Styra, we knew when we created OPA that whatever language we used for people to express policy—the policy language—had to be open source from day one. We decided to avoid a standards process because we knew that the language needed to grow organically by solving real-world problems. Nobody is an expert in all the technologies coming from the cloud-native world. The only way to create a truly unifying policy language is through actually building it out, experiencing what it takes to use it to solve real problems and adapting the language over time.
The engine for evaluating the language and the tooling around it must also be open source, as no one will use a language without basic tooling. The declarative policy language we developed, Rego, defines policy that’s easy to read and write, providing powerful support for referencing nested documents and ensuring that queries are correct and unambiguous.
Open source projects also can live and breathe beyond a single company—that’s the beauty of building amongst a community of experts.
Finally, as part of hardening OPA, we needed to integrate with third-party systems. These are valuable to the community because they solve concrete problems; they also help the world understand the value and generality of the solution.
CNCF: A Vendor-Neutral Home for OPA
From the start in 2016, we knew that OPA would need collaborative efforts. It could only thrive if driven by an active, passionate community that would feed language ideas, improve tooling and build integrations with external systems. Open source projects can live and breathe beyond a single company, and we knew that decoupling OPA from any one vendor would help.
We really liked what the Cloud Native Computing Foundation was doing; it provided the vendor-neutral home that users wanted. It served as a rallying point, providing a level of trust for OPA and a highly engaged and passionate community. The CNCF also does a great job of shepherding projects and curating an important set of building blocks that help projects grow and evolve. (Kubernetes is a standout example of one of the CNCF’s graduated projects.) We were thrilled to donate OPA to the CNCF in March 2018, and we’re excited to see how the community has adopted, supported and enhanced it as we grow.
The Community Moving OPA Forward
The code and the community of OPA continue to mature. Rego’s been proven in production in some of the largest cloud-native deployments in the world. We continue to solve new and evolving customer authorization and policy problems, from helping to define the desired-state in Kubernetes to microservice authorization and out to user-based contextual authorization for access.
In late April, OPA passed the milestone of 2,000 GitHub stars, and at this year’s KubeCon Barcelona, the community support was overwhelming. We’re seeing users pick up OPA and use it for one use case then another and another, and, as you’d expect, we see new use cases crop up regularly—both on our Slack channel and on main stages at huge events! It’s a truly inspirational time in the evolution of the project. We’re thrilled to see what the community continues to add and expand.