OPA - Driving Policy Standards

This article we discuss about the preliminary ideas of Tekton and how it works

The Open Policy Agent (OPA, pronounced “oh-pa”) is an open source, general-purpose policy engine that unifies policy enforcement across the stack. OPA provides a high-level declarative language that lets you specify policy as code and simple APIs to offload policy decision-making from your software. You can use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more.

OPA decouples policy decision-making from policy enforcement. When your software needs to make policy decisions it queries OPA and supplies structured data (e.g., JSON) as input. OPA accepts arbitrary structured data as input.

In this article we are going to talk about how OPA helps us implementing policies in a Kubernetes cluster.In Kubernetes, Admission Controllers enforce policies on objects during create, update, and delete operations. Admission control is fundamental to policy enforcement in Kubernetes.

What is OPA Gatekeeper?

OPA Gatekeeper is a specialized project providing first-class integration between OPA and Kubernetes.

OPA Gatekeeper adds the following on top of plain OPA:

• An extensible, parameterized policy library.
• Native Kubernetes CRDs for instantiating the policy library (aka “constraints”).
• Native Kubernetes CRDs for extending the policy library (aka “constraint templates”).
• Audit functionality.

Install OPA Gatekeeper

Install using Helm Charts:

helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper/gatekeeper --name-template=gatekeeper --namespace gatekeeper-system --create-namespace

Once installed let us deploy a CRD called ConstraintTemplate

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          type: object
          properties:
            labels:
              type: array
              items:
                type: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg, "details": {"missing_labels": missing}}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("you must provide labels: %v", [missing])
        }        

In the Targets section we are describing the policy with kind K8sRequiredLabels. This policy is written in a policy language called Rego. This example policy do not allow you to create the resource if the resource is not labled. In this example We will next create a CRD of K8sRequiredLabels.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: ns-must-have-gk
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["gatekeeper"]

Now if we check the YAML we can see that we have mentioned required labels is “gatekeeper” and apiGroups is Namespace.Hence namespace created from now on wards will require a label “gatekeeper”. Otherwise we will receive an error as below If we now create the namespace with the label “gatekeeper”, the namespace gets created. This is one of such examples where OPA along with Admission Controllers is enforcing policies on Kubernetes cluster. OPA can help to enforce many different kind of policies for security and compliance of Kubernetes cluster.