Why can't an admission rule reject an image whose bundled dependencies carry a disallowed licence?
answer
- the fact is not in the payload
- labels live in the registry, not the Pod spec
- a label is a claim by the builder
- an inventory says what is inside
- known at build, not re-derived at deploy
basics
~20 sThe 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.
solid answer
~50 sThe licence of a bundled dependency is established when dependencies are resolved at build time, and it is recorded in the artifact's inventory. Admission never sees any of that: the Pod spec carries `registry.internal/api:2026.08.1` and nothing about what is inside. The usual retry is to have the builder stamp the licence into an image label and have admission read that, which fails twice. First, the label is not in the request either, so the check needs a registry fetch during a write — an expression-only policy cannot do I/O at all, and a webhook that does puts a network call in the path of every Pod create. Second, the label is a claim written by whoever built the image, so a rule reading it enforces the builder's honesty, not the licence. The right answer is that admission enforces nothing here and the control lives where the inventory is produced.
go deeper
Know that a container spec holds an image name, not the image. If a rule needs to know what is inside an artifact, that information has to come from somewhere other than the deployment request.
Explain both failures of the image-label retry: the label is not in the request, so reading it needs I/O in the write path, and it is self-asserted by the builder, so it proves nothing.
Demonstrate that you would refuse the placement and relocate the control, and that you would resist a proxy rule or a warn-only rule that produces the appearance of coverage.
Own the reporting consequence: the coverage map must state that admission enforces nothing for this requirement, with a named owner for the control where the fact actually exists.
### The request that keeps coming back Somebody in legal or engineering leadership decides the company will not ship a particular dependency licence. The requirement is real. The request that lands on the platform team is not: *add an admission rule so nothing with that licence can be deployed.* It sounds like exactly the kind of thing a cluster gate is for. It is the canonical wrong choke point. ### Why it cannot land there Start with the inputs. An admission decision is made from one API request, and for a Pod that request contains a container spec whose image field is a string. It does not contain the image's layers, its installed packages, its language-level dependencies, or the licences of any of them. The fact the rule needs is simply not in the payload, and no amount of expressiveness in the rule language changes that — a policy language can only decide over the data it is given. ### The retry: put it in an image label The next proposal is always the same: have the build stamp a label into the image metadata, then let admission read the label. Two separate things break. **The label is still not in the request.** Image labels live in the image config in the registry, not in the Pod spec. To read one, the policy must fetch the image manifest and config from the registry during the admission decision. A policy expressed as pure expressions over the request cannot perform I/O by design. A webhook can — and now every Pod create in the cluster depends on a registry round trip completing inside the API server's admission timeout. When the registry is slow or unreachable, either writes stop or the check silently stops happening; both outcomes are decided by configuration rather than by the risk you were managing. You have also made a security decision depend on network reachability from the control plane. **The label is a claim, not evidence.** Whoever built the image chose what to write in it. A rule that reads it enforces the builder's assertion about the licence, not the licence. Anyone who can push an image can push one with the label set to whatever passes. That is not a subtle bypass — it is the entire content of the check. **And the reference is not the artifact.** The tag in the spec is resolved to actual bytes later, when the node pulls. A decision made about what a tag pointed at during admission is not necessarily a decision about what runs. ### Where the fact actually is The licence of a dependency is known at the moment the dependency is resolved into the build. That is where the composition of the artifact is established, and it is recorded in the inventory produced then — an SBOM is exactly a statement of what is inside an artifact. A check that reads that inventory is reading a description produced by the process that knows, at a moment when there is no latency budget and no user waiting, and where a failure is a red build rather than a cluster that cannot accept writes. Note the direction carefully, because interviews probe it: an inventory says **what is inside** an artifact. It does not say how the artifact was built, and it does not say who vouches for it. The licence question is a what-is-inside question, which is precisely why the inventory is its home and the deployment request is not. ### The uncomfortable outcome The answer a lead has to be able to give is: *admission will not enforce this, and it will not record anything about it either.* That is not a gap to be papered over. Two tempting patches make things worse: - **A proxy rule.** Only allow images from the repository the compliant pipeline pushes to. This is a useful rule for other reasons, but it does not decide the licence question; it decides a path question, and it will be read by everyone as licence coverage that does not exist. - **A warn-only rule on the label.** It manufactures the appearance of a control. It fires on unverified input, produces noise a team learns to ignore, and puts a green line in a coverage report that nobody can defend when asked what it actually checked. ### Third-party images you did not build When the artifact comes from a vendor, there is no build of yours to attach the check to. The fact still has to be established once, by analysing the artifact or by getting a statement from the vendor, and the decision is made when you promote it into your registry — once per artifact, not once per Pod create. The shape of the answer is unchanged: establish the fact where it can be established, decide there, and do not ask the write path to re-derive it. ### What good sounds like *The requirement is fine, the placement is wrong. The request has an image name and no image contents, and the only way to get contents into the decision is to trust a self-written label or to make the API server call the registry. The licence is known at build time and recorded in the inventory; the check belongs there, and I will say plainly on the coverage map that admission does not enforce it.*
- Could a validating webhook simply fetch the inventory from the registry itself?Technically yes, and you would regret it. Every Pod create now waits on a registry round trip inside the admission timeout, so registry availability decides whether the cluster accepts writes. You have also moved a build-time fact into the write path to re-derive it under a latency budget, and the answer still describes an image the node may not pull.
- The image is from a vendor and there is no build of ours. Now what?Establish the fact once, when you promote the artifact into your own registry — from your own analysis of it or from a vendor statement — and decide there. It is one decision per artifact rather than one per deployment, and the decision is made against the artifact you actually accepted rather than against a name in a Pod spec.
- Is there anything about this requirement admission can legitimately help with?Only path-shaped facts that are genuinely in the request: which repository an image comes from, which identity submitted the workload, whether required metadata is present. Those are real rules, but none of them decides the licence question, so do not let them be reported as if they did.
saying these in an interview costs you the question
- Reads image labels as if they were verified facts
- Wants the webhook to download and inspect the image inline
- Assumes the Pod spec contains the image's package list
- Adds a proxy rule so a control appears to exist
- Says an inventory records how the artifact was built