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.

The Author

Martin Gerhard Loschwitz is Cloud Platform Architect at Drei Austria and works on topics such as OpenStack, Kubernetes, and Ceph.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs



Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.

Learn More”>
	</a>

<hr>		    
			</div>
		    		</div>

		<div class=