Decoupling Policy Logic and Business Logic
How do you create an OPA policy?
How would you design RBAC using OPA?
What are Open Policy Agent alternatives?
Open Policy Agent (OPA) is a general-purpose policy engine that helps with policy enforcement in cloud infrastructure. OPA allows users to define and enforce policies across a wide range of systems, ensuring compliance and security in dynamic environments.
I have always considered OPA to be one of the most important advancements for cloud infrastructure. In my experience, absent a bespoke solution (e.g. Oso), a rigorous OPA implementation makes for stronger enterprise software.
To implement the OPA engine, you submit a request in the form of a JSON or YAML object. OPA evaluates this incoming request against its policies and data to give a policy determination. You can think of the determination as a decision: approved or declined. It is now up to your software to enforce this decision.
.png)
One of the main reasons to use OPA is that it allows you to decouple policy decision making from the business logic of your services. OPA helps you determine the decision of a policy while your software enforces that decision. This allows you to manage policies in one place rather than coordinating policy changes in the business logic of several systems which could be written in different languages and managed by different teams.
.png)
Rego is the custom language that OPA uses for writing policies. It is a declarative language designed for inspecting and transforming structured data, like JSON and YAML that is used for expressing access to cloud infrastructure.
Rego was inspired by Datalog, but extended to support structured document models such as JSON and YAML. Some developers consider it particularly confusing (evidenced by this Reddit thread), but Rego is the language of choice for Opa users.
Authorization in OPA starts with loading your authorization data in a structured format like JSON. You then write policy rules in Rego to transform the data as needed in order to derive the authorization context of the data. An example of this could be determining a user’s role or figuring out which organization a file belongs to. When the data is in the right structure, you inspect it to determine whether to allow or deny a request.
RBAC, which stands for Role-Based Access Control, is a broad classification for using roles to control the access that users have to resources. Most people are familiar with the concept of roles, and expect them to be a part of any authorization system. For many app developers, roles are the first and fastest step in implementing application authorization.
To design an RBAC system using OPA, you’ll first need to assign roles to all of your users. We’ll do that using a dictionary. In our case we have two roles: admin and member. Alice is both an admin and a member while Bob is only a member.
Based on their roles, Alice and Bob will have different permissions. We’ll need to define the various permissions that each role has. In the example below, a member can only “read” the Acme repository while an admin can “write” and “delete” the repository.
.png)
With these data structures in place, we’ll need to implement logic to determine whether a user has permission to perform a given action based on their role. Given a user, we’ll need to first determine what roles they have. Then, across all of their roles, we need to see what permissions they have.
In this simple example, you can see that we defined a policy that determines what permissions our users have. With this policy defined, we can determine if a given user has permissions to do the requested action.
OPA is a great general-purpose policy engine. It’s designed to accept data from a variety of systems in their native format. Its rules language, Rego, provides primitives that allow you to transform and inspect its data as needed during evaluation to make authorization decisions. In this way, OPA emphasizes interoperability with third-party systems, where the data isn’t under your direct control. It is also well suited to machine-to-machine operations.
Oso is a good alternative to OPA for use cases like application authorization.
Oso’s policy language, Polar is built around the higher-order entities that you model in applications, such as actors, roles, and relationships. This makes it a natural fit for the application authorization domain.
If this space is relevant to you, I would recommend reading our overview of the distinctions between Open Policy Agent and Oso.
Engineering teams are increasingly adopting services for core infrastructure components, and this applies to authorization too. There are a number of authorization-as-a-service options available. OPA is a popular general-purpose policy engine that implements authorization logic as low-level operations on structured data.
Oso Cloud is a managed authorization service that is tailored to Application Authorization. You use Oso Cloud to provide fine-grained access to resources in your app, to define deep permission hierarchies, and to share access control logic between multiple services in your backend. You do all this by using the same sorts of higher-order entities that you’re already modeling in your application: users, roles, relationships, attributes.
Oso also comes with built-in primitives for patterns like RBAC and ReBAC, and it is extensible for other use cases like attribute-based access control (ABAC). It is built using a best practices data model that makes authorization requests fast and ensures that you don’t need to make schema changes to make authorization changes. It provides APIs for enforcement and data filtering. Oso Cloud is also deployed globally for high availability and low-latency.
Oso Cloud is free to get started – try it out. If you’d like to learn more about Oso Cloud or ask questions about authorization more broadly, set up a 1x1 with an Oso engineer.
OPA is free and is available under an Apache License 2.0.
OPA is developed by the OPA community. It was originally created by Styra.
The best place to get started with Rego is to read the Rego documentation on the OPA website.