Container image

An OCI image is a small graph of content-addressed blobs. At the top sits an image index (a "fat manifest" listing one manifest per platform, e.g. linux/amd64 and linux/arm64); each manifest points to one config blob and an ordered list of layer blobs; every reference is a descriptor holding the media type, size and digest (usually sha256) of the target. Because the manifest's own digest is a hash over those descriptors, a reference such as name@sha256:… pins the exact bytes of every layer, whereas a tag such as :2.4 or :latest is just a mutable pointer that the registry can move.

Each layer is a tar archive (typically gzip- or zstd-compressed) describing a filesystem changeset; deletions are recorded as whiteout files (.wh.name), so a file "removed" in a later layer is still present in the earlier one. This is why a secret copied into one Dockerfile step and deleted in the next remains extractable from the image. The config blob carries the runtime defaults - Entrypoint, Cmd, Env, User, WorkingDir, ExposedPorts, labels - plus the ordered list of uncompressed layer digests (diff_ids) and a history. At run time the layers are stacked with overlayfs and a writable layer is added on top; the image itself never changes.

Images are built from a Dockerfile/Containerfile with BuildKit or Buildah, or without a daemon by tools such as ko, Jib or Bazel rules. Good practice is multi-stage builds so compilers stay out of the final image, a minimal base (distroless, Alpine, Chainguard-style or scratch), a non-root USER, and pinning the base by digest. Reproducible builds (fixed timestamps via SOURCE_DATE_EPOCH, sorted file order) let independent parties rebuild and compare digests. The OCI image and distribution specifications in version 1.1 added artifactType and a subject field, so signatures, SBOMs and attestations can be stored in the registry as separate artifacts that refer to an image digest.

Security work on images centres on three questions: what is inside (SBOM generation with Syft or Trivy and vulnerability matching against the OS package database and language lockfiles), who built it (signatures and SLSA provenance, e.g. via cosign), and whether the cluster only admits approved digests (admission policy). Scanners that only read OS package metadata miss statically linked binaries and vendored code, and a clean scan today says nothing about CVEs published tomorrow, so images need continuous rescanning and regular rebuilds. An image differs from a container the way a class differs from an instance, and from a VM image in carrying no kernel.