OPA Gatekeeper Kubernetes Part-1

Every company has policies. Some are required to meet governance and legal obligations. Others help to guarantee that best practices and institutional standards are followed. Manually ensuring compliance would be error-prone and tiresome. Policy enforcement automation provides consistency, reduces development delay through rapid feedback, and improves agility by allowing developers to operate autonomously without sacrificing compliance.

Kubernetes allows policy choices to be separated from the inner workings of the API Server using admission controller webhooks, which are triggered anytime a resource is created, changed, or destroyed. Gatekeeper is a webhook that validates and modifies CRD-based policies that are performed by Open Policy Agent, a policy engine for Cloud Native environments hosted by CNCF as a graduating project.

Finally, Gatekeeper’s engine is portable, allowing administrators to detect and reject non-compliant commits to an infrastructure-as-code system’s source-of-truth, bolstering compliance efforts and preventing bad state from slowing the business down.

The motivation for Open Policy Agent (OPA)

When we start our application, it usually consists of several subsystems. Even in the most basic scenarios, we will have an API gateway/load balancer, 1-2 applications, and a database. In general, all of these subsystems will use different mechanisms to authorize requests. For example, the application may use JWT tokens to authorize the request, but your database may use grants to authorize the request. It is also possible that your application is accessing third-party APIs or cloud services, which will use a different mechanism to authorize the request. When you factor in your CI/CD servers, log server, and so on, you can see how many distinct types of authorization can exist even in a small system.

The presence of so many permission models in our system complicates matters when it comes to meeting compliance, information security, or even self-imposed organizational regulations. For example, if we need to conform to any new compliance criteria, we must understand and apply the same for all of the components in our system that perform authorization.

What is OPA Gatekeeper?

The OPA Gatekeeper project is a specialized project that provides first-rate interaction between OPA and Kubernetes.

OPA On top of simple OPA, Gatekeeper adds the following:

• Native Kubernetes CRDs for instantiating the policy library (aka “constraints”).
• An extendable, parameterized policy library.
• Native Kubernetes CRDs for expanding the policy library (sometimes referred to as “constraint templates”).
• Audit the functioning.

Lets Start the Installation:-

Deploying a Release using Prebuilt Image

If you want to deploy a released version of Gatekeeper in your cluster with a prebuilt image, then you can run the following command:

kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

Deploying via Helm

A basic Helm chart exists in charts/gatekeeper. If you have Helm installed, you can deploy via the following instructions for Helm v3:

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

Following are the objects created as part of the gatekeeper installation:

Validating Admission Control

After we’ve deployed all of the Gatekeeper components in our cluster, the API server will use the Gatekeeper admission webhook to process the admission request anytime a resource in the cluster is created, updated, or removed.
Gatekeeper serves as a conduit between the API server and OPA throughout the validation process. All OPA policies will be enforced by the API server.

Internally, Gatekeeper leverages CustomResourceDefinitions to define ConstraintTemplates and Constraints to enforce policies on Kubernetes resources like Pods, Deployments, and Jobs.

How to Use Gatekeeper

To describe and enforce policy, Gatekeeper employs the OPA Constraint Framework.

Constraint Templates

ConstraintTemplates define a means for Gatekeeper’s Kubernetes admission controller to validate a set of Kubernetes objects. They are made up of two primary components:

1. Rego code that defines a policy violation
2. The schema of the accompanying Constraint object, which represents an instantiation of a ConstraintTemplate

Constraint template example:-

constraint template that demands the presence of all labels described by the constraint

---
apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        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])
        }

Constraint

A constraint is a list of requirements that a system must meet. In other words, Constraints are used to notify Gatekeeper that the admin want to impose a ConstraintTemplate and how.

Constraint example:-

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

In the preceding constraint, we set a policy that requires a pod to contain the label “app”

In the next post we will perform demo with our use case

https://cloudsbaba.com/opa-gatekeeper-kubernetes-part-2/