OPA @Lacework
Tags: kubernetes, devops
Published: 2021-08-17 22:19:52

There is always a ton of innovation and exciting things happening in the Kubernetes community. One of the CNCF projects we are super excited about over here at Lacework is [Open Policy Agent](https://www.openpolicyagent.org/) which has seen tremendous interest and adoption over the last 18months. If you’re not familiar with OPA it is a unified toolset and framework that can be used for consistent policy decisions across your cloud native stack. In 2020 alone the OPA project had over 35 million downloads and officially became an CNCF graduated project on Feb 4th, 2021. 

What really makes this project special is it’s open governance and that organizations can leverage their existing investment and skillset around policy in many facets of their cloud native stack. Lacework is committed to embracing OPA so that our customers can drive policy decisions in many parts of our platform.

Where are we starting with our OPA support? No place better than in build. This will allow us to offer an enriched developer experience, deeper insight, software supply chain governance, and flexible decision making prior to application delivery.

Ok enough of the fancy terms. Let’s get to the nuts and bolts of our current integration efforts. Lacework is currently in the process of launching a k8s security toolkit called Helios named after the greek titan of the sun and guardian of oaths. So how does OPA fit into Helios? One of Helios’ components is a k8s admission webhook that allows for policy decisions to be made at time of deployment through pod interception with OPA and Lacework image assurance.

Admission webhooks intercept requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. At a high level they offer admission control which governs and enforces how the cluster is used. Let’s take a look at how this works in action as seen in figure 1.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/avrrxvbz1zqk2noutotu.png)
**Figure 1 - High level architecture of k8s admission webhook**

When the application or pod is deployed in step 1 and after the request has been authenticated and authorized it is passed the admission webhook which can be both mutating or validating for processing in step 2. From here the helios webhook will then lookup image assurance scan results with the Lacework platform for the image in step 3. This lookup is performed with the image SHA and if not found an on-demand scan can be initiated. From here in step 4 the scan results json object is sent to an OPA endpoint for a policy decision.

Then based on the results received from the OPA endpoint the pod or deployment is either allowed to be provisioned or is blocked. This result along with any error message received from the OPA endpoint is passed to the kube API server for processing.


We can see the results of this in action below in figure 2. The top terminal is an attempt to circumvent an approved organizational CI/CD pipeline and directly deploy application changes from kubectl. The bottom terminal is a tail on the Lacework Helios admission webhook. We can see that the pod deployment has been intercepted while image assurance results are validated against an OPA endpoint. Based on the vulnerability surface in this image the deployment was ultimately blocked from entering this cluster.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/msooj0vimqtrf3nrr53y.png)
**Figure 2 - Pod interception and OPA validation of scan results**  

These types of checks and best practices can also be integrated at build time through a variety of plugins to well know CI/CD tools. In figure 3 we can see a Jenkins pipeline blocked through an arbitrary policy written in Rego and validated in build against Lacework’s image assurance scanning results. Figure 4 displays a portion of the resulting build artifact.


 ![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/mr1gich24koqs0b2i9be.png)
**Figure 3 - Custom OPA policy in build driving pipeline decisions** 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/nnyuakw7r5psnuehc0b5.png)
**Figure 4 - Resulting build artifact displaying scan decision and policy ID** 


These are just a couple of quick examples demonstrating the power and flexibility of using Open Policy Agent to enforce policy decisions at various stages in your build to deploy pipelines. In this article we covered how Lacework is integrating OPA into our k8s admission controller and CI/CD plugins. Stay tuned for more info on our OPA and other tech initiatives.