Kubernetes Admission Control

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.

A validating rule can only accept or reject. A mutating rule rewrites the object that actually runs, so whoever controls it can add a container, volume or environment variable to every Pod it matches, cluster-wide.

Only what the API server hands the expression: the incoming object, the previous object on an update, the request attributes, the request's namespace object, and a bound parameter resource. It cannot fetch anything else.

An admission request carries only the submitted object, its previous version, and the requesting user - not the namespace's other Services. Counting needs those siblings, so the rule must get them from somewhere outside the request.

Nothing happens to them. Admission evaluates API write requests, not stored objects, so the 400 existing PVCs keep running unlabelled and are never checked again unless something submits a write for them.

It carries the single object being submitted, the previous version on an update or delete, the requesting user and groups, and a dryRun flag. It carries no other object, no cluster state, no history, and no artifact contents.

namespaceSelector matches labels on the containing Namespace, objectSelector matches labels on the object itself, and matchConditions are CEL expressions over the whole request. All three narrow a match that resource rules have already made on group, version, resource and operation.

Admission runs only on the write path. It sees objects as they are created or updated, and it was never shown anything already stored in the cluster. Counting today's violations needs a background evaluation that reports on existing objects as data.

Every subsequent write. A CREATE-scoped rule sees the object once, at birth; any later update by a user, an operator or a provisioner can strip the required label and no request is ever denied, so a compliant object silently becomes non-compliant.

The admission request carries an image reference string, not the image's dependency list, so the licence fact is not in the payload. Reading it would need an out-of-band fetch of self-asserted metadata. The fact belongs to the build-time inventory instead.

Each request was evaluated on its own, against a view of the cluster that did not yet contain the other. Admission has no lock and no serialisation, so a check-then-act uniqueness rule can pass both halves of a race.

A rule you can only exercise inside a live cluster can only be tested by deploying it. Offline evaluation runs the same rule text against a saved manifest in seconds, in a unit test and in CI.

Target Pods for enforcement — every path ends in a Pod. Target the workload kinds too for feedback: only there does the denial reach the author's terminal. The two views can disagree, so decide which your intent means.

messageExpression is a CEL expression evaluated against the request object, so the failure text can name the specific object, field or value that broke the rule. A static message is one fixed sentence that can only describe the rule.

On CREATE, object holds the incoming object and oldObject is null. On UPDATE both are populated, new and stored. On DELETE it inverts: object is null and oldObject holds the object about to be removed. userInfo is populated in all three.

Because the same webhook can be called again on an object it already patched, once a later mutator changes that object. A patch that sets a field converges; one that appends to a list adds a duplicate every time it runs.

The full object body — for a Secret, its complete data — plus the previous version on an update, the requesting user and groups, the operation and dryRun. It carries no other object and no cluster state.

Declare a paramKind on the policy, point the binding's paramRef at an instance of that kind, and read it in the expression as params. Changing the allowlist then means editing that resource, not the policy.

It supplies the siblings a request does not carry, by watching the API and holding a local copy of chosen kinds. That copy always reflects a slightly earlier moment, and it is empty and filling right after the engine restarts.

Most likely a Pod-level admission rule is rejecting the job's Pods. The CronJob and its Jobs are admitted fine; only the Pod create is denied, by a controller, so the failure lands in a Job event and never in anyone's terminal.

Carry only what the API server cannot know. Its built-in deprecation warning already names the version and its replacement, so your text must add local detail: which template produced the object, which rule fired and who owns it.

Scoping by objectSelector grants a self-service opt-out. Labels live on the submitted object, so anyone allowed to create that object can also set the label that puts it out of scope, in the same manifest the rule would have judged.

Because the rule forbids a transition, not a state. Only oldObject reveals the previous value, so the rule can tell a harmless edit from a downgrade. On CREATE there is no oldObject, so the rule needs its own branch for that case.

Compare live objects with the manifests that produced them: the extra container is in the stored object but not the source. Then remove the mutating registration so the API server stops calling the engine, and roll the workloads.

Editing the rule weakens it for everyone and buries the carve-out in policy source. An exception object keeps one rule text everywhere, states exactly what is excluded and where, and is listable, access-controlled and revocable by deleting it.

Not directly — CEL in an admission policy cannot call anything. Either mirror the inventory into a parameter resource and enforce against the copy, split the rule and keep only the self-contained half in-tree, or move the check to an engine that can do the lookup.