A cluster gate admits any image whose reference names the company's own registry host — what does that rule actually enforce?
answer
- where from, not what
- a match on the reference string
- count who can publish there
- a copy launders the name only
- bind the decision to exact bytes
basics
~20 sAn approved-source rule enforces where the bytes will be fetched from, not what the bytes are — it is a match on the reference string. Anyone able to publish under that host, or to copy a foreign image there, passes it.
solid answer
~40 sThe rule compares the front of the image reference against a list of approved hosts and paths. That is text the submitter wrote, so what it constrains is the fetch location and nothing about the content. Its real trust set is everyone and everything able to publish under that host, which is usually far larger than the set of builds anyone reviewed — and a promote-by-copy step or a caching mirror will re-publish an outside image under an approved name without changing it at all. The rule still earns its place: it is cheap, it stops the accidental public fetch, and it gives one place to look. To bind the decision to the content you pair it with a **verification result the gate computes over the exact bytes**, and you record the bytes admitted.
go deeper
Know that an approved-source rule matches the front of an image reference, so it constrains where bytes are fetched from and says nothing about what they contain.
Explain that the rule's real trust set is everyone able to publish to that host, which is normally much larger than the set of builds anyone actually reviewed.
Name the concrete ways an outside image arrives under an approved name — promotion by copying, a caching mirror, a pointer that moved — and what you add to close them.
Decide what the source rule is for on your estate: a cheap coarse filter that composes with content verification, never a control you present on its own as provenance.
## What the rule actually matches An image reference is a **name**: a host, a path within that host, and a pointer to something published there. An approved-source rule compares the front of that name against a list. It runs before anything is fetched, on text the submitter supplied, and it produces one guarantee — *the bytes will be fetched from this host* — and no other. That is a real guarantee, and it is not the one people think they bought. "It came from our registry" is a statement about a **location**, and every question worth asking at admission is a statement about **content**: who built these bytes, from what source, and has anything the cluster owner trusts vouched for them. ## The trust set the rule creates When a cluster admits anything published under a host, it has quietly declared a trust set. Everyone in it can put a workload on the cluster: - every person holding publish rights to that host, including people far outside the release process; - every automated job holding a publish credential, including ones that were set up for something unrelated; - anyone who compromises one of those credentials; - anyone who can influence what the registry serves for a given name — a mirror configured to fetch and serve content it found elsewhere, or a cache that was populated from outside. Ask the question directly in a review: *how many identities can publish here, and is that the list we meant to approve?* On most estates the honest answer is a number nobody has counted. ## Three ways an unwanted image passes the rule 1. **Promotion by copying.** A step copies an outside image into the approved registry so that deployments can name it. The copy normally preserves the bytes exactly, so nothing about the image changed — only the prefix your rule matches on. Copying launders the name, not the content. 2. **A caching mirror.** A host configured to fetch on demand and serve what it fetched will answer for names it has never been asked to vouch for. To the rule the reference looks approved, because the host is. 3. **A pointer that moved.** A reference can name a **movable pointer** rather than the content-derived **digest** that identifies exact bytes. Approve the name today and the bytes behind it can be different tomorrow; the rule still matches, because the rule is looking at the name. | The rule says | What that proves | What it does not prove | |---|---|---| | The reference names an approved host | The fetch goes to a host you operate | Nothing about the bytes fetched | | The name matches an approved path | Someone with rights there published under it | That the publisher was the release process | | The reference is well-formed | It resolves to something | That it resolves to the same thing twice | ## What binds the decision to the bytes - A **verification result computed by the gate over the exact bytes** — not a report attached to the request, and not the fact that an earlier step said it checked something. - Expectations written down by the cluster owner for that result to be checked against, so the gate is asking a specific question rather than "does anything at all vouch for this". - A **provenance statement** naming the build source the cluster expects those bytes to have come from, so a byte-identical rebuild from somewhere else does not quietly satisfy the rule. - **Resolution and recording**: the gate resolves the reference to the exact bytes it admitted and stores that, so the answer to "what was actually running" survives a pointer moving afterwards. ## Where the source rule still earns its place The reflex after all of the above is to drop the source rule as security theatre. That is the wrong conclusion. It is **cheap**, it is evaluated without a network call, and it does the one thing verification is bad at: it stops the accidental fetch from somewhere nobody intended, which is a far more common event than a targeted supply-chain attack. It also gives the estate a single place to point every fetch, which is what makes availability, rate limiting and caching tractable at all. The defensible position is composition. Keep the source rule as the **coarse filter** that says where bytes may come from, and add the verification result as the **fine filter** that says what those bytes must be. Each is weak alone and the pair is not: one narrows the surface to a place you operate, the other makes the decision about content that cannot change underneath it. What you must not do is describe the coarse filter to an auditor, or to yourself, as if it were the fine one.
- Why does copying an image into an approved registry not raise how much it can be trusted?Because a copy moves bytes without changing them. The content, its build history and whatever does or does not vouch for it are all exactly as they were; the only thing that changed is the prefix your rule matches on. Everything the gate should have asked about the original is still unanswered, and now it is unanswered behind a name that looks internal.
- The gate matched an approved prefix and admitted the workload. What should it record?The exact bytes it resolved and admitted, the rule version that produced the decision, and the verification result it computed. Recording the reference alone is not enough, because a movable pointer can name different content later and the record would no longer describe what ran. The record is what turns "we have a gate" into an answer to "what was running on the day of the incident".
saying these in an interview costs you the question
- Treats an internal registry host as proof the image was built internally.
- Assumes only the release process can publish to that host.
- Thinks copying a foreign image into an approved registry improves it.
- Believes a source allowlist removes the need to check anything about the bytes.
- Calls the rule worthless and drops it instead of pairing it with verification.