How to Enforce Security Policies in Kubernetes with OPA

What Is OPA and Why Does Kubernetes Need It?

Open Policy Agent (OPA) is an open-source policy engine that lets you enforce security policies in Kubernetes using a declarative language called Rego. Instead of manual reviews and scattered YAML checks, OPA becomes the central policy engine that evaluates every request to your Kubernetes cluster and blocks anything that violates your Kubernetes security policies.

Kubernetes is powerful, but by default it is permissive. Without enforced Kubernetes security policies, nothing stops a developer from deploying a container that runs as root, pulling images from untrusted registries, exposing internal apps to the internet, or skipping resource limits entirely.

RBAC controls who can do things in Kubernetes. OPA controls what is allowed to exist in the cluster. That distinction is the foundation of policy as code, and it is exactly why enforcing security policies in Kubernetes with OPA has become the industry standard.

How Does OPA Enforce Security Policies in Kubernetes?

OPA enforces Kubernetes security policies through the Kubernetes Admission Controller pipeline. Here is exactly how the request flow works:

1. A user or CI/CD pipeline sends a request to the Kubernetes API server, for example when applying a new deployment.
2. The API server authenticates and authorizes the request using RBAC.
3. Before the object is saved to the cluster database (etcd), the API server forwards it to the admission webhooks.
4. OPA, running via Gatekeeper, evaluates the request against your Rego security policies.
5. If the request violates a policy, it is rejected with a clear error message. If it passes, the object is admitted to the Kubernetes cluster.

The key insight: OPA enforces security policies in Kubernetes before a bad configuration ever reaches your cluster. Prevention, not detection.

OPA vs OPA Gatekeeper: What Is the Difference?

OPA Gatekeeper is the Kubernetes-native way to run OPA. While standalone OPA can enforce policies anywhere, including APIs, Terraform, and CI/CD pipelines, Gatekeeper wraps OPA with Kubernetes-specific capabilities:

1. CRD-based policies: You define Kubernetes security policies as native Kubernetes resources called ConstraintTemplates and Constraints, so they can be managed like any other cluster object.
2. Audit mode: Gatekeeper continuously scans existing cluster resources for policy violations, not just new requests.
3. Flexible enforcement actions: Every policy can be set to deny, warn, or dry-run mode.
4. Cluster state awareness: You can write policies that reference other objects already running in the cluster.

For enforcing security policies in Kubernetes in 2026, Gatekeeper is the recommended approach.

Step-by-Step: Enforcing Your First Kubernetes Security Policy with OPA Gatekeeper

Step 1 — Install OPA Gatekeeper. Gatekeeper is installed by applying its official deployment manifest from the open-policy-agent GitHub repository using kubectl. Once applied, verify that the Gatekeeper pods are running in the gatekeeper-system namespace.

Step 2 — Create a ConstraintTemplate. A ConstraintTemplate holds the actual policy logic written in Rego. For example, a template called K8sRequiredLabels can define a rule stating that if a required label is missing from a resource, the request generates a violation with a message like "Missing required label: team."

Step 3 — Apply a Constraint. The Constraint is where you activate the template against specific resources. For instance, you can create a Constraint that targets all Namespaces and requires them to carry a label called "team."

Once both are applied, any Namespace created without the team label is instantly rejected at admission time. That is OPA enforcing a Kubernetes security policy in real time.

5 Essential Kubernetes Security Policies to Enforce with OPA

1. Block privileged containers: Deny any pod that requests privileged mode in its security context.
2. Enforce trusted image registries: Only allow container images pulled from your approved internal registry.
3. Require resource limits: Reject deployments that do not define CPU and memory limits, preventing noisy-neighbor issues.
4. Disallow root users: Enforce that all workloads run as non-root users.
5. Restrict host networking and host paths: Block pods from using host networking or mounting sensitive host directories.

These five OPA policies alone eliminate the majority of common Kubernetes misconfigurations flagged in security audits.

If you want to master OPA, Gatekeeper, and real-world Kubernetes security hands-on, check out this industry-focused DevOps Course that covers policy as code from scratch to production.

Best Practices for Enforcing Security Policies in Kubernetes with OPA

1. Start in dry-run mode. Audit violations first, then switch to deny once teams have remediated existing issues.
2. Version-control every policy. Treat Rego policies like application code with pull requests, reviews, and GitOps deployment.
3. Test policies before shipping. Use OPA unit tests and tools like Conftest to validate policies in CI before they touch the cluster.
4. Use exemptions sparingly. Excluding system namespaces like kube-system is fine, but per-team exceptions erode your Kubernetes security posture.
5. Monitor Gatekeeper metrics. Track violation counts, webhook latency, and audit results in Prometheus and Grafana to keep policy enforcement healthy.

FAQs: Kubernetes Security Policies with OPA

What is OPA used for in Kubernetes?

OPA is used to enforce security policies in Kubernetes at admission time. It validates every resource against custom rules written in Rego and rejects anything non-compliant before it enters the cluster.

Is OPA Gatekeeper free?

Yes. OPA and Gatekeeper are both open-source CNCF graduated projects and completely free to use.

What replaced Pod Security Policies in Kubernetes?

Pod Security Policies (PSPs) were removed in Kubernetes 1.25. OPA Gatekeeper, along with Kyverno and the built-in Pod Security Admission, are the modern replacements — with Gatekeeper offering the most flexibility for custom security policies.

OPA vs Kyverno: which is better for Kubernetes security policies?

Kyverno is simpler because policies are written in YAML, while OPA uses Rego, which is more powerful and works beyond Kubernetes too. Teams needing one policy engine across cloud, CI/CD, and Kubernetes usually choose OPA.