Minimal Container Images

What Is Minimal Container Images?

A production image carrying a package manager, a compiler, a shell and network utilities turns a limited application flaw into a working toolkit. The attacker brings nothing; the image already shipped it. You'll use one command from a checkout-service bug to find curl and read the instance role credentials from the metadata endpoint at 169.254.169.254. Then you'll split the build into two stages, copy only the compiled artifact into a distroless final image, and watch a shell fail to open in the redeployed container because there is none.

What You'll Learn in Minimal Container Images

• Recognize that a shell, package manager, compiler, and network tools shipped in a runtime image become an attacker's toolkit
• Trace how one command from an application flaw uses shipped curl to read instance role credentials from 169.254.169.254
• Configure a multi-stage build that keeps build tooling in the build stage and copies only the compiled artifact forward
• Apply a distroless final image and verify that a shell cannot be opened in the redeployed container
• Explain how removing the shell and package manager breaks the easiest path from limited code execution to control

Minimal Container Images — Training Steps

1. A foothold in checkout

   Bob does not start with a shell. The checkout service builds PDF shipping labels and shells out to do it, and one field in that request is not sanitised. He injects a probe to confirm he can run a command, and to see who and where he is.

2. Everything the image ships

   Bob has one-command-at-a-time execution as the app, but no shell yet. That is usually where an attacker stalls, unless the container hands him a toolkit. Before doing anything loud, he checks what is already installed.

3. Curl the cloud credentials

   The container runs in the cloud, and every cloud instance exposes a metadata service on a fixed internal address that hands out the machine's temporary role credentials. Reaching it needs an HTTP client. The image shipped one.

4. How one command became a breach

   Bob's access to the app was tightly limited.

5. A shell in a runtime container

   Skelwyn runs endpoint detection on its container hosts. It does not know what each container is for; it reports behavior that does not fit a runtime.

6. Confirm what shipped

   Alice reproduces what the attacker found: she asks the running container which of those tools it actually contains.

7. A 412MB runtime

   The toolkit is not free. It is weight, and it is attack surface. Alice checks the size of the image the service actually runs.

8. Where the toolkit gets in

   The image is built from one Dockerfile. Alice opens it to see why a runtime container ends up carrying a compiler.

9. One stage, everything ships

   The image is built and run in a single stage, so whatever the build needs, the runtime also carries.

10. Split build from runtime

    The fix is a multi-stage build: keep the full image and its toolchain as a build stage that compiles the app, then copy only the finished app and its dependencies into a distroless runtime image that has no shell, no package manager, and no compiler.