Where does an admission gate sit when a workload spec is submitted to a cluster, and what can it do to that request?

middlemust knowfreq 55%

answer

before anything is stored
a document, not a process
admit or refuse the request
both halves: image and spec
running replicas are not re-checked

basics

~20 s

An admission gate runs after a workload spec is submitted and before the platform stores or schedules it. It reads the spec and the image reference the spec names, then admits the request or refuses it outright.

solid answer

~40 s

A start request arrives as a document: a workload spec naming an image reference, the command to run, what it reserves, and what it wants from the host. The gate is evaluated on that document before the platform commits to it, so nothing is placed, pulled or started while the decision is outstanding. It can answer in two useful ways — admit or refuse — and some designs also let it rewrite the request first, most often to replace a moving reference with the exact bytes it just verified. Two consequences follow. It judges a declaration, not behaviour, so a workload that passes every rule can still misbehave once it runs. And it fires only on submission, so tightening a rule leaves replicas already running untouched until something resubmits their spec.

code

yaml · 16 lines

yaml

admissionRule:
  name: ledger-cluster-default
  appliesTo:
    workloadLabels:
      tier: payments
  image:
    allowedSources:
      - registry.internal/ledger/
    requireVerificationResult: true
    expectedBuildSource: source.internal/ledger
    resolveReferenceToExactBytes: true
  spec:
    denyFullHostPrivilege: true
    denyHostPathMounts: true
    denyHostControlSocket: true
  onVerifierUnreachable: refuse

go deeper

for a junior

Remember the position first: an admission gate runs on a submitted workload spec, before anything is pulled, placed or started, and its answer is admit or refuse.

for a middle

Explain that the gate reads a document rather than a process, and that it judges both halves — the image reference it names and what the spec asks of the host.

for a senior

Show you know a refused start leaves no container to inspect, and that a tightened rule reaches running replicas only as they churn, so enforcement and compliance differ.

for a principal

The live trade is how much a gate may rewrite a request. Pinning a verified reference to the exact bytes is defensible; quietly editing what a team declared is not.

What a start request looks like to the gate

Nothing is running yet. What reaches the platform is a document: a workload spec that names an image reference, the command to run, the resources it reserves, and what it wants from the host — writable paths, mounted host directories, the privilege set the process should hold. An admission gate is a check the platform runs over that document before it commits to it.

The gate never sees a process, a filesystem or a packet. It sees a declaration and answers one question about it. Almost every misconception about admission comes from forgetting that sentence.

Where it sits in the sequence

A client or a controller submits the workload spec.
The platform authenticates the submitter and checks they are allowed to create this kind of object at all.
The admission gate is evaluated on the submitted document. The rules may be built into the platform, or computed by a separate checker the platform calls over the network.
If the gate admits, the spec is stored as desired state — and only then does a scheduler choose a place, a node fetch the image, and a runtime start the container.
If the gate refuses, nothing further happens: no placement, no pull, no container.

Step 5 is worth sitting with. A refused workload leaves no container, so there are no container logs to read and nothing to attach to. The reason travels back on the submitting request and into the gate's own decision record. When a controller is the submitter rather than a person, it keeps retrying, and the symptom is a workload that never appears at all rather than one that crashes.

What the gate can decide

Outcome	What it means	Typical reason
Admit	The document is stored exactly as submitted	The common case
Refuse	The request fails and nothing is created	Unapproved source, no verification result, a spec asking for privilege
Rewrite, then admit	What gets stored differs from what was submitted	Replacing a moving reference with the exact bytes that were verified

Not every platform offers the third, and where it exists it is easy to misuse: rewriting means what runs is not what the author wrote, so the rewrite has to be small, predictable and recorded. The most defensible use is pinning — the gate resolves the reference it has just verified down to the exact bytes and stores that, so the decision and the thing the decision was made about cannot drift apart afterwards.

The two halves it checks

About the image — whether the reference names an approved source; whether a verification result exists for those exact bytes, computed by something the platform itself trusts rather than read out of a report someone attached; whether the reference resolves to one specific set of bytes at all.
About the spec — whether it asks for the full host privilege set, a host path mounted into the container, the runtime's own control socket, or a shared host view of the system.

The second half is the one people forget, and it is why admission is a security control rather than only a supply-chain one. The same gate that refuses an unverified image refuses a spec that would have made the isolation boundary irrelevant — and it refuses it before anything starts, by rule, rather than leaving the kernel to be the only thing standing in the way.

The two things admission does not do

It does not judge behaviour. A spec that passes every rule describes a workload that may exfiltrate data the moment it runs. Admission constrains what may start; what a running process then does is a different layer with different controls.
It does not reach what is already running. The gate fires on submission. Tighten a rule today and every replica admitted yesterday keeps serving under yesterday's rule, until something resubmits its spec — a rollout, a replacement after a node is lost, a scale-up.

That second point has a practical edge on a large estate. A new rule takes effect gradually and unevenly, in whatever order workloads happen to churn, so "the rule is enforced" and "the estate complies" are two different claims and only the first is true on the day you ship it. Teams that want the second either deliberately churn the workloads after the rule lands, or report continuously on the gap between the population the rule would admit today and the population actually running.

## What a start request looks like to the gate Nothing is running yet. What reaches the platform is a **document**: a workload spec that names an image reference, the command to run, the resources it reserves, and what it wants from the host — writable paths, mounted host directories, the privilege set the process should hold. An **admission gate** is a check the platform runs over that document before it commits to it. The gate never sees a process, a filesystem or a packet. It sees a declaration and answers one question about it. Almost every misconception about admission comes from forgetting that sentence. ## Where it sits in the sequence 1. A client or a controller **submits** the workload spec. 2. The platform authenticates the submitter and checks they are allowed to create this kind of object at all. 3. The **admission gate is evaluated** on the submitted document. The rules may be built into the platform, or computed by a separate checker the platform calls over the network. 4. If the gate admits, the spec is **stored as desired state** — and only then does a scheduler choose a place, a node fetch the image, and a runtime start the container. 5. If the gate refuses, nothing further happens: no placement, no pull, no container. Step 5 is worth sitting with. A refused workload leaves **no container**, so there are no container logs to read and nothing to attach to. The reason travels back on the submitting request and into the gate's own decision record. When a controller is the submitter rather than a person, it keeps retrying, and the symptom is a workload that never appears at all rather than one that crashes. ## What the gate can decide | Outcome | What it means | Typical reason | |---|---|---| | **Admit** | The document is stored exactly as submitted | The common case | | **Refuse** | The request fails and nothing is created | Unapproved source, no verification result, a spec asking for privilege | | **Rewrite, then admit** | What gets stored differs from what was submitted | Replacing a moving reference with the exact bytes that were verified | Not every platform offers the third, and where it exists it is easy to misuse: rewriting means what runs is not what the author wrote, so the rewrite has to be small, predictable and recorded. The most defensible use is **pinning** — the gate resolves the reference it has just verified down to the exact bytes and stores that, so the decision and the thing the decision was made about cannot drift apart afterwards. ## The two halves it checks - **About the image** — whether the reference names an **approved source**; whether a **verification result** exists for those exact bytes, computed by something the platform itself trusts rather than read out of a report someone attached; whether the reference resolves to one specific set of bytes at all. - **About the spec** — whether it asks for the **full host privilege set**, a **host path** mounted into the container, the runtime's own **control socket**, or a shared host view of the system. The second half is the one people forget, and it is why admission is a security control rather than only a supply-chain one. The same gate that refuses an unverified image refuses a spec that would have made the isolation boundary irrelevant — and it refuses it before anything starts, by rule, rather than leaving the kernel to be the only thing standing in the way. ## The two things admission does not do - **It does not judge behaviour.** A spec that passes every rule describes a workload that may exfiltrate data the moment it runs. Admission constrains *what may start*; what a running process then does is a different layer with different controls. - **It does not reach what is already running.** The gate fires on submission. Tighten a rule today and every replica admitted yesterday keeps serving under yesterday's rule, until something resubmits its spec — a rollout, a replacement after a node is lost, a scale-up. That second point has a practical edge on a large estate. A new rule takes effect **gradually and unevenly**, in whatever order workloads happen to churn, so "the rule is enforced" and "the estate complies" are two different claims and only the first is true on the day you ship it. Teams that want the second either deliberately churn the workloads after the rule lands, or report continuously on the gap between the population the rule would admit today and the population actually running.

The rule is tightened to require a verification result. What happens to the replicas already running under the old rule?
Nothing, immediately. They were admitted under the rule in force at the time and the gate does not revisit them. Each one moves to the new rule only when its spec is resubmitted — a rollout, a replacement after a node is lost, a scale-up. Until then the estate holds two populations, and only a report comparing what is running against what the rule would admit today will tell you how big the older one is.
A refused request produced no container and no container logs. Where do you look for the reason?
Two places. The refusal is returned on the submitting request itself, so whatever submitted it — a person or a controller — saw the reason first. And the gate keeps its own decision record, which is where you find refusals for requests a controller has been retrying quietly. The absence of a container is the signal: a workload that never appeared at all was refused, while one that appeared and died was admitted.

saying these in an interview costs you the question

Thinks the gate inspects the running container's behaviour rather than a submitted document.
Assumes tightening a rule stops or restarts workloads that are already running.
Believes passing the gate proves the image is free of flaws.
Thinks the gate only reads the image reference and never the rest of the spec.
Looks for the refusal reason in the container's logs, of a container that was never created.

Where does an admission gate sit when a workload spec is submitted to a cluster, and what can it do to that request?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What a start request looks like to the gate

Where it sits in the sequence

What the gate can decide

The two halves it checks

The two things admission does not do

▾common follow-ups2 questions

▾red flags5 flags

What a start request looks like to the gate

Where it sits in the sequence

What the gate can decide

The two halves it checks

The two things admission does not do

answer

go deeper