A Policy is a group of rules that enforce desired behavior. The module provides a set of common policies out of the box to get started in securing your cluster.
A policy in OPA Gatekeeper is defined by two objects: a ConstraintTemplate
and a Constraint
.
As the name suggests, the ConstraintTemplate
defines the common logic of the policy and the Constraint
takes that logic and creates the actual policy by creating an instance of the template with the right values for the required parameters.
For example, one could have a ConstraintTemplate
to check that a set of labels are present. But, what particular labels to check could be a parameter of the template that should be configured in the Constraint
. Let's say that the Constraint
will check that the label application-group: FURY
should be present for deployments in a defined namespace.
For a more detailed explanation, please refer to Gatekeeper's official documentation.
Below, you can find a list of constraint templates shipped with Kubernetes Fury Distribution:
Rule Name | Description |
---|---|
k8slivenessprobe |
Deny pods that don't declare livenessProbe . |
k8sreadinessprobe |
Deny pods that don't declare readinessProbe . |
k8suniqueingresshost |
Deny duplicated ingress across the cluster. |
k8suniqueserviceselector |
Deny duplicated services selector in the same namespace. |
securitycontrols |
Deny container images with the latest tag, with no limits declared (both CPU and memory), with privilege escalation capability and root containers. |
security_controls_template.yml: it's an all-in-one pod security policy measure composed of several rules. Most of the rules are commented out and provided as examples and to be used as starting point for your own rules. This file can be split into several
ConstraintTemplates
with the counterpart of having to manage an additionalconstraint
/constraintTemplate
resource for each one.
The KFD OPA package provides both
ConstraintTemplates
andConstraints
for each rule out of the box.
All the
Constraints
exclude by default KFD "infra" namespaces (kube-system
,logging
,monitoring
,ingress-nginx
,cert-manager
) to avoid service disruption.
Creating a constraint from a SIGHUP base constraint template is done by declaring a new CRD, for example, the following Constraint
will check that all Deployments
have a liveness probe defined in all namespaces except in kube-system
and deny the creation of the ones that do not have it:
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sLivenessProbe
metadata:
name: liveness-probe
spec:
enforcementAction: deny
match:
excludedNamespaces:
- kube-system
kinds:
- apiGroups: ["apps", "extensions"]
kinds: ["Deployment"]
ℹ️ change enforcementAction
value to dryrun
first and look into the audit logs to understand if your constraint is working as expected without blocking anything. Once you are sure, you can set the Constraint
to deny
and start blocking.
ℹ️ take a look at Gatekeeper Policy Manager if you want to see the status of your constraints (and more) in a nice web UI.
Please refer to the official documentation to better understand how to create
Constraints
.