Building with Open Policy Agent (OPA) for Better Policy as Code

When we hear the term Policy as Code, it’s for the most part associated with the enforcement aspects of applying policy at scale within organizations.  Whether in the context of GitOps or just popular open source projects like Open Policy Agent (OPA), applying global policy is the end goal.

However, OPA as an open source project is quite unique in its capabilities. There is a whole pre-enforcement set of tools that provide incredible insights into our systems that have long been overlooked.  A new wave of infrastructure drift has arisen in the cloud world due to the layers of abstraction and automation. When building Firefly, we channeled the power of OPA as a policy discovery engine, not just an enforcement mechanism.

What Is Open Policy Agent and How It Works

Open Policy Agent is an open-source engine that provides a way of declaratively writing policies as code and then using those policies as part of a decision-making process. It uses a policy language called Rego, allowing you to write policies for different services using the same language.

OPA can be used for a number of purposes, including:

OPA and Gatekeeper: OPA or Gatekeeper?

In the last couple of posts, I wrote about Open Policy Agent (OPA). People almost always ask one question: what is the difference between OPA and Gatekeeper when it comes to Kubernetes admission control? And, generally, follow up with another question: so should I use Gatekeeper instead of OPA?

Admittedly, the OPA documentation does a nice job explaining OPA and its use cases. It also has a brief section about the difference between Gatekeeper and OPA. But for those just getting started with OPA, this difference isn't always clear.

Leveraging Kubernetes Open Policy Agent

One of the big challenges of going cloud-native and using containers is enforcing security and usage policies. This is an easy task to complete when the cloud infrastructure is relatively simple and has only a limited number of users. Once the cloud environment becomes complex or there are more end-users utilizing cloud resources, having clear governance is a must.

In Kubernetes, policy management and governance are easy thanks to the Open Policy Agent Gatekeeper project or Gatekeeper in short. It enables compliance checks and more thorough management of policies without sacrificing agility or ease of use. Gatekeeper acts as the agent that validates CRD-based policies run by Open Policy Agent.

Kubernetes Pod Security Policies with Open Policy Agent (OPA)

Kubernetes is the most popular container orchestration platform in today's cloud-native ecosystem. Consequently, Kubernetes is also an area of increased interest and attention.

In this blog post, first I will discuss the Pod Security Policy admission controller. Then we will see how Open Policy Agent can implement Pod Security Policies. In fact, during Kubernetes SIG Auth at Kubecon + CloudNaticeCon North America 2019, Open Policy Agent/Gatekeeper was touched upon as a potential alternative to Pod Security Policy.

How to Automate Container Security by Using CRDs to Get Security Policy as Code

Security has long been a sticking point for many DevOps teams (including my own, at a Canadian insurance and financial services co-operative). While available tools have enabled automation across plenty of other parts of our CI/CD pipeline — and made automated deployment of our container-based applications the norm — security automation has largely lagged behind.

Like most DevOps teams, we put automated vulnerability scanning into place, but the manual effort of building security policies to safeguard production application workloads remained a pain point.

Open Policy Agent, Part II – Developing Policies

In the previous part of the series, we explored Open Policy Agent and implemented an ACL-based access control for our application. In this entry, I am going to share with you some of the discoveries that I made while evaluating Open Policy Agent in regards to policy design and development.

Policy Design

After evaluating policy rules, OPA returns a result of the policy decision to your application. This result is a JSON structure. Based on your requirements, this JSON structure can contain a single member holding a true or false (authorized/not authorized) value. However, you can create policies whose evaluation results in an arbitrarily complex JSON document. For example, OPA can return a list of nodes on which Kubernetes should schedule a workload.