Kubernetes Admission Operation Handling

Kubernetes Admission Operation Handling covers how admission plugins and webhooks respond differently depending on which HTTP-style operation — CREATE, UPDATE, DELETE, or CONNECT — a request represents, since each operation carries distinct semantics, distinct available fields in the AdmissionRequest, and often warrants entirely different policy logic even when applied to the same resource type.

The Four Operation Types

CREATE

A CREATE operation submits a brand-new object with no prior state to compare against; admission logic handling CREATE typically focuses on validating the object's initial configuration against policy — required labels, resource limits, security context settings — since there is no previous version to diff against.

rules:
- operations: ["CREATE"]
  apiGroups: [""]
  apiVersions: ["v1"]
  resources: ["pods"]

UPDATE

An UPDATE operation includes both the new object (request.object) and the previous version (request.oldObject), enabling policy that specifically reasons about what changed — for instance, rejecting an update that removes a previously required label, or permitting a security-sensitive field to be set at creation but blocking any later change to it.

{
  "request": {
    "operation": "UPDATE",
    "object": { "metadata": { "labels": { "team": "payments" } } },
    "oldObject": { "metadata": { "labels": {} } }
  }
}

DELETE

A DELETE operation carries request.oldObject (the object being removed) but no new object, since nothing is being persisted; admission logic for DELETE typically enforces protective policy — preventing deletion of objects carrying a "do not delete" annotation, or requiring deletions in a production namespace to originate from an approved automation identity.

CONNECT

CONNECT operations correspond to subresource actions like pods/exec, pods/attach, and pods/portforward that establish a streaming connection rather than submitting or removing a standard object; admission handling for CONNECT is comparatively rare but relevant for policies that want to restrict or log interactive access to running containers.

Handling Operations Correctly in Webhook Logic

Checking the Operation Before Applying Logic

A webhook registered for multiple operations must branch its logic based on request.operation, since applying CREATE-oriented validation (such as requiring a field be unset) against an UPDATE request can incorrectly reject legitimate modifications that were never intended to be covered by that rule.

if request["operation"] == "UPDATE":
    old_labels = request["oldObject"]["metadata"].get("labels", {})
    new_labels = request["object"]["metadata"].get("labels", {})
    if "team" in old_labels and "team" not in new_labels:
        return deny("team label cannot be removed")

Scoping Rules to Only the Relevant Operations

Registering a webhook only for the operations its logic actually needs to handle — rather than all four by default — reduces unnecessary invocation overhead and avoids the webhook receiving requests (such as DELETE) it has no meaningful logic to apply to, simplifying both performance and correctness.

Operation-Specific Policy Patterns

Immutability Enforcement on UPDATE

A common pattern uses UPDATE handling specifically to enforce field immutability — rejecting any change to a workload's assigned serviceAccountName after creation, for instance — which cannot be expressed through CREATE-only validation since the field is legitimately allowed at creation time.

Deletion Protection

Policies that protect critical resources from accidental removal register specifically for DELETE operations, checking for a protective annotation or label and rejecting the deletion unless the annotation has been explicitly removed first, requiring a deliberate two-step process for genuinely intended deletions.

metadata:
  annotations:
    policy.example.com/protected: "true"

Auditing Interactive Access via CONNECT

Organizations with strict change-control requirements sometimes use CONNECT operation handling to log or restrict pods/exec sessions in production namespaces, since exec access bypasses the normal declarative deployment path entirely and warrants separate scrutiny.

Common Pitfalls

Forgetting oldObject Is Absent on CREATE

Webhook logic that unconditionally reads request.oldObject without checking the operation type will encounter a null or missing value on CREATE requests, a frequent source of webhook implementation bugs that only surface once a policy handling both CREATE and UPDATE is exercised against a genuinely new object.

Applying DELETE Logic to subresources Unexpectedly

Because DELETE on a parent resource and DELETE on certain subresources can both match a broadly scoped rule, webhook rule configuration should explicitly enumerate the resources (including or excluding subresources) intended, rather than assuming a resources: ["pods"] entry only ever matches deletion of whole pod objects.