In the cloud native space, security goes a long way. One of the open source rising stars of this space is Open Policy Agent (in short – OPA).
I’ve found it difficult to explain to fellow engineers and my colleagues what exactly is OPA and what does it do? As time passed, I came up with a form of analogy that explains it even to those who know nothing about development!
In this blog post I’ll share this analogy with you and tie it down to our world.
So what is OPA? Starting from the official documentation:
General-purpose policy engine that unifies policy enforcement across the stack
Those are some fancy words right? let’s try and break it down
The startup analogy
Our story begins with a startup company named Popo. As they are at early stages, Popo are renting a few rooms at an office building. They also hire a total of 10 employees. One of those employees is the secretary – Sarah. Sarah is responsible for coordinating meetings for the CEO and CTO, employees well being, kitchen supplies, a weekly happy hour. She also maintains a spreadsheet which states which employee is allowed to enter what rooms and to which he is not. The spreadsheet rooms policy updates according to Tom, the CTO.
As Popo are growing, they start renting more rooms and hiring more employees. As a result, Sarah’s rooms policy spreadsheet grows. Popo also starts handling more sensitive data during meetings. A resulting limitation is that some employees are denied entry to meeting rooms at certain times. Now Sarah needs to maintain, among all of her other tasks, more spreadsheets.
Popo now arrive at round C and raised serious money! They now have 3 floors, a lot of rooms and 60 employees. Sarah can’t really handle the rooms policy anymore since it got too complex.
Following the illustration below: first, Tom explains to Sarah which employee is allowed or denied to which room. Sarah updates the spreadsheet accordingly. Then, an employee approaches Sarah with a request to enter a certain room. Sarah needs to evaluate the spreadsheet and decide whether or not this employee is allowed to enter that specific room.
Outsourcing a solution
The CTO, Tom, notices that some employees are in rooms that they are not supposed to be in. After a discussion with Sarah he understand the problem. Tom remembers he heard about a company called Shmopa that solves these problems exactly.
Tom gives a call to Shmopa’s sales offices. He hires them to outsource the rooms policy and offloads this mission from Sarah’s hands. Now she can focus on her more important missions.
Shmopa solves the problem in the following way: whenever an employee needs to enter a room, Sarah calls Shmopa, states the employee name and a room. Shmopa replies with an allowed or denied entrance to said room.
The way that Shmopa knows if the employee is allowed or denied is by receiving the list of limitations in a format they ask for in advance from Tom. This format is really easy for Tom to update when needed. Shmopa cross reference the policy and gives back an answer of allowed or denied. The only thing left for Sarah to do is either walk the employee to the room or out of the office. How cool is that?!
Following the illustration below: Tom now updates Shmopa with the rooms policy directly, and when an employee approaches Sarah, she no longer need to evaluate the spreadsheet, she just calls Shmopa and gets a response.
Breaking it down
Let’s take this to the development world. Say you were developing an API server (Popo). How would you determine which user is allowed to do what actions? In most common cases, this would be a part of your code. The developers would then need to maintain it (Sarah). Meaning you would hard code users or their roles (employees) and have constraints on each endpoint. Each constraint stating user names and actions they are allowed or disallowed performing on these endpoints (spreadsheet). The way you would know which user is allowed or denied is by the the SecOps team for example (Tom).
As your code grows, and the users policy gets more complex (remember how Popo started growing), it takes a lot of engineering time and power to maintain the policy.
OPA (Shmopa, very original, I know) solves this in an elegant way. From the official documentation:
OPA decouples policy decision-making from policy enforcement. When your software needs to make policy decisions it queries OPA and supplies structured data (e.g., JSON) as input. OPA accepts arbitrary structured data as input.
Say you were using OPA to decouple the policy decision from your code. Your API server, once receiving some request to an endpoint, will query OPA which holds the policy conditions and logic. OPA will then return a true/false answer (not only! more on this later) stating whether this request is allowed or denied.
Key points
You must not forget that the actual enforcement is still up to you to implement. Meaning, walk the employees into the room or out of the office. For example: if OPA returns false on a certain request, the logic on what the following steps would be is up to you.
The policy is written in Rego – OPA’s policy language, which was designed specifically for policy compilation.
Credit: OPA documentation
Another key point is that OPA not only examines the specific request, but it also generates policy decisions by evaluating the query input (request, event, etc.) against policies and data. Where the data can be anything that describes the state of your system (which meeting room is occupied). Also, as mentioned above, the answer does not have to be true or false, it can be any structured data you want such as the reason for which a certain request was denied.
Do you share the pain Popo and Sarah experienced? Is there a policy that you consider complex as part of your code? If the answer is yes, you should consider using the Open Policy Agent.