Container-image

Et OCI-image er en lille graf af indholdsadresserede blobs. Øverst ligger et image index (et "fat manifest" med ét manifest per platform, fx linux/amd64 og linux/arm64); hvert manifest peger på én config-blob og en ordnet liste af lag-blobs; hver reference er en deskriptor med medietype, størrelse og digest (normalt sha256) for målet. Fordi manifestets egen digest er en hash over deskriptorerne, låser en reference som navn@sha256:… de præcise bytes i hvert lag, mens et tag som :2.4 eller :latest blot er en foranderlig peger, som registryet kan flytte.

Hvert lag er et tar-arkiv (typisk komprimeret med gzip eller zstd), der beskriver et sæt ændringer i filsystemet; sletninger registreres som whiteout-filer (.wh.navn), så en fil, der "fjernes" i et senere lag, stadig findes i det tidligere. Derfor kan en hemmelighed, der kopieres ind i ét Dockerfile-trin og slettes i det næste, stadig trækkes ud af imaget. Config-blobben indeholder runtime-standarderne - Entrypoint, Cmd, Env, User, WorkingDir, ExposedPorts, labels - plus den ordnede liste over ukomprimerede lag-digests (diff_ids) og en historik. Ved kørsel stables lagene med overlayfs, og et skrivbart lag lægges ovenpå; selve imaget ændres aldrig.

Images bygges fra en Dockerfile/Containerfile med BuildKit eller Buildah eller uden dæmon med værktøjer som ko, Jib eller Bazel-regler. God praksis er multi-stage builds, så compilere ikke kommer med i det endelige image, et minimalt base-image (distroless, Alpine, Chainguard-lignende eller scratch), en USER, der ikke er root, og at base-imaget låses via digest. Reproducerbare builds (faste tidsstempler via SOURCE_DATE_EPOCH, sorteret filrækkefølge) lader uafhængige parter genbygge og sammenligne digests. OCI's image- og distributionsspecifikationer i version 1.1 tilføjede artifactType og et subject-felt, så signaturer, SBOM'er og attestationer kan gemmes i registryet som selvstændige artefakter, der henviser til et images digest.

Sikkerhedsarbejdet med images drejer sig om tre spørgsmål: hvad er der indeni (SBOM-generering med Syft eller Trivy og matchning af sårbarheder mod styresystemets pakkedatabase og sprogenes lockfiler), hvem byggede det (signaturer og SLSA-provenance, fx via cosign), og lukker klyngen kun godkendte digests ind (admission-politik). Scannere, der kun læser styresystemets pakkemetadata, overser statisk linkede binærer og vendoreret kode, og en ren scanning i dag siger intet om CVE'er, der offentliggøres i morgen, så images skal genscannes løbende og genbygges jævnligt. Et image forholder sig til en container, som en klasse forholder sig til en instans, og adskiller sig fra et VM-image ved ikke at indeholde nogen kerne.