Validating OPA Policies in the CLI

Learn how Fairwinds Insights helps to validate OPA policies. See training on setting this up in the CLI.

 

Transcript

Hello, my name is Ivan Fetch, and I'd like to demonstrate using our Insights command line interface to test and validate OPA policies. The command line interface helps both validate OPA policy syntax, as well as the action item that the policy outputs for use in Fairwinds Insights. This improves the feedback loop when working with OPA policies and allows you to test policies locally before you upload them to Fairwinds Insights.

Installation

The first step is to install the Fairwinds Insights command line interface, which can be done by visiting our GitHub page at https://github.com/FairwindsOps/insights-cli, which will link you to the CLI documentation and installation options.

First let's run a --help command to see which validation options are currently available. That's insights-cli validate opa --help. This demo, I'm going to be validating a single policy, but you might also notice that it's possible to validate multiple policies such as for use in CI/CD.

OPA Policy Validation

Let's take a look at the first version of this policy, which has multiple errors that we'll fix along the way as we use the CLI to do validation. We've got a function block namespace at the top, which keeps this policy from running in certain Kubernetes namespaces, such as kube-system. Below that, we have a label required rule, which in this case requires a label named department to be set in the Kubernetes resource. There's also a Kubernetes deployment, which will serve as the test input when validating this policy, and you can see at the top here, there's a commented out label called department. Since that label's not going to be set, it'll cause this policy to fail and generate an action item in Insights.

Let's use the command line interface to validate this first version of this policy. It's failing validation because of the package statement at the top. Here that's set to mycompany and in the next file, 2 2.rego, I've corrected that package statement to be package Fairwinds. If I validate 2 2.rego we have some unsafe variable warnings that begin on line five. Let's take a look at the top of that policy. We see that line five is missing some quotes around the string that's contained in brackets.

However, the 3.rego file has fixed that error. So, let's validate that file next. 3.rego, we have the title and then remediation missing from the action item that the policy outputs. Let's take a look at the bottom of that 3.rego file, and indeed those fields are missing from the action item, but they're present in this next file 4.rego.

Validating the 4.rego file, we have success. It also shows the action item that will be provided to Fairwinds Insights.

Namespace Validation

Now we recognize that when we looked at the policy earlier, it avoids running in certain namespaces like kube-system. So, what happens if we change the Kubernetes manifest input to be in the kube-system namespace, there's a command line option to help make this easier and avoid having to edit the manifest file directly. So, let's go ahead and see what that looks like, if I add -n kube-system, we see that it failed validation and there was no action item that was output.

We can use rego print statements to help get feedback during policy execution. If I take a look at the next file, 5.rego, I've added some print statements, the first of which is in the function that checks our namespace against those that we want to block. The next two print statements are before and after we call that block namespace function.

Let's validate 5.rego and use the default namespace that's supplied in the manifest and see what that output looks like. Now we can see about to check block namespaces, and that we check it, and our namespace was not blocked. So, the policy continues.

Let's do the same thing, except use the kube-system namespace, and this time we see that the print output stops after checking the namespace because kube-system is our namespace, it short circuits the running of that policy.

This policy is working as we intend it to, and we could upload that policy to Insights and make sure that the OPA report is enabled in report hub and begin using OPA. Thank you very much for watching.