A build-time token is baked into an image layer — who can read it once the image is published?

## What "baked into a layer" means A build runs as an ordered sequence of steps. Each step produces a **layer** — the filesystem changes that step made — and the finished image is that ordered stack of layers plus a document describing them and the build that produced them. Nothing about that package is private to the team that built it; it is an artifact designed to be copied. A credential can enter the package by two routes, and both of them ship: - **In the layer bytes.** A step writes the value to a file — a configuration file, a credential file for a package fetch step, an appended line in a shell profile — and the file is still there when the step ends. That file is now part of the layer. - **In the build record.** A value supplied as a **build argument** or an **environment value** is an input the builder records alongside the step it fed, so the image carries a description of how it was made that contains the value. No file has to be written for this to happen. That second route is the one that surprises people, because nothing in the running container ever shows it. ## Who the audience actually is | Who | How they get the value | |---|---| | Anyone who can pull the image | Pull it, unpack the layers, read the file or the build record — no need to run it | | Anyone with read access to the registry | Same, without ever touching a host that runs containers | | A mirror or pull-through cache | It holds its own copy of the same layers, on its own retention rules | | A host that already pulled it | The local copy survives anything you do upstream afterwards | | Anyone handed a saved copy | An image exported to a file carries the layers and the build record with it | | A later image built on this one | It inherits these layers wholesale, so the value spreads into descendants | The list is not exhaustive and that is the point: **you cannot enumerate the holders of a published image.** The honest assessment is the credential's privileges, not a guess about how many people bothered to look. ## Why the running container misleads you The most common wrong check is to start the image, list the path, see nothing, and conclude the value never shipped. Layers stack: a later step that removes a file records that the path is hidden in the assembled view, while the earlier layer that wrote the file is unchanged and is still transferred on every pull. The readable check is on the layers and the build record, not inside a running container. ## What follows from this 1. **Assume disclosure at push time.** The clock starts when the image became pullable, not when someone noticed. 2. **Size the incident by the credential, not the image.** A read-scoped feed token and a token that can publish are very different incidents even though the leak mechanism is identical. 3. **A private registry narrows the audience; it does not remove it.** Everyone who can pull still reads the value, and internal pull access is usually far wider than the build team. 4. **Fixing the build does not fix what is already published.** A corrected build produces a clean new image; every earlier image stays exactly as it was. ## The rule worth carrying An image is a distribution format. Anything inside it is published to the whole audience that can obtain it, for as long as any copy exists. A credential therefore has no business being inside one — not compressed, not encoded, not written and then hidden, not tucked into the build record. The question to ask of any value a build touches is simply: *is this still present in what gets pushed?* If the answer is yes, the value is public to the pull audience, and the response is to stop the value being accepted rather than to tidy the registry.