Strengthen Compliance by Analyzing Rego in CI/CD Pipelines – InApps Technology 2022

Open Policy Agent (OPA) is an open source engine for specifying compliance policies across the cloud native stack. The OPA project includes a recent enhancement to its Rego type checker that uses JSON schemas as input during policy evaluation, which essentially provides a blueprint for the policy being written. This allows for more immediate static type checking with informative error messages, letting users write policies correctly.

The new enhancement is achieved through the opa eval command and a new schema parameter (–schema/-s), including schema(s) for the input and data. Previous blog posts introduce the static type checker with schemas to the OPA user community, using various examples that can be run as individual policies in a pure development environment such as an IDE or terminal.

In this blog, we demonstrate how to bring OPA type checker usage with schemas to continuous integration/ continuous delivery (CI/CD) pipeline workflows. This adds a layer of vulnerability checks to the Rego policies that, in turn, enforce compliance of critical resources and data for organizations in production-like environments.

A Compliance Bonus

We aimed to not only improve the productivity of Rego programmers during local development cycles, but also to contribute to the “shift left” movement by adding a type checking stage for Rego policies to existing and new CICD pipelines. We’ll discuss how this can be used in your own workflows further. But first, let’s understand why this is important from a compliance and security perspective.

It is common for organizations to have hundreds of Rego policies, if not more, to guard and monitor access to resources, data, etc. Testing batches of Rego programs requires concrete inputs, which might not cover the range of possible behaviors. Errors, even very minor ones, in Rego policies can result in non-compliant configurations going undetected.

DevSecOps encourages teams to build compliance and security into applications from the start by incorporating security checks and gates in pipelines. One such check is to integrate OPA’s enhanced static type checking as a pipeline stage in DevSecOps processes to analyze large bundles of Rego source to find errors in them.

Batch Analysis of Rego Files in DevSecOps Pipelines

There is a “shift left” focus now in the software world for security and compliance processes in DevSecOps. This involves methods for analyzing all kinds of code — application code, configuration code, etc before deploying them — which has been helpful for discovering security issues sooner and guaranteeing vendors and users compliant and safe code.

IBM recently announced a new compliance and regulatory software called Code Risk Analyzer (CRA), an offering from IBM Cloud Continuous Delivery. Today, CRA comes with a number of pre-built Tekton tasks and pipelines that perform compliance checks on your source code and your infrastructure code like Terraform, etc., and can be easily incorporated into your continuous delivery pipelines.

The output from these delivery workflows can be used both in your Git repository and in the continuous delivery dashboard. This development is significant because it blocks code with compliance holes from being deployed and, if needed, it can be manually or automatically remediated.

We used both IBM Toolchain and OpenShift Pipelines to execute many of the pre-built CRA Tekton tasks and pipelines on our GitHub repositories. We then implemented a similar, but new Tekton task (screenshots below) that runs OPA’s enhanced static type checker on policies via batch analysis and added it to the existing CRA collection.

For example, to run this new pipeline, we chose a GitHub repository that contained hundreds of Rego source files for Terraform and generated JSON schemas for many of the input documents being referenced. The repository with its directory of policies and directory of corresponding schemas are then batch analyzed by the opa eval -s command to expose type checking errors.

Below is a screenshot of what the IBM Toolchain UI shows you once you have the CRA Tekton task/pipelines integrated into your DevSecOps flow. Notice the cra-rego-analysis task being listed as a stage in the overall pipeline.

Now, let’s look a bit more into the details of the new CRA Tekton task running in the pipeline above: ​

The task lets you set any necessary environment variables and inputs for rego analysis such as information about the GitHub repository being analyzed, location to the directory of policies, schemas within the repo, access tokens, etc. (screenshot below). The args section contains the commands to be run on the policies.

IBM Toolchain/OpenShift Pipelines also lets you set triggers for when these CRA tasks/checks must be run. For example, you can create a trigger for GitHub pull requests into the main branch that runs the specified set of compliance stages every time someone opens a pull request in that repository. (See below how opening a pull request triggers a pipeline to run with your configured CRA tasks.)

It then evaluates all the Rego policy files it finds in the input GitHub repository for compile-time errors. For example, let’s say that your GitHub repository being analyzed contains a policy file like below where variables is incorrectly spelled:

The typo causes the field variables to be an empty set, even if there exists defined variables in tfplan, which could lead to other dependent policies making incorrect decisions.

Once the analysis is done, the pipeline posts a comment in readable format to your GitHub pull request and updates the result status for this task with success|failure. The comment includes any errors that were discovered during analysis, which must be reviewed before merging the pull request. See screenshot below to see the Rego error resulting from OPA’s static type checker evaluating the policy with the supplied schemas.

Similar compliance Tekton tasks pre-built in CRA can be found here: https://github.com/open-toolchain/tekton-catalog/tree/master/cra

Bundle Type Checking Feature in OPA

Additionally, OPA has support for evaluating bundles of policy and data files using “bundle” sub-commands and APIs. The ability to similarly upload a bundle of JSON schemas for performing static type checking of batches of policies was added to OPA. This can be used in your DevSecOps workflows and is a value-added gain to assess your policy files and get them production-ready.

Read more here about using OPA eval with bundle parameter: https://www.openpolicyagent.org/docs/latest/#2-try-opa-eval

Read more here about using OPA bundle APIs: https://www.openpolicyagent.org/docs/latest/management-bundles/

Summary

The addition of OPA’s static type checking with JSON schemas to CI/CD pipelines is an exciting advancement in the world of compliance. This provides a level of guarantee to users that their software is secure and compliant after it has gone through stages of code analysis and any possible vulnerabilities exposed and remediated.

Thanks to tools like IBM Code Risk Analyzer and managed public cloud offerings like IBM Toolchain and OpenShift Pipelines, it is possible to add new compliance tasks with a few lines of code and the push of a few buttons.

Featured image via Pixabay.