The latest release of the Kubernetes Policy Controller Gatekeeper integrates with the Open Policy Agent (OPA) Constraint Framework to enable shareable and enforceable policies. The Open Policy Agent Gatekeeper project is a collaboration between Google, Microsoft, RedHat, and Styra, and is designed to help enforce policies and strengthen governance in Kubernetes environments. Gatekeeper 3.0 takes greater advantage of OPA Constraints to offer users the ability to declare policies, share constraint templates, and audit resources for policy violations.
The motivation for Gatekeeper was to create a way of customizing Kubernetes admission control via configuration, instead of code. Gatekeeper is meant to address compliance requirements such as requiring that all pods having resource limits, ingress names being globally unique, or all images are only pulled from the designated repositories. Gatekeeper removes this logic from the API code by defining policies in configuration and enforcing policies with the OPA.
OPA is a Cloud Native Computing Foundation incubation project that provides an open source, general-purpose policy engine. Policy management is centralized in OPA, creating a unified, context-aware solution applied across the application stack.
The latest release of Gatekeeper provides additional functionality by changing how OPA is used with the Kubernetes policy controller. The admission controller has been integrated with the OPA Constraint Framework to enforce Custom Resource Definition (CRD) based policies and policy sharing. Compared to using OPA with its sidecar kube-mgmt, as implemented in Gatekeeper 1.0, Gatekeeper 3.0 introduces an extensible, parametrized policy library, native Kubernetes CRDs for instantiating and extending the policy library, and audit functionality.
The OPA Constraint Framework introduces the concept of constraints, which is a declaration of requirements that the system must satisfy. Before creating constraints, a constraint template is required, which describes that logic that enforces the constraint and the parameters that can be passed to the constraint. Once a constraint template has been deployed to a Kubernetes cluster, an admin can create individual constraint CRDs as defined by the constraint template.
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
name: ns-must-have-finance
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Namespace"]
parameters:
labels: ["finance"]
Example Constraint CRD that requires the label finance on all namespaces, from the Kubernetes Blog
Constraints are written in Rego, a declarative programming language that extends Datalog to support structured document models such as JSON. Rego is a query language, and Rego queries are assertions on data stored in OPA.
Audits enable periodic evaluations of Kubernetes resources against constraints to detect pre-existing misconfigurations. Gatekeeper stores audit results as violations listed in the status field of the relevant constraint.
Future work on Gatekeeper will focus on providing support for mutation scenarios, such as adding default tagging when resources are created, as well as making data outside of the cluster available for admission decisions. Dry runs and extensions to the audit functionality will also be added so that users can better understand how policy changes will affect an existing cluster.
To learn more about the Gatekeeper project, visit the Github repository. To provide feedback and contribute to the development of Gatekeeper, join the #kubernetes-policy channel on OPA Slack.
