Policy-as-Code Philosophy

Nine project certifications sit on this course's shelf, and exactly one of them touches policy: KCA, tested against Kyverno in exhaustive YAML detail. That narrowness is deliberate — and it leaves a gap this page exists to close. Every policy engine guarding a Kubernetes cluster, whatever badge is printed on it, is answering the same design question — reject the request outright, quietly rewrite it, or spawn a companion object in response — and answering it at exactly one moment, before anything is ever written to etcd. This page steps back from Kyverno's specific fields to the model underneath it: the admission-control mechanics every engine shares, why a policy earns the same scrutiny as production code, and the genuine philosophical fork between Kyverno's Kubernetes-shaped YAML and OPA/Gatekeeper's general-purpose Rego. The fork matters past KCA — it's the difference between a platform that runs one guardrail tool by accident and one that chose it on purpose.

One doorway, two verbs: the admission-control model

☺ Like you're 10: The cluster's front door has two little windows in it — one where a guard can hand back your form with something already filled in, and one where a guard just says yes or no. Everything passes both windows, in that order, before it's let inside.

Before any policy engine gets a say, ordinary Kubernetes authentication and authorization already ran — is this identity real, and is it allowed to attempt this verb on this resource at all? That's RBAC territory, covered at real depth by the sibling Kubernetes course's KCSA and CKS, and this course assumes it rather than re-teaching it. What a policy engine adds is a second gate, sitting after authorization and before persistence, and Kubernetes splits that gate into exactly two phases every object passes through in order. Mutating admission runs first and may rewrite the object — inject a default, add a label, patch in a missing field. Validating admission runs second, sees whatever the mutating phase already changed, and returns a final verdict: allowed, or rejected with a message. A rejection at either phase means the object is never written to etcd at all — there's nothing to roll back, because nothing happened.

Why the rule belongs in a pull request, not a person's memory

☺ Like you're 10: A rule that only lives in one person's head has exactly one point of failure — that person being on vacation, in a different meeting, or simply wrong that day.

A policy engine doesn't just enforce a rule — it encodes, in a form a machine will obey unsupervised, forever, a claim about what's dangerous. That claim deserves at least the scrutiny given to the application code it governs, and arguably more, because a mistake in it fails in one of two expensive directions: too loose, and it becomes a false sense of safety nobody notices until an incident; too strict, and it becomes an outage that looks like the platform itself broke. Writing the rule as code and putting it in Git is what makes that scrutiny actually happen instead of remaining a good intention. Git gives a policy change a diff a reviewer can read in thirty seconds instead of a change nobody saw coming; it gives it attribution — who decided privileged containers were fine in this one namespace, and when; and it gives it a revert as cheap as reverting any other commit, instead of someone manually reconstructing what the rule used to say. Both engines this page compares ship a real test runner for exactly this reason — kyverno test and opa test both let a rule prove, in CI, that it still catches what it claims to catch before it's ever trusted against a live cluster.

The other half of the discipline is what happens once a policy CRD is merged: it's just another Kubernetes object, so a GitOps controller reconciles it exactly the way it reconciles a Deployment — drift back to what Git says, on the same schedule, with the same audit trail. A policy applied once by hand from a laptop and never touched again isn't policy as code; it's a screenshot of a good intention that Git never got to see.

Two philosophies wearing the same badge

☺ Like you're 10: The carved door and the memorizing guard from the analogy above are a real engineering choice, not just a story — and most platforms only ever build one of them.

Kyverno's premise is that policy is a Kubernetes resource, full stop. A ClusterPolicy is ordinary YAML that reads almost like the object it's checking, carrying four built-in verbs — validate, mutate, generate, verifyImages — directly in its schema. A team already fluent in Kubernetes manifests can read a Kyverno policy on sight, because it was never asked to learn a second language to do it. The cost of that fluency is scope: the policy language has no meaning outside an admission review. Ask it to also gate a Terraform plan or a CI artifact and there's simply nothing there to ask.

OPA and Gatekeeper start from the opposite premise: policy is a general-purpose brain, and Kubernetes is just one thing it's been taught to look at. Rego is a real, standalone declarative language that evaluates arbitrary JSON — it has no built-in notion of a "Pod" until a ConstraintTemplate tells it where to look inside an admission review's input. Gatekeeper is the Kubernetes-shaped wrapper around that brain — the webhook, the audit loop, the CRD generation — but the brain itself was never Kubernetes-specific, and the exact same Rego package can evaluate a Terraform plan in CI, or a policy check inside a service mesh, with zero code shared with the Kubernetes case beyond the rule text.

#  KYVERNO — the rule is shaped exactly like the object it checks
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  background: true
  rules:
    - name: no-privileged
      match:
        any:
          - resources: { kinds: [Pod] }
      validate:
        failureAction: Enforce
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            containers:
              - =(securityContext):
                  =(privileged): "false"

# OPA / GATEKEEPER — the same idea, in a language that has never
# heard of a "Pod" until this rule tells it where to look
package k8sdisallowprivileged

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

# The identical Rego engine, evaluating something that has never heard of a Pod:
opa eval -i terraform-plan.json -d policy/ "data.terraform.s3.deny"

# Kyverno has no equivalent invocation. Its only input shape is a Kubernetes
# admission review — the language was never designed to be general-purpose.

Enforcement is a dial, not a switch — and that's part of the philosophy too

☺ Like you're 10: Turning a brand-new rule fully on the moment you write it is how you find out, the hard way, whose deploy it was quietly breaking all along.

Both philosophies converge on identical operational wisdom despite their different syntax. Kyverno expresses it per rule as failureAction: Audit versus Enforce; Gatekeeper expresses the same idea per constraint as enforcementAction: dryrun, warn, or deny. In every case, the honest first move for a new rule is to let it run and simply record what it would have blocked, before it blocks anything at all — because a cluster that's been running unpoliced for months almost always has existing objects the new rule would reject on sight, and finding that out by breaking someone's Tuesday deploy is a worse way to learn it than reading a report. Rolling from audit to enforcement is itself a change worth the same discipline as section two of this page: a pull request that flips one rule's mode, reviewed and merged like any other diff — not a toggle someone flips from a dashboard because a Friday incident made the room nervous.

Choosing a philosophy — or living with someone else's

☺ Like you're 10: Most real clubhouses end up with one kind of guard, not both auditioning forever — but everyone inside should be able to say why that guard, and not the other one, is the one on duty.

Most platforms commit to one engine rather than running both indefinitely, and the honest deciding question is about your team and your estate, not which engine is "better." A team that's fluent in Kubernetes YAML and expects to stay Kubernetes-only leans toward Kyverno — lower ramp, and every rule already reads like the manifests it governs. A team that already needs, or expects to need, one policy brain across CI, cloud infrastructure, and a service mesh — see Service Mesh Architecture for how Istio's own authorization policy sits as a third, related-but-different control surface — leans toward OPA/Gatekeeper, and treats Rego's steeper ramp as a cost worth paying once, rather than three separate policy languages maintained in parallel forever. Golden Kubestronaut candidates specifically meet Kyverno in real depth through KCA, and meet the general-purpose side of this fork conceptually through the Platform Engineering course's own OPA & Gatekeeper and Kyverno tool pages — worth reading even if your own cluster only runs one of the two, because inheriting someone else's cluster eventually means reading the engine you didn't pick.