Policy Enforcement on Kubernetes with Open Policy Agent (OPA)

Note: The original post associated with this URL contained unrelated market-research content and did not cover the stated topic. The article below is an independent, accurate technical explanation of policy enforcement on Kubernetes with Open Policy Agent.

What Is Open Policy Agent?

Open Policy Agent (OPA) is a general-purpose, open-source policy engine maintained by the Cloud Native Computing Foundation (CNCF). It decouples policy decisions from application and platform code, allowing teams to express, enforce, and audit rules in a single, consistent way across microservices, CI/CD pipelines, API gateways, and — most relevantly for DevOps engineers — Kubernetes clusters.

Policies in OPA are written in Rego, a purpose-built declarative language that evaluates structured data (typically JSON) against a set of rules and returns a decision. That decision can be as simple as allow = true or as rich as a detailed object listing violations.

Why Kubernetes Needs Policy Enforcement

Kubernetes RBAC controls who can perform an action, but it does not control what configuration is allowed. Without additional policy enforcement, a developer with permission to create a Deployment can:

• Run containers as root
• Pull images from untrusted registries
• Omit resource limits, starving other workloads
• Mount the host filesystem or expose the host network
• Skip required labels that your monitoring or cost-allocation tooling depends on

OPA fills this gap by acting as a Kubernetes Admission Controller: every resource creation or update request passes through OPA before it is persisted to etcd, and OPA can approve, reject, or mutate it.

How OPA Integrates with Kubernetes

The Admission Webhook Model

Kubernetes exposes two webhook admission controller types:

• ValidatingAdmissionWebhook — can approve or reject a request.
• MutatingAdmissionWebhook — can modify the request payload before it is persisted.

OPA (or its Kubernetes-native distribution, OPA Gatekeeper) registers itself as one or both of these webhooks. When the API server receives a request, it serializes the object into an AdmissionReview JSON payload and forwards it to OPA over HTTPS. OPA evaluates the payload against loaded policies and returns an AdmissionResponse indicating whether to allow or deny.

OPA Gatekeeper vs. Standalone OPA

Standalone OPA requires you to manage the webhook registration, sidecar deployment, and policy loading yourself. Policies are typically pushed to OPA via its REST API or bundled and served from a remote bundle server.

OPA Gatekeeper is a Kubernetes-native OPA distribution that introduces two Custom Resource Definitions (CRDs):

• ConstraintTemplate — defines a new CRD and embeds the Rego logic.
• Constraint — an instance of that CRD that specifies which resources and namespaces the policy applies to and what parameters it uses.

Gatekeeper also adds an audit controller that continuously evaluates already-existing resources against current policies and reports violations, closing the gap between admission time and drift detection.

Writing Policies in Rego

Rego is a logic-based query language. The key idea is that you write rules that define when something is true. For admission control, you typically define a violation rule that produces a message when a constraint is breached.

Example: Require Resource Limits

The following Rego snippet (suitable for a Gatekeeper ConstraintTemplate) denies any container in a Pod that does not declare CPU and memory limits:

package kubernetes.admission

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.cpu
  msg := sprintf("Container '%v' must specify a CPU limit", [container.name])
}

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container '%v' must specify a memory limit", [container.name])
}Code language: CSS (css)

Example: Restrict Image Registries

This rule denies Pods that reference images from registries not in an approved list:

package kubernetes.admission

approved_registries := {"registry.example.com", "gcr.io/my-project"}

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  image := container.image
  not any_approved(image)
  msg := sprintf("Image '%v' is not from an approved registry", [image])
}

any_approved(image) {
  registry := approved_registries[_]
  startswith(image, registry)
}Code language: JavaScript (javascript)

Deploying OPA Gatekeeper on Kubernetes

The fastest way to get Gatekeeper running is to apply the official release manifest. Always check the Gatekeeper GitHub repository for the current stable release and recommended installation method.

# Replace <version> with the current stable Gatekeeper release tag
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/<version>/deploy/gatekeeper.yamlCode language: PHP (php)

After installation, Gatekeeper runs in the gatekeeper-system namespace. You can verify it is healthy:

kubectl get pods -n gatekeeper-systemCode language: JavaScript (javascript)

Creating a ConstraintTemplate and Constraint

Below is a minimal ConstraintTemplate that enforces required labels, followed by a Constraint that activates it on all namespaces:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredlabels
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredLabels
      validation:
        openAPIV3Schema:
          properties:
            labels:
              type: array
              items: string
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredlabels

        violation[{"msg": msg}] {
          provided := {label | input.review.object.metadata.labels[label]}
          required := {label | label := input.parameters.labels[_]}
          missing := required - provided
          count(missing) > 0
          msg := sprintf("Missing required labels: %v", [missing])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: require-team-label
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["team"]Code language: PHP (php)

Testing Policies Before Deployment

OPA ships with a built-in test framework. Write unit tests alongside your Rego files and run them with:

opa test ./policies/ -v

The OPA Playground (play.openpolicyagent.org) is also a useful browser-based environment for iterating on Rego logic without a cluster. Gatekeeper additionally provides a gator CLI tool for running Gatekeeper-specific constraint tests in CI pipelines before policies ever reach the cluster.

Audit Mode and Dry-Run Enforcement

Rolling out new policies directly to a production cluster is risky. Gatekeeper supports an enforcementAction field on each Constraint:

• deny — rejects non-compliant resources at admission time.
• warn — allows the request but returns a warning message to the user (Kubernetes 1.19+).
• dryrun — records violations in the constraint’s status field without blocking anything.

Start with dryrun to understand the blast radius of a new policy, then graduate to warn, and finally to deny once you have fixed or exempted all legitimate violators.

Best Practices

• Store policies as code — keep ConstraintTemplate and Constraint YAML files in version control alongside your application manifests.
• Gate policies in CI — use opa test and gator verify in pull-request pipelines so policy regressions are caught before merging.
• Use namespaced exemptions carefully — Gatekeeper allows excluding namespaces via the constraint’s match block; document every exemption.
• Monitor audit violations — scrape Gatekeeper’s Prometheus metrics and alert when the violation count for a deny-mode constraint is non-zero for existing resources.
• Limit webhook failure policy — set failurePolicy: Fail for security-critical policies and ensure Gatekeeper is highly available; use failurePolicy: Ignore only for non-critical advisory checks.
• Separate policy development from cluster administration — consider a dedicated policy-as-code repository with its own review and approval workflow.

Summary

Open Policy Agent and its Kubernetes-native distribution Gatekeeper provide a powerful, auditable, and GitOps-friendly way to enforce organizational standards across Kubernetes clusters. By expressing policies in Rego, storing them as code, and using Gatekeeper’s audit and enforcement modes progressively, platform engineering teams can prevent misconfiguration at admission time while maintaining full visibility into policy compliance across the fleet.