In a Kubernetes AdmissionReview, what does the API server actually send an engine whose match includes Secrets?

## What is in the request When a request matches a registered webhook, the API server sends the engine an `AdmissionReview` whose `request` field carries: - **`object`** — the object under review, complete. - **`oldObject`** — the previously stored version, on an update or a delete (on a delete there is an old object and no new one). - **`userInfo`** — the username, UID and groups of whoever made the request. - **`operation`**, **`kind`**, **`resource`**, **`subresource`**, **`namespace`**, **`name`**, a request **`uid`**, and **`dryRun`**. Two things about this list matter far more than the rest. ## The body is complete, not a projection The API server does not know which fields your rule inspects, so it cannot send a subset. A rule that only checks `metadata.labels` is still handed the entire object. For most resources that is unremarkable. For Secrets it is the whole point: a Secret's `data` is base64-encoded, not encrypted, so a match that includes `secrets` means every credential written anywhere in the cluster crosses the network to the engine's pods, in full, and an update to rotate a credential delivers both the old and the new value in one request. Notice how that read path came about. Nobody granted the engine permission to read Secrets. Admission is a **push**: the API server sends what the match selects, regardless of what the engine's own credentials would allow it to fetch. The match rules — the resources, the namespace and object selectors — are the *only* control over that channel. That is why narrowing a match is a least-privilege argument about the engine, not a throughput optimisation. It is also why the engine's pods, the network path to them, and anything the engine writes down about a decision hold some of the most sensitive data in the cluster; what the engine then does with that body is its own design problem. ## What is absent, and what that forbids The request carries **no other object, no cluster state and no history**. This is the single fact policy authors most often get wrong. From an admission request alone a rule cannot decide: - "no two Ingresses may claim the same hostname" — it cannot see the other Ingresses; - "this namespace already has ten Deployments" — it cannot count them; - "this image is on the approved list" — unless the list travels with the rules; - "this user did the same thing an hour ago" — there is no history. Anything of that shape needs state the request does not contain, which means either shipping the data to the engine as configuration or giving the engine credentials to fetch it live — a decision with its own consequences, because it adds a second privilege channel alongside the pushed objects. ## Practical consequences - **Match only what the rules need.** If no rule reasons about Secrets, no Secret should ever be sent. The same goes for ConfigMaps, which routinely hold connection strings and tokens. - **Do not confuse the two channels.** The engine having no read permission on a resource does not stop that resource's bodies arriving at its endpoint. - **Use `oldObject` deliberately.** It is what makes update rules possible — comparing what changed rather than judging the new object alone — and it is also a doubling of exposure on every update you match. - **Design rules around what the request contains.** A rule that needs the rest of the cluster to decide is a rule that will either be weakened, be moved to a check that runs after the fact, or push you into granting the engine standing access.