Open Policy Agent (OPA)

Share on facebook
Share on twitter
Share on linkedin
Open Policy Agent is a policy engine, basically, a software component allowing an organisation to enforce how resources and data can be manipulated and accessed.

What can you do with Open Policy Agent (OPA)?

Last year, me and a colleague, attended KubeCon/CloudNativeCon in Copenhagen.  During those day on the conference we discovered lots of new tools, frameworks.  One of those discoveries was Open Policy Agent (https://www.openpolicyagent.org). From now on I will use OPA when talking about Open Policy Agent. 

At that time what I liked the most about OPA was the fact that you could have an external and centralised component doing HTTP API authorization plus the fact that you can do some data filtering.  A couple of months later, due to some high pressure projects, I finally found some time to have a more profound look into OPA.

What is Open Policy Agent?

Open Policy Agent is a policy engine, basically, a software component allowing an organisation to enforce how resources and data can be manipulated and accessed. 

What we’ll discuss about OPA in this blog

In our case there are few use cases which OPA can handle:
– HTTP API authorization
– Data filtering
– Kubernetes Admission Control
– Kafka Authorization
– SSH / sudo authorization
– Testing Terraform resource creation

Using a declarative language (REGO) you can write logical tests that evaluate the input, eventually combined with context-aware data.  The language itself is totally context unaware, it does not now about the real world, only the person writing the policy does.

HTTP API Authorization

In a world where more and more organisations are adopting a microservices based approach you can imagine that rules of who can access what are scattered and duplicated over more than 1 service.  This is where OPA comes in and offers the possibility to centralise this configuration.  By defining a policy in OPA you can secure your microservices in a centralised and unified way.  

Data filtering

Another possibility OPA offers is that you can filter the data you return to the consumer, the data of your REST API.  For example, you can imagine that employees of an organisation can access data about themselves or their colleagues.  In that case it would be logic that everybody can see some contact information like phone number, email address, but you don’t want your colleague to be able to view your salary.  

Kubernetes Admission Control

The last year and a half I’ve been using Kubernetes extensively.  During this time I’ve learned that there are a lot of configuration options and that some best practices should be applied.  By making use of the Admission Controllers you can enforce some of those best practices.  One of these best practices is for me the use of labels. By using good labeling it’s a piece of cake to filter your resources. When you use policies you can enforce that a certain label should always be present on your resource.  If you do not use the correct labeling in your manifests, the resource will simply not be created.

Kafka Authorization

In a world where more and more streaming is used, and events are sent everywhere, problems of confidentiality can arise.  Kafka, being a distributed streaming platform, can integrate with OPA to limit the access to certain topics.  By using metadata you can limit applications to access certain topics with confidential data.  Or you can prevent applications to write accidentally to topics on which they should not write. In short, Kafka authorization can keep the integrity of your system safe.

SSH / sudo authorization

In some organisations not all employees should have access to every server.  With Open Policy Agent you can write policies that make sure that only admins have access to all servers. You can also make sure that regular users only have access to a limited set of servers.  For example a team that is responsible for a couple of applications should only be able to access the server of those applications.  And eventually you can even restrict to read-only access.  When needed (maintenance, … ) you can then modify the policy to give write access to the team on their servers, or only one team member, or the entire team to only one server, or … . Once the work is finished you can revert back the policy to only giving read only access.

Testing Terraform resource creation

Like the resource manipulation in Kubernetes, OPA offers also the possibility to set policies that verify the resources created/altered/deleted with Terraform.  Hashicorp already has a Policy As Code solution called Sentinel which at this time integrates better with Terraform, but if you have multiple use cases, like described above, OPA could be a good alternative solution.  

What’s next?

In another blogpost I will go further into detail, explore some more features and provide some code examples that I’m working on.  

Thank you for reading.

Matching documents with queries using Elasticsearch Percolator

How to avoid vendor lock-in with Kubernetes

Peter Ophals

Peter Ophals is Evolutionary Architect at ToThePoint IT company. Peter is a senior Java developer with a growing interest in DevOps, SRE, Cloud native solutions. Peter is working on projects using microservice architectures with use of DDD concepts, CQRS, Event Sourcing, Spring boot technology and which run mostly on Kubernetes in the cloud on Google Cloud or on AWS.

Leave a Reply