OPA - In Action

Hey guys, thanks for taking the time to read the following blog post. I hope it will benefit you in your Kubernetes learning path and help you create a positive impact in your organization.

Let's get into it…

In a previous post, we covered the fundamental understanding of Open Policy Agent, and now we will follow up with real-life examples that you may find yourself implementing in your organization. If you want to view the examples used throughout this blog, you can view the relevant links at the end of the post.

Installing OPA

Let’s start by using a demo cluster. We are using K3D, but you can use any tool to bootstrap your cluster for demo purposes. Then, we can continue installing the OPA Gatekeeper using Helm.

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts

helm repo update

helm install gatekeeper/gatekeeper gatekeeper --namespace gatekeeper-system --create-namespace

You can verify the installation has been done successfully by viewing the Custom Resource Definitions and pods on the gatekeeper-system namespace if you follow the command above.

OPA primary functions

Now, we need to be familiar with the fact that OPA Gatekeeper is primarily used for the following functions:

Validating resources against defined policies (constraints) and rejecting requests that violate these policies.
Mutating resources by modifying them before they are created or updated to enforce/modify configuration which will ensure compliance with policies
Auditing resources that violate defined policies. The resources may have been created prior to the gatekeeper installation or had bypassed the admission controller.

OPA policy example

In the post, we will create a validation policy to check compliance with using an internal company registry. To implement it, we would need to use the CRD ConstraintTemplate.

ConstraintTemplate defines a reusable policy template that allows the same logic to be used with different parameters. The following ConstraintTemplate will check the container image registry, and if validation occurs, it will output an error message.

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
 name: k8sallowedrepos
 annotations:
   metadata.gatekeeper.sh/title: "Allowed Repositories"
   metadata.gatekeeper.sh/version: 1.0.1
   description: >-
     Requires container images to begin with a string from the specified list.
spec:
 crd:
   spec:
     names:
       kind: K8sAllowedRepos
     validation:
       # Schema for the `parameters` field
       openAPIV3Schema:
         type: object
         properties:
           repos:
             description: The list of prefixes a container image is allowed to have.
             type: array
             items:
               type: string
 targets:
   - target: admission.k8s.gatekeeper.sh
     rego: |
       package k8sallowedrepos

       violation[{"msg": msg}] {
         container := input.review.object.spec.containers[_]
         not strings.any_prefix_match(container.image, input.parameters.repos)
         msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
       }

We can view the created constraint template with the kubectl get constrainttemplate command

To put it into action we will need to create a constraint out of the ConstraintTemplate k8sallowedrepos. The following constraint will check if pods on the default namespace will have an image set to openpolicyagent/

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
 name: repo-is-openpolicyagent
spec:
 match:
   kinds:
     - apiGroups: [""]
       kinds: ["Pod"]
   namespaces:
     - "default"
 parameters:
   repos:
     - "openpolicyagent/"

We can view the constraint which had been created with the kubectl get constraint

Trying to create a nginx pod (kubectl run nginx –image nginx) will result in an error by the OPA Gatekeeper. In case we want to remove the constraint from the cluster we can delete the resource, or in emergency case where the OPA creates issue to operate the cluster we can remove his mutation and validation webhooks with the following command:

To conclude,

Implementing OPA in your cluster involves multiple steps, from installing the gatekeeper to implementing CRD, and requires understanding rego unless you use the existing examples in https://open-policy-agent.github.io/gatekeeper-library. Today, Kyverno allows an easier way to implement policies for the cluster, and we will cover it in later posts.

Relevant links:
Gatekeeper library - https://open-policy-agent.github.io/gatekeeper-library
Gatekeeper - https://open-policy-agent.github.io/gatekeeper
Gatekeeper Helm Chart - https://github.com/open-policy-agent/gatekeeper/tree/master/charts/gatekeeper