implementing-policy-as-code-with-open-policy-agent

name	implementing-policy-as-code-with-open-policy-agent
description	This skill covers implementing Open Policy Agent (OPA) and Gatekeeper for policy-as-code enforcement in Kubernetes and CI/CD pipelines. It addresses writing Rego policies, deploying OPA Gatekeeper as a Kubernetes admission controller, testing policies in development, and integrating policy evaluation into deployment pipelines.
domain	cybersecurity
subdomain	devsecops
tags	["devsecops","cicd","opa","gatekeeper","policy-as-code","kubernetes","secure-sdlc"]
version	1.0.0
author	mahipal
license	Apache-2.0
nist_ai_rmf	["GOVERN-1.1","MEASURE-2.7","MANAGE-3.1"]
nist_csf	["PR.PS-01","GV.SC-07","ID.IM-04","PR.PS-04"]

Implementing Policy as Code with Open Policy Agent

When to Use

• When enforcing organizational security policies across Kubernetes clusters programmatically
• When requiring admission control that blocks non-compliant resources from being created
• When implementing policy governance that can be version-controlled, tested, and audited
• When standardizing security rules across multiple clusters and environments
• When needing a flexible policy engine that extends beyond Kubernetes to APIs and CI/CD

Do not use for vulnerability scanning (use Trivy/Checkov), for runtime threat detection (use Falco), or for network policy enforcement (use Kubernetes NetworkPolicy or Calico).

Common Misconfigurations & Verification

A policy engine left in advisory mode enforces nothing:

• Constraints stuck in enforcementAction: warn (or dryrun). Warn/dryrun only annotate the audit log; non-compliant resources are still admitted. Flip to enforcementAction: deny once the remediation window closes, and verify with a test apply.
• conftest exit code ignored in CI. conftest test returns non-zero on a deny[...] rule, but a trailing || true, continue-on-error: true, or using only warn[...] rules means the pipeline passes regardless. Use deny rules for hard gates and let the non-zero exit fail the job.
• Constraint match: too narrow. If match.kinds omits Deployment/StatefulSet/DaemonSet (only Pod), workloads bypass the policy entirely. Over-broad excludedNamespaces (beyond kube-system/gatekeeper-system) also creates blind spots.
• Gatekeeper webhook not actually intercepting (failurePolicy Ignore, or template/constraint not applied) so admission silently allows everything.
• conftest pointed at the wrong --policy dir or --parser (e.g. HCL not parsed) → zero rules evaluated, green by accident.

Concrete verification: kubectl apply a Pod that clearly violates a deny constraint (a privileged: true container, or a container with no CPU/memory limit) and confirm the API server with the policy's violation message. In CI, run on a manifest using and confirm the job .