OPA and Gatekeeper enforce policy defaults in Kubernetes

Watchdog

Gatekeeper or kube-mgmt?

No matter how you spin it, the details that differentiate OPA with kube-mgmt on one side from Gatekeeper on the other do not turn out to be earth-shattering. In both cases, the same up-to-date OPA versions are used; in both cases, the administrator has to change the configuration of a Kubernetes cluster to use OPA as an admission controller.

Gatekeeper may have an advantage here because it allows policy configuration from within K8s, whereas with the kube-mgmt variant, the admin is up against the OPA instance itself. (See the "Whence Come the Rules" box.) However, this only makes a relevant difference where the admin for the workload in K8s is not the admin running Kubernetes itself.

Whence Come the Rules

Gatekeeper and kube-mgmt have one feature in common: You have to create the compliance rules required for the specific application themselves. Ready-made rulesets for different areas of application cannot be found on the web, at least not yet. It is far beyond the scope of this article to go into detail about Rego and how to use Rego in OPA for Kubernetes. The examples in Listings 1 and 2 are taken directly from the docs for Gatekeeper and show what rule enforcement can look like in principle. The first listing defines the constraint template, and the second implements the concrete constraint with payload data. To load both constraints into a K8s cluster, use:

kubectl apply -f

The example enforces that the gatekeeper label is set for each namespace within the K8s installation. If an admin creates a namespace without this label, K8s returns the request with an error message and refuses to create it.

Listing 1

Constraint Template

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        # Schema for the `parameters` field
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: 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])
        }

Listing 2

Constraint with Payload

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

For those new to permission control and the various factors that can be used to decide whether to allow or disallow resource creation in Kubernetes, kube-mgmt is probably a little better than the larger Gatekeeper.

Infos