OPA Gatekeeper for Kubernetes
As you know Kubernetes is a wornderful tool for Container orchestration. It have lot of features which helps to manage the applications or workloads. When using Kubernetes for a Enterprise, managing the security policies for deploying or managing applications will be little challenging. OPA Gatekeeper helps to overcome this challenge. As the name suggest it functions as a gatekeeper which intercepts all API requeststo Kubernetes using admission controller webhooks before persisting into etcd.
Introduction
Before seeing how gatekeeper works, we will see different phases of API requests in Kubernetes which helps to understand the Gatekeeper behaviour.
All API request to Kubernetes will go into different phase before persisting the data in etcd. The first phase is authentication and authorization. Once the request is authenticated and authorized, mutatuion controller will mutate the request based on its webhook configuration and then validated by validation controller using its webhook configuration and will be persisted to ETCD. The request will not be persisted to etcd, if it fails at any of the phase.
Gatekeeper is using the same approach for its functionality and its two primary task are,
- Mutation webhook to mutate the API requests using MutatingAdmissionWebhook controller
- Validation webhook to validate the API requests using ValidatingAdmissionWebhook controller
Installation
There are different options available for installing Gatekeeper and are pretty straightforward.
- Deploy using kubectl
- Deploy HEAD using Make
- Deploy using Helm
Use kubectl if you are exploring Gatekeeper for the first time. Helm deployment is the better approach for production grade as it will give felxibility to configure different options and other benefits such as rollback etc.
Helm Install
# Default installation
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm install gatekeeper/gatekeeper --name-template=gatekeeper --namespace gatekeeper-system --create-namespace
# Update chart with values.yaml
helm upgrade -f values.yaml gatekeeper -n gatekeeper-system gatekeeper/gatekeeper
# Check the helm deployment history
helm history gatekeeper -n gatekeeper-system
# Check the helm deployment status
helm status gatekeeper -n gatekeeper-systemDetailed steps for installation is available here.
Gatekeeper Features
The two primary features available in Gatekeeper are,
- Mutation
- Validation
Mutation
Mutation to API requests can be done in three ways and are listed below,
- AssignMetadata - Changes the metadata section of a resource
- Assign - Changes everything outside of the metadata section
- ModifySet - Adds or removes entries from a list, such as the arguments to a container
Few examples of mutation are given below. Likewise we can do different types of mutation.
Get DevOps Mate’s stories in your inbox
Join Medium for free to get updates from this writer.
Setting owner as admin of all Namespace
apiVersion: mutations.gatekeeper.sh/v1
kind: AssignMetadata
metadata:
name: demo-annotation-owner
spec:
match:
scope: Namespaced
location: "metadata.labels.owner"
parameters:
assign:
value: "admin"Setting imagePullPolicy of all containers to Always in all namespaces except namespace system
apiVersion: mutations.gatekeeper.sh/v1
kind: Assign
metadata:
name: demo-image-pull-policy
spec:
applyTo:
- groups: [""]
kinds: ["Pod"]
versions: ["v1"]
match:
scope: Namespaced
kinds:
- apiGroups: ["*"]
kinds: ["Pod"]
excludedNamespaces: ["system"]
location: "spec.containers[name:*].imagePullPolicy"
parameters:
assign:
value: AlwaysRemoving --alsologtostderr argument from all containers in a pod
apiVersion: mutations.gatekeeper.sh/v1
kind: ModifySet
metadata:
name: remove-err-logging
spec:
applyTo:
- groups: [""]
kinds: ["Pod"]
versions: ["v1"]
location: "spec.containers[name: *].args"
parameters:
operation: prune
values:
fromList:
- --alsologtostderrValidation
Validating the API request using Gatekeeper requires two components,
- ConstraintTemplate
- Constraint
ConstraintTemplate
Constraint template actually contains the logic (piece of code written in Rego) to validate the request and the Constraint reference. Below example constraint template validate the request conatins all labels described by the constraint. In the below template, the rego section contains the logic, which checks the label of api request input.review.object.metadata.labels[label] with the parameter input.parameters.labels[_] passed from Constraint K8sRequiredLabels.
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])
}Constraint
Constraints are used to inform Gatekeeper which ConstraintTemplate to be enforced, and how. Below example enforce K8sRequiredLabels ConstraintTemplate for all Namespace to have the labels gatekeeper.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-gk
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["gatekeeper"]As mentioned above Gatekeeper is a wonderful tool for managing the polices of kubernetes cluster and the workloads deployed to it. When using it effectively it will give lot of benefits.







