The Cloud Native Computing Foundation's (CNCF) Technical Oversight Committee accepted the Open Policy Agent (OPA) as an incubation-level hosted project on April 2nd. OPA is an open source, general-purpose policy engine that provides flexible access control across the entire stack.
Originally joining CNCF as a sandbox project in March 2018, OPA's move to the incubation level indicates the project has been used in production for at least three end users, has a healthy number of contributions, and maintains an active number of commits and merged contributions.
OPA targets cloud-based enterprise technology companies with a solution that offloads service level policy management into a unified, context-aware solution applied across the application stack. A key principle of OPA is that policy decisions should be separated from policy enforcement so that access policies can be decoupled from business logic and no longer hard-coded into services. OPA policy rules can be used for contexts such as service and user level access and authorization, auditing and testing of infrastructure configuration, as well as application specific solutions such as Kubernetes admission control.
Policy management is centralized in OPA and accessed via a RESTful API using JSON over HTTP. OPA is run alongside application services, with relevant service information stored in OPA on startup. When a service needs to answer policy questions, it sends a request to OPA’s API and enforces the policy based on the query result. OPA is deployed either as an operating system daemon, inside a container, or as a library. Policies and service data are stored by OPA in memory. This architecture reduces latency in policy decision making and ties OPA availability with the availability of the host.
OPA’s query and decision model [From OPA's Documentation]
Policies are written in OPA's declarative query language Rego, which was inspired by Datalog. Rego is used to query structured documents models, such as JSON, with support for traversing nested documents and transforming data. Rules make assertions about the data in OPA and enable users to ask yes-no questions about policies.
Traditional policy engines have been designed with methods such as role-based access control (RBAC), which relies on roles and privileges, or access control lists (ACL), which ties permissions to objects. However, these approaches are generally unable to leverage data from the external context, for example, information about the cluster a single Kubernetes pod is running in. XACML (eXtensible Access Control Markup Language) is a declarative language that implements attribute-based access control (ABAC), which combines attributes such as user, application, or environment, to determine access. Like OPA, XACML promotes the segregation of policy decisions and enforcement. OPA's documentation highlights similarities with existing policy engines and how these different systems can be implemented and made more flexible and maintainable with OPA.
OPA is currently used in production at companies such as Netflix, Intuit, and Medallia, and Chef and is working with Google and several other partners on Gatekeeper, a policy controller for Kubernetes. OPA provides a playground to get started with writing policies and full documentation can be found on their website.