TL;DR: A Policy Engine says what configurations are allowed.

In this post, I will explain the concept of a Policy Engine, followed by Policy as Code (PaC) and the Open Policy Agent (OPA).

Policy Engine

A Policy Engine is a system that evaluates resource requests against defined rules and determines what configurations are allowed.

Instead of checking identity or user permissions (which is handled by Role-Based Access Control, or RBAC), a Policy Engine inspects the resource payload itself to determine whether it adheres to operational and security guardrails.

In Kubernetes, policies are enforced through the API Server’s Admission Control pipeline via two primary behaviors:

  • Mutating Admission: Modifies an incoming resource before it is accepted (e.g., automatically injecting default resource requests/limits or sidecar containers).
  • Validating Admission: Inspects an incoming resource and accepts or rejects it (e.g., blocking containers configured to run as root or using the :latest image tag).

Kubernetes includes built-in ValidatingAdmissionPolicy and MutatingAdmissionPolicy controllers using the Common Expression Language (CEL). External policy engines integrate directly with the Control Plane using dynamic admission webhooks.

Everything as Code (XaC)

Infrastructure as Code (IaC) established the paradigm of declaring infrastructure state in code and relying on execution engines to reach that state.

Everything as Code (XaC) extends this concept across all operational domains. Instead of maintaining security guidelines, architectural rules, and compliance requirements in passive documents or wiki pages, we express those rules directly as version-controlled code.

Policy as Code (PaC)

Policy as Code (PaC) is the practice of expressing operational guardrails, compliance rules, and security constraints as declarative code rather than relying on manual checklists or code reviews.

Stored in Git ──► Automatically Enforced ──► Fully Testable

By storing policy logic in Git, policies benefit from standard software engineering practices:

  • Auditable: Every rule change is versioned, reviewed, and tracked via pull requests.
  • Automated: Policies run continuously in CI/CD pipelines and at API runtime.
  • Testable: Rules are validated against unit test suites before being applied to live clusters.

How to Apply PaC in Kubernetes

Policy as Code is integrated into Kubernetes at the Control Plane level during the API request lifecycle across three phases:

1. Policy Declaration

Policies are written as declarative custom resources and stored in version-controlled repositories.

  • OPA Gatekeeper uses ConstraintTemplate and Constraint resources.
  • Kyverno uses ClusterPolicy and Policy resources.

These files live in Git alongside application manifests and are synchronized to the cluster using GitOps tools such as Argo CD or Flux.

2. Policy Integration

External policy engines integrate with the kube-apiserver by registering webhooks:

  1. Mutating Phase: Registered mutating webhooks modify incoming specifications before validation.
  2. Validating Phase: Registered validating webhooks evaluate the final payload against active policies and return an explicit allow or deny decision.

Per Kubernetes specification, mutating admission always executes prior to validating admission.

3. Runtime Verification

When a manifest is submitted via kubectl, CI/CD pipelines, or Helm, it traverses the Control Plane pipeline:

Request
   │
   ▼
API Server
   │
   ├── Authentication           (Who are you?)
   │
   ├── Authorization / RBAC     (Are you allowed to perform this action?)
   │
   ├── Mutating Admission       (Modify/default payload specifications)
   │
   ├── Validating Admission     (Does this payload satisfy policy rules?)
   │
   └── Persistence
          │
          ▼
         etcd

If a validating policy engine rejects the request during admission control, the API server returns an error directly to the client. The request fails instantly, and etcd remains untouched.

Open Policy Agent (OPA)

The Open Policy Agent (OPA) is an open-source, general-purpose policy engine developed by the CNCF. It uses a declarative query language called Rego to evaluate rules.

Because OPA is domain-agnostic, it can evaluate JSON/YAML inputs for microservices, CI/CD pipelines, Terraform plans, or Kubernetes manifests.

OPA Gatekeeper

To run OPA natively inside Kubernetes, the community uses OPA Gatekeeper. Gatekeeper provides a Kubernetes-native integration layer using Custom Resource Definitions (CRDs):

  • ConstraintTemplates: Declare the reusable Rego logic and define the parameter schema for a policy (e.g., defining logic that forbids root containers).
  • Constraints: Instantiate the template with specific parameters and targets (e.g., applying the root restriction rule strictly to Pods in the production namespace).

In addition to evaluating requests at admission time, Gatekeeper continuously scans and audits existing resources in the cluster to report on policy violations that were created prior to rule deployment.

For more reference Open Policy Agent (OPA) Documents

Back to Certified Cloud Native Platform Engineering Associate Preparation