Policy as Code

The change under evaluation is the document being decided on, such as a proposed plan or manifest. The surrounding facts are everything else the rule needs, like the list of approved instance types, which the change never carries.

A policy decision point evaluates the rule and returns an answer. A policy enforcement point sits in the change's path, gathers the input, asks, and acts on the reply. A policy information point supplies facts the change itself does not carry.

A rule file states the condition as data, so the engine can report which rule failed on which resource, and the same rule can be listed, reviewed and reused elsewhere. An exit code carries one bit: pass or fail.

A usable denial names the rule that fired, the object and the exact field it failed on, what the rule requires, and one concrete fix. It should list every violation found, not only the first.

Fail open means the deploy proceeds when the decision service cannot answer; fail closed means it is rejected. Open protects delivery and lets unassessed changes through; closed protects the guardrail and can halt every deploy in the organisation.

It produces the empty set. Each successful evaluation of the rule body adds one message; when nothing matches, there are zero messages, and a runner such as conftest reports that as a pass.

A Rego rule cannot invent a fact. It must be loaded into the engine before the query, supplied by the caller inside the query itself, or fetched during evaluation with http.send. Nothing else reaches a rule.

OPA v1 makes if and contains mandatory, so a partial set rule must read deny contains msg if { ... }. The bare v0 head is a parse error, not a deprecation. import rego.v1 opts a single file into v1 syntax on an older engine.

input is the document the caller sends with a single query, the thing being judged. data is the tree the engine already holds: JSON loaded alongside the policy, plus the virtual documents that rules themselves define.

False is a value; undefined means Rego found no value at all. Both stop a rule body, but false is an answer, while undefined leaves the rule with no result to emit and no error to report.

An OPA bundle is a gzipped tar archive of Rego policy, data files and an optional .manifest. The manifest's revision is an opaque label for that build, reported in OPA's status and decision output so you know which policy decided.

OPA's data document is the in-memory JSON tree of standing facts policies read as data.something, separate from the input being decided. Facts arrive as startup files, inside a bundle OPA polls for, or as pushes to its Data API.

Gatekeeper's audit controller periodically re-evaluates objects that already exist in the cluster against every enforced Constraint and records the violations in each Constraint object's own status field. It only reports: it never blocks, deletes or changes anything.

gator test evaluates Gatekeeper policy locally: you hand it ConstraintTemplates, their Constraints, and the Kubernetes objects to review, and it reports which object violated which constraint. It needs no cluster, no kubeconfig and no admission webhook.

A Gatekeeper Assign is a mutator: at admission it writes a value into a field of the incoming object, so the object is stored changed instead of rejected. A Constraint only inspects and denies.

Three separate ones, not one: your Deployment, then the ReplicaSet the deployment controller creates, then one request per Pod from the ReplicaSet controller. Each is admitted on its own, under the controller's identity rather than yours.

A warning is advisory only. The API server returned it in an HTTP Warning response header alongside a response that succeeded, so the object was admitted. Only a denial, which comes back as a failed status, stops the write.

The rule was written for tenant workloads, not cluster infrastructure — and the policy engine's own Pods live in a system namespace, so an engine inside its own scope can block the Pods that would replace it.

An AdmissionReview request carries one object under review, its previous version on updates, the requesting user and groups, the operation, resource and subresource, and a dryRun flag. It carries no other objects, no cluster state and no history.

Patch when the fix is behaviour-neutral and the platform owns the value, like adding a missing default. Reject when the compliant form changes what the process sees, such as moving a secret from an environment variable into a mounted file.

kyverno apply reads policy files and resource files from disk and evaluates the rules against them locally, printing pass, fail, skip and warn results. It is a dry run: no cluster is contacted and nothing is admitted.

A Kyverno PolicyException names the policy and the specific rule names it waives, plus a match block selecting which resources the waiver covers. It never disables the policy itself; anything the match block misses is still enforced.

A Kyverno generate rule creates a companion object when a trigger appears, such as a default-deny NetworkPolicy in every new namespace. A validate rule can only accept or reject the request; generate supplies the resource instead of demanding it.

The +() anchor in a Kyverno strategic-merge mutate patch sets a field only when the incoming object does not already have it. If the field is already present, the existing value is left alone rather than overwritten.

A deny block evaluates boolean conditions with operators over the admission request and blocks when they are true. A pattern only asserts the shape a resource must match, so it cannot use operators, compare two fields, or read request metadata.

The configuration section. Each resource there carries an expressions object whose references list the addresses it points at. The planned_values section holds only each resource's resolved attribute values and records no links between resources.

The plan is flattened. Every resource a module declares is expanded into the plan's resource lists under a module-qualified address such as module.network.aws_s3_bucket.flow_logs, so ordinary resource rules fire on module-created resources without knowing modules exist.

A chart's templates are Go template text, not valid YAML, and fields hidden behind conditionals only appear once values are applied. Render the chart first, then evaluate the manifests it produces.

planned_values is the whole post-apply state, every managed resource including untouched ones. resource_changes is the per-resource diff, carrying the action and the before and after values. A rule over planned_values judges the estate; a rule over resource_changes judges this run.

It means the value does not exist yet: the provider or cloud only produces it when the resource is actually created, so the plan holds a placeholder. A policy rule evaluating that attribute has nothing real to test.

The check is the same engineering fact; only the reporting differs. One check with three mapping edges means one rule to maintain and three audit reports that can never disagree about the same listener.

Decomposition turns one control sentence into the separate facts a machine can test. "Audit logging enabled and retained 365 days" becomes distinct checks: a log destination exists, retention is at least 365, tamper-evidence is on, delivery still succeeds.

A pass rate hides its denominator. The 98% counts only instances the check actually enumerated; anything in an account, region or project the tooling never reached sits outside both numbers, so unseen systems are invisible rather than failing.

It proves only that passwords change on schedule. It says nothing about phishing, stolen session tokens, or accounts that were never removed. A green control measures the activity someone wrote down, not the attack it was meant to stop.

Each record needs the verdict plus everything that makes it re-checkable: which control it proves, which resource was evaluated, the exact rule version and input it saw, when it ran, and which identity ran it.

A shadow run evaluates a candidate rule offline against a corpus of real, already-completed changes and records the verdict it would have given each one, without blocking anything. It shows how often the rule fires and on what.

Near-miss cases are legitimate inputs sitting just inside the boundary — the changes the rule must let through. Deny cases only prove a rule can refuse something. They never prove it refuses nothing else.

The input contract is the written agreement about the document a rule decides over: which step produces it, how it is wrapped, and which fields are guaranteed present. Agree it before writing the rule.

Which ruleset produced the number and what it covered. Zero violations only means the rules that actually loaded found nothing in the resources that were actually enumerated. An empty or replaced ruleset reports exactly the same green.

A rule is production code: one bad rule blocks every team's builds at once. Review, tests and CI catch it before it reaches a gate, and give each change an author, a reviewer and a history.

A break-glass override is a pre-authorised, deliberately loud way to ship one change that a policy gate denied, used when waiting is worse than the risk. It must leave a record: who pulled it, which rule, which change, and why.

A CI check only sees changes that travel through CI. Anyone holding cloud credentials can create the instance from a console session or a local apply, and that route never reaches the check at all.

Merging is not deploying. The reconciler reads whatever sits on the tracked branch and applies it, without consulting the check that ran on the pull request. The check informs humans; it has no authority over the applier.

A required check must report a passing result before the pull request may merge. An advisory check only posts a result nobody consults. If a required check never reports, the merge stays blocked rather than allowed.

No. A missing report is not a clean result, it is an absent one. A gate needs three outcomes — pass, fail, and no usable evidence — and the third must never be folded silently into the first.