Policy-as-Code Gates: Blocking Bad Deploys Before They Ship
The problem
Security policy at most organizations lives in a document. "Containers must not run as root." "Images must come from an approved registry." "No privileged containers in production." These rules get written once, reviewed in an audit, and then quietly ignored — because nothing in the deployment path actually checks for them. A misconfigured manifest that violates every rule in the document will deploy exactly as successfully as one that follows all of them.
We hit this directly: a security review found containers running as root, some with privileged access they didn't need, and images pulled from registries nobody had explicitly approved. None of this was malicious — it was just what happens when policy exists as prose instead of as something the pipeline actually enforces. By the time these findings surfaced, the workloads were already live.
Why manual review wasn't enough
The instinctive fix — add a manual security review step before production deploys — didn't scale and didn't match how the org actually shipped software. Reviewers became a bottleneck, review quality varied by who was on call, and the whole model depended on a human catching a YAML misconfiguration by eye, every time, under time pressure. We needed the check to happen automatically, consistently, and early enough that failing it was cheap — a rejected pull request, not an incident report.
The solution: policy gates with OPA and Kyverno
We built a layered policy enforcement setup using Open Policy Agent (OPA) for CI-time checks against Infrastructure-as-Code, and Kyverno as an admission controller enforcing the same intent at the Kubernetes cluster level — so a violation is caught whichever way it tries to reach production.
The policies we enforced were deliberately the highest-leverage ones first:
- No privileged containers — blocks any pod spec requesting privileged mode or unnecessary host access
- Non-root enforcement — rejects containers that don't explicitly set a non-root user
- Approved registry only — images must originate from our internal or explicitly allow-listed registries; anything else is rejected at admission
- Signed image verification — using Sigstore/cosign, Kyverno verifies image signatures at admission time, so an unsigned or tampered image simply cannot run, regardless of how it got built
- Mandatory resource limits — no container without CPU/memory limits defined, closing off a whole class of noisy-neighbor and cost issues alongside the security angle
OPA runs earlier — against Terraform plans and Kubernetes manifests in CI, using Conftest — so violations get caught in a pull request with a clear, specific failure message before anything is ever applied. Kyverno acts as the backstop at the cluster's admission controller, so even a change that bypasses CI (a manual kubectl apply, a hotfix, a misconfigured pipeline elsewhere) still can't land a non-compliant workload. Neither layer alone was sufficient; together they close the gap between "policy that's written" and "policy that's actually true in production."
Results
- Non-compliant manifests started getting rejected automatically at the PR stage, with the specific rule and reason surfaced directly to the engineer — no waiting on a reviewer's availability.
- Privileged and root-running containers in production dropped to effectively zero going forward, since the admission controller makes them structurally impossible to deploy, not just discouraged.
- Unsigned or unverified images became unable to run in the cluster at all, closing a real supply-chain gap rather than relying on trust in the build pipeline alone.
- Security review shifted from "find problems after the fact" to "maintain and extend the policy set" — a meaningfully different, more scalable use of the same team's time.
Lessons learned
- Enforce at more than one layer. CI-time checks are fast feedback for developers; admission-time checks are the actual guarantee. Relying on either alone leaves a gap someone will eventually find.
- Start with rules nobody can reasonably argue with. "No privileged containers" and "must run as non-root" are hard to object to, which built trust in the gate before we introduced anything more opinionated.
- Error messages are part of the policy. A rejected deploy with a vague "denied by policy" message trains people to route around the gate. A rejection that names the exact rule and the exact fix keeps the gate credible.
- Image signing was the highest-value, latest addition. It directly answers "how do we know this image is what we think it is," which matters more every year as supply-chain attacks keep growing in frequency and sophistication.
- A gate without an exception path gets bypassed. We built a narrow, logged, time-boxed override process for legitimate edge cases — without it, people find ways around policy instead of through it.
What's next
We're extending the policy set to cover network policy enforcement (default-deny with explicit allow rules) and tightening the signature verification requirement to include provenance attestation (SLSA-style build provenance), not just a valid signature — moving from "this image wasn't tampered with" to "this image was built by the pipeline we expect, from the source we expect."
If you're building out policy-as-code enforcement with OPA, Kyverno, or a similar stack, I'd like to hear how you're approaching exception handling — get in touch.