What is an OPA Design Pattern?
Before we talk about design patterns for Open Policy Agent (OPA) (what they are, why they’re beneficial, what their key ideas are, and how you might try to see them in action with sample data/apps in Styra Declarative Authorization Service (DAS) Free), it’s helpful to start with some background. When we designed the OPA at Styra, we aimed to make it flexible enough to solve every authorization and policy problem in the cloud-native space (and beyond). Obviously it’s an ambitious goal that we will continue to work on for the lifetime of the project, but given that goal, it should come as no surprise that we designed OPA to be supremely flexible in numerous dimensions:
Architecture: OPA can be deployed in a CLI, as a library (Go or WASM), as a sidecar, as a daemon, or as a building block in a centralized service. OPA helps you meet the performance, availability, security and consistency requirements you have.
Policy expressiveness: OPA is more expressive than RBAC (Role-Based Access Control), ABAC (Attribute-based Access Control), ACLs (Access-Control Lists), and cloud IAM (Identity and Access Management) policy languages. It helps you to write the policies you care about, whether they are simple or sophisticated.
Policy composition: Rarely is a single team responsible for all policy, so OPA enables you to decompose your policy into different fragments, share common policy logic, and delegate decision making to the proper policy fragment. OPA helps you reflect the realities of policy ownership in your organization within the structure of the policy itself.
Integration with enforcement points: OPA makes it easy to decouple policy decision making from the software systems that enforce those decisions—whatever those software systems are. OPA is domain-agnostic, meaning it has NO builtin knowledge of any domain (e.g. APIs, cloud resources, data) and because of that can be applied to any domain.
Data sources: OPA supports policies that rely on external data and as such must make it easy to inject that data into OPA so it can properly evaluate those policies. Besides supporting five different ways of injecting that data into OPA, OPA was also designed to ingest any data so long as it is JSON. No need to formulate your data to match some predefined schema; just extract the data from some system of record, convert it to JSON and inject it into OPA.
The consequences of flexibility.
The consequences of flexibility.That flexibility is part of why OPA has been so successful—it can be adapted to meet the authorization needs of many different applications, platforms and organizations. At the same time, that flexibility can be intimidating because there are so many different options you have for solving your authorization and policy problems.
What is an OPA design pattern?
It is therefore helpful to have a collection of starting points—patterns we have seen emerge over the years that solve concrete problems. Just as a design pattern in software engineering gives you an algorithmic solution to a common programming problem, a design pattern for OPA gives you an architectural solution to solve a common policy problem.
Why is an OPA design pattern beneficial?
Design patterns speed up your ability to solve authorization and policy problems with OPA. They embody solutions that account not just for the problems that are immediately evident but also for problems that arise down the road. They have been successfully deployed by multiple organizations at scale in production. Additionally, the names given to each OPA design pattern makes it easier to communicate your plans, experiences, and questions with other engineers, both inside and outside of your organization.
3-body problem for policy
In a previous blog post we described the three of the key design decisions about policy enforcement (Policy – Data – Software) and how they relate to each other. In summary:
Policies can only be evaluated when provided with the correct Data.
Data gravity (size, dynamicity, and consistency) influence which Software can practically be used to make Policy decisions using that Data.
Software that is integrated with OPA determines which domain of Policy decisions can be made and enforced (e.g. API, Database, Resource configuration).
Key information in an OPA Design Pattern
The design pillars for policy enforcement are a key component of the OPA design patterns that we have seen emerge since we created OPA five+ years ago. Each design pattern embodies decisions about Policy – Data – Software. It begins with a description of what the design pattern actually is: the architecture and the Software OPA is integrated with. Then we describe the policies that the design pattern admits and then what kind of external data we see people inject into policy and how. Then we describe the ramifications of this design pattern: performance, availability, security and finally the concrete problems that people use this design pattern to solve.
Each description of a design pattern provides the following information:
Name: a name to make it easy to communicate how you use OPA.
Architecture and software: what software enforces OPA policies and how is OPA deployed?
Policy: what kinds of policies do people write and who writes them?
External Data: what are the data requirements (e.g. sources of data, size, dynamicity, consistency)?
Availability and Performance: what are the expectations for latency, throughput, and availability?
Security: what are the best-practices for ensuring OPA policies are enforced properly?
- Concrete Problems: what are some real-world problems that this pattern solves?
Future Posts
This post has described what an OPA design pattern is and why they are beneficial. In future posts, we will describe several of the design patterns we have identified so far in the wild:
Offline configuration: Authorization for platform resources that are managed outside of the platform itself.
Online configuration: Authorization for platform resources that are managed only within the platform.
Application sidecar: Authorization for end-users or services whose policies are written entirely by developers.
Application entitlements: Authorization for employees who are granted permissions based on traditional systems-of-record (e.g. LDAP).
Application multi-tenancy: Authorization for end-users who write the policies that the system enforces.
Interested in learning more about OPA? Sign up for the Styra Academy! It’s a free online portal that provides exclusive training for Open Policy Agent, Rego and Styra DAS from the founders of Styra and OPA!