Policy as Code (OPA, Gatekeeper & Kyverno)

Someone shipped a privileged container

On a Tuesday afternoon a developer needed their pod to mount a host path for a quick debug session. They added securityContext: { privileged: true }, opened a PR, got a thumbs-up from a busy reviewer who skimmed the diff, and merged. The manifest sailed through CI. It deployed to production. Nobody caught it.

A privileged container can escape to the host node. From there it can read other tenants' secrets, tamper with the kubelet, or pivot across the cluster. The control that was supposed to stop this, a human reading a YAML diff at 4pm, is the least reliable control you own. Reviewers get tired, files get long, and privileged: true is one word buried in a 300-line manifest.

The fix is not more discipline. It is policy as code: write the rule once, and let a machine enforce it on every change, forever, without getting tired.

What policy as code actually means

Policy as code is your security and compliance guardrails written as machine-readable rules, version-controlled, tested, and enforced automatically, so the rule is the gate, not a human's memory of the rule.

Every team already has policies: "no privileged containers," "every workload must set resource limits," "images must come from our registry," "every resource needs a cost-center label." The question is only *where those policies live*. In most orgs they live in a Confluence page and in the heads of two senior engineers. Policy as code moves them into a Git repo and into an engine that checks them on every change.

The inspector never has a bad day, never skims, and applies the same code to the billionaire's tower and the corner shop. That consistency, not raw intelligence, is what makes the control trustworthy.

Where the engine sits

A policy engine intercepts a change *before* it takes effect, evaluates it against your rules, and returns a single verdict: allow or deny. There are two natural places to put that gate, in your CI pipeline (before a manifest ever reaches the cluster) and at the Kubernetes admission stage (the last line of defense, catching anything that bypasses CI).

1. 1

   A change is authored

   A developer writes or edits a Kubernetes manifest or a Terraform plan and pushes it.

2. 2

   CI evaluates it first

   A pipeline step runs the policies against the rendered manifests. A violation fails the build, the change never merges. This is the fast feedback loop.

3. 3

   The API server intercepts the apply

   If something reaches the cluster anyway (a kubectl from a laptop, a Helm install, a compromised pipeline), the admission webhook fires before the object is persisted.

4. 4

   The engine returns a verdict

   The policy engine evaluates the request against every matching policy and answers allow or deny in milliseconds.

5. 5

   Allow creates, deny blocks

   On allow, the resource is created. On deny, the user gets a clear message, `privileged containers are not allowed`, and nothing is created.

OPA / Gatekeeper vs Kyverno

Two tools dominate Kubernetes policy enforcement, and the choice mostly comes down to one question: are you willing to learn a policy language? OPA (Open Policy Agent) is a general-purpose policy engine that uses a language called Rego; Gatekeeper is the project that wires OPA into Kubernetes admission control. Kyverno is Kubernetes-native and writes policies as plain YAML, no new language to learn.

A real policy: deny privileged pods

Here is the rule that would have stopped our Tuesday incident, written as a Kyverno policy. It is just a Kubernetes resource, you kubectl apply it like anything else, and from that moment every pod is checked.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce   # Audit while testing, Enforce to block
  background: true                    # also scan existing resources
  rules:
    - name: privileged-containers
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            =(securityContext):
              =(privileged): "false"
            containers:
              - =(securityContext):
                  =(privileged): "false"

The same intent in Rego (for OPA/Gatekeeper) reads as logic rather than a pattern. A violation is produced for any container that asks for privilege:

package kubernetes.admission

violation[{"msg": msg}] {
  container := input.review.object.spec.containers[_]
  container.securityContext.privileged == true
  msg := sprintf("container %v runs privileged; not allowed", [container.name])
}

The same shape covers the boring-but-critical rules too. Requiring a cost-center label is a Kyverno validate that asserts the key exists under metadata.labels, a two-line change that makes every untagged resource impossible to create.

Catch it in CI, not just at the cluster

Admission control is your safety net, but the *fastest* feedback is in CI, before a change is ever merged. Running the same policies against rendered manifests in the pipeline means a developer sees privileged containers are not allowed in their PR check, not after a failed deploy. Same rule, earlier gate.

name: policy-check
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Render manifests
        run: helm template ./chart > /tmp/rendered.yaml
      - name: Run Kyverno policies
        run: |
          kyverno apply ./policies/ \
            --resource /tmp/rendered.yaml \
            --audit-warn=false   # nonzero exit on any failure

The same idea applies to infrastructure. With OPA/conftest you can gate a Terraform plan: render terraform show -json plan.out and let Rego deny, say, an S3 bucket without encryption or a security group open to 0.0.0.0/0. Bad infrastructure-as-code never reaches apply. This is exactly the kind of drift that a Cloud Security Posture Management (CSPM) tool would otherwise find *after* it is already running and exposed.

Preventive vs detective enforcement

Every control is one of two kinds, and you need both. Preventive controls stop the bad thing from ever happening, a CI gate that fails the build, an admission webhook that denies the request. Detective controls find the bad thing that already happened, a background scan that flags running pods which violate a policy you added later.

Preventive is stronger but stricter: if your policy is wrong, you block legitimate work and people route around you. Detective is safer to roll out but reactive: by the time it alerts, the privileged container has been running for an hour. The mature pattern is to start detective, then graduate to preventive. Deploy a policy in audit mode, watch what it *would* have blocked for a week, fix the false positives, then flip it to enforce. In Kyverno that is one field: validationFailureAction: Audit becomes Enforce.

Common mistakes that cost hours

1. Audit-only forever. Teams deploy in audit mode "to be safe" and never flip to enforce. The guardrail looks present but blocks nothing, the privileged container still ships. Set a date to enforce when you deploy.
2. No policy tests. A policy is code; untested code lies. Without kyverno test / opa test fixtures you ship a regex that matches nothing, or a Rego rule that blocks every pod. Commit tests with the policy.
3. Over-strict blocking on day one. Turning on twenty enforce-mode policies at once breaks deploys org-wide and burns your credibility in an afternoon. Roll out one policy at a time, audit first.
4. No exception path. Real systems have legitimate edge cases. If the only way past a policy is to disable it, people disable it. Build a scoped, reviewed exception mechanism (a namespace label, an annotation) so the policy survives contact with reality.
5. Vague denial messages. validation error: pattern mismatch tells a developer nothing. A good message names the rule and the fix: privileged containers are not allowed; remove securityContext.privileged.
6. CI-only or admission-only. CI alone misses anything applied outside the pipeline; admission alone gives slow feedback. Run the same policies in both places.

Takeaways

Where to go next

Policy as code is most powerful once you understand the cluster it is guarding and the broader security posture it fits into. Build the foundation, then add the guardrails.

• Get hands-on with the API server and admission flow in the kubectl lab.
• See how these guardrails fit a real cluster in Kubernetes in Production: Beyond the Tutorial.
• Pair preventive policy with detective scanning in Cloud Security Posture Management (CSPM).
• Put it all together on the DevOps Engineer career path.