Rego Policy Language
Describes Rego, the policy language used to write OPA Gatekeeper template objects in HPE Ezmeral Runtime Enterprise.
Rego Policy Language
Organizing Template and Constraint Objects
- Combine multiple template and constraint objects into one YAML file.
This “one big YAML file” becomes a collection of policies – or one big
policy – that includes pairs of templates and constraints. See this example
(
onebigpolicy.yaml
). - Create a directory of policies with each policy represented as a single YAML file that contains a pair of constraint and template objects. See this example directory.
View sample YAML policies:
https://github.com/open-policy-agent/gatekeeper-library/tree/master/library/general
Example Policy
The following example policy (allowedrepo-policy.yaml
) validates all
pods in the cluster and ensures that they come from the
openpolicyagent
repo.
In this example, the constraint object appears first, followed by the template object. The template object contains logic for how the policy should be validated. In the template object, lines of code in bold face indicate Rego commands. The constraint object contains the values that the template will validate against.
openpolicyagent
repo is detected, an
error is generated. ---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
name: repo-is-openpolicyagent
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
namespaces:
- "default"
parameters:
repos:
- "openpolicyagent"
---
apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
name: k8sallowedrepos
annotations:
description: Requires container images to begin with a repo string from a specified
list.
spec:
crd:
spec:
names:
kind: K8sAllowedRepos
validation:
# Schema for the `parameters` field
openAPIV3Schema:
properties:
repos:
type: array
items:
type: string
targets:
- target: admission.k8s.gatekeeper.sh
rego: |
package k8sallowedrepos
violation[{"msg": msg}] {
container := input.review.object.spec.containers[_]
satisfied := [good | repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
not any(satisfied)
msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
}
violation[{"msg": msg}] {
container := input.review.object.spec.initContainers[_]
satisfied := [good | repo = input.parameters.repos[_] ; good = startswith(container.image, repo)]
not any(satisfied)
msg := sprintf("container <%v> has an invalid image repo <%v>, allowed repos are %v", [container.name, container.image, input.parameters.repos])
}
Policy Enforcement Example
# kubectl apply -f disallowedcontainerlimit.yaml
Error from server ([denied by container-image-must-have-digest] container <opa> uses an image with a digest <openpolicyagent/opa:0.9.2>
[denied by container-must-have-limits] container <opa> memory limit <2Gi> is higher than the maximum allowed of <1Gi>
[denied by must-have-probes] Container <opa> in your <Pod> <opa-disallowed> has no <readinessProbe>
[denied by must-have-probes] Container ,opa> in your <Pod> <opa-disallowed> has no <livenessProbe>): error when creating "disallowedcontainerlimit.yaml": admission
webhook "validation.gatekeeper.sh" denied the request: <denied by container-image-must-have-digest] container <opa> uses an image without a digest <openpolicyagent/opa:0.9.2>
[denied by container-must-have-limits] container <opa> memory limit <2Gi> is higher than the maximum allowed of <1Gi>
[denied by must-have-probes] Container <opa> in your <Pod> <opa-disallowed> has no <readinessProbe>
[denied by must-have-probes] Container <opa> in your <Pod> <opa-disallowed> has no <livenessProbe>
Overly Restrictive Policies
As with any security system, it is possible to create policies that interfere with
normal system operations and that result in unwanted behavior. For example, when
creating policies for HPE Ezmeral Runtime Enterprise, setting the root file
system directory to “read only” results in numerous errors, because fsmount
daemonset pods must have write access to the /opt/bluedata/share
directory on all of the Kubernetes hosts and the
/opt/bluedata/share
directory inside the pod. One such error is
the failure to configure a Kubernetes Web Terminal.
To view a list of policy violations and denials that are occurring in a cluster, see: Viewing Policy Violations.
Alternatively, to display a JSON-formated list of policy violations that are occurring in a cluster, enter the following command:
kubectl get constraints -o json