Open Policy Agent – Primer

The Open Policy Agent (OPA) is a general-purpose, open-source policy engine, i.e. a collection of components that allows for a uniform and efficient implementation of rules of all kinds. This article shows a small practical example.

When was the last time you heard of a company or IT policy? Maybe you think of "We're supposed to make sure we set certain parameters in the Terraform script" or "We're supposed to make sure we don't run as root in the Kubernetes deployment." The policy can be implemented by taking organizational action – which is a cumbersome description of a peer review or approval process – or by means of clever automation. The latter increases security on the one hand – because, let's be honest: a lot of times, some things remain unnoticed – and on the other hand, it also increases speed, since an automatic check within a pipeline is definitely faster than a human being can ever be. I would like to take a closer look at this small example in this article, because I think that this is a nice way to speed up an in-house process through automation with little effort using the Open Policy Agent.

OPA ecosystem

To be honest, the ecosystem is large and possible use cases are manifold. On the one hand, OPA provides the software components needed to execute rules at runtime, and on the other hand, it is an ecosystem with a wide variety of tools and integrations. And that's where I think the strength of this solution comes in. It gives us the opportunity to benefit from each other as a community, as we normally like to do in our work.

Usage

If we want to deploy the project, we can choose between several deployment variants. The following are the most prominent ones:

1. integration as a library, e.g. in a Go project or via Web Assembly.
2. standalone deployment as a service with REST-based API.
3. usage in a testing tool such as Conftest.

Depending on the deployment scenario, the approaches of loading and executing the data and rules differ. For example, it is possible to include the data and rules in the delivery as a package or to receive these rules from outside.

What the scenarios have in common is the general procedure: First, there is a call that is delivered to the engine from the outside. The rules are then executed and the decision is returned with meta-data. Conftest is the simplest tool, since in this case the rules and the input data are available and can simply be executed locally.

Rego

This language is optimized for this purpose and inspired by Dataloc. I have to admit that I heard about it for the first time only during the research. We can efficiently use it to define rules that are applied to structured input data. Documents or input data are known via a specific variable within the rule execution and can be validated via logical operations. Navigating within documents is similar to https://github.com/stedolan/jq and easy, with a little practice. That being said, we quickly move on to the obligatory "Hello, World!" example. As input data here, we use a JSON document with the Input object consisting of two attributes. The policy checks whether the two attributes are present with the desired values.

Input data:

1{
2    "greeting": "hello",
3    "message": "world",
4    
5}

Policy:

1default result := false
2result if {
3    input.message == "world"
4    input.greeting == "hello"
5}

Kubernetes

Input data can be any structured document, such as YAML or JSON, so Kubernetes manifests are a good example, which is why I will look at this use case in this short article.

Validation of Kubernetes manifests can be done both in the CI system and by an Admission Controller in the cluster. Within the CI system, OPA tooling is used to terminate a build with an appropriate error message. In addition, an active check can be included on the clusters in the form of the aforementioned Admission Controller. This Admission Controller rejects Kubernetes API objects that do not comply with the defined company defaults.

A small example of how to implement validation of Kubernetes manifests via the Open Policy Agent tool Conftest: Conftest is a small command line tool that gets the Rego policies and deployment configuration, does the checking, outputs the result, and provides appropriate return code to act on it in the CI.

We now implement these policies in Rego that check a deployment.

1# Referenced in the following rules to work only on deployments. Other API objects are ignored
2is_deployment {
3  input.kind = "Deployment"
4}
5
6# Only container images from the internal container repository should be used. Checked by a Regular Expression on the image name
7deny[msg] {
8    kubernetes.is_deployment
9    container := input.spec.template.spec.containers[_]
10    not re_match("^internal.repository.de/.+$", container.image)
11    msg = sprintf("Container in Deployment %s should use an image from the internal repository", [name])
12}
13
14# We want to generate a warning if no liveness probe has been defined for a deployment. It is checked directly whether this was defined
15warn[msg] {
16    kubernetes.is_deployment
17    container := input.spec.template.spec.containers[_]
18    not container.livenessProbe
19    msg = sprintf("Container in Deployment %s should define a livenessProbe", [name])
20}

If a rule is not fulfilled, a message is returned by the msg block and is thus visible in the CI pipeline. This is a very simple step that adds value right off the bat. If you have any questions about this, feel free to contact me directly e.g. via Twitter or by e-mail. I'll be happy to work with you to see how we can implement it.

Further reading

This article has quickly given you a first overview of the Open Policy Agent (OPA) project and a way to use it. There are many more options to use the tool. To get a first impression of it, it is worth browsing the ecosystem page of the project. Furthermore, we will post articles on this topic on this blog and also record a SoftwerkerCast episode on this topic.