Policy Engines for Platform Governance: CNPA practice questions

Policy engines let a platform turn its rules into code that is evaluated automatically: images must come from approved registries, containers must not run privileged, every Deployment needs an owner label, production namespaces need resource limits. Kyverno's introduction defines policies in cloud-native systems as configurations that manage other configurations or runtime behaviors. For platform teams this is how guardrails scale. Instead of reviewing every manifest by hand, the platform rejects or fixes what breaks the rules and reports what already does.

The main enforcement point in Kubernetes is admission control, which runs in two phases: mutating admission controllers first, then validating ones. Policy engines plug in as dynamic admission webhooks. For simpler rules Kubernetes also offers ValidatingAdmissionPolicy, stable since v1.30, a declarative, in-process alternative to validating webhooks that evaluates Common Expression Language (CEL) expressions inside the API server.

Open Policy Agent (OPA), a graduated CNCF project, is a general-purpose policy engine that decouples policy decisions from enforcement. Software sends OPA structured input such as JSON, OPA evaluates it against policies written in its declarative language, Rego, together with data, and returns a decision, which can be richer than allow or deny. It is used for Kubernetes, microservices, CI/CD pipelines and API gateways. OPA Gatekeeper brings OPA to Kubernetes as a validating and mutating webhook: a ConstraintTemplate defines a reusable, parameterized policy and a Constraint instantiates it, with validation able to deny, warn, dry-run, audit or report. Gatekeeper's audit shows existing resources that violate a policy, which matters because admission only sees new or changed requests.

Kyverno takes a Kubernetes-native approach. Policies are Kubernetes resources written in YAML and CEL, so there is no new language to learn, and they can validate, mutate, generate or clean up resources and verify container images and their metadata for supply chain security. Kyverno runs as a dynamic admission controller, its CLI applies the same policies to manifests and other files in a pipeline, and for resources that were allowed or existed before a policy it creates Policy Reports with their results. It also supports explicit policy exceptions.

Governance works best in layers. The same policies run as early checks in CI, at admission as the hard gate, and as continuous audit of what is already running. A sensible rollout introduces a rule in a warn or audit mode, fixes existing violations, then enforces it, and handles special cases through exceptions rather than by disabling the policy.

Misconceptions: policy engines are not only for security, since they also cover cost, reliability and naming conventions; admission policies do not fix existing resources on their own; and RBAC is not a substitute, because RBAC decides who may make a request while a policy decides whether the content of that request is acceptable.

At associate level, expect to choose between OPA/Gatekeeper and Kyverno for a requirement, to place a check in CI, admission or audit, and to describe what mutating and validating admission each do.