Container

En Linux-container er ikke et objekt i kernen, men en konvention: et helt almindeligt procestræ, der startes med en bestemt kombination af isolations- og ressourcestyringsmekanismer. Namespaces giver processen sit eget billede af en global ressource - mount (filtræet), PID (procesnummerering, hvor entrypoint er PID 1), network (netkort, ruter og iptables/nftables-regler), UTS (værtsnavn), IPC, user (mapning af UID/GID), cgroup og siden Linux 5.6 også time. Control groups (cgroups, i dag som regel det samlede v2-hierarki) begrænser og måler CPU, hukommelse, antal processer og blok-I/O; en container, der overskrider sin hukommelsesgrænse, bliver slået ihjel af kernens OOM killer i stedet for at gøre værten langsom. Rodfilsystemet er typisk et overlay (overlayfs) af imagets skrivebeskyttede lag plus et tyndt skrivbart lag, der forsvinder sammen med containeren.

Namespaces og cgroups er alene en svag grænse, så runtimes lægger yderligere begrænsninger ovenpå: de fleste Linux capabilities fjernes (en container-"root" mangler normalt CAP_SYS_ADMIN, CAP_NET_ADMIN og lignende), et seccomp-bpf-filter blokerer sjældent brugte eller farlige systemkald, en MAC-profil fra AppArmor eller SELinux håndhæves, no_new_privs sættes, og følsomme dele af /proc og /sys monteres skrivebeskyttet. User namespaces kan desuden mappe UID 0 i containeren til en uprivilegeret UID på værten, så en proces, der slipper ud, stadig er uprivilegeret; det er standard i rootless Podman og Dockers rootless mode, men ikke i en typisk Docker- eller Kubernetes-opsætning.

Formatet og livscyklussen er standardiseret af Open Container Initiative (OCI, stiftet 2015): runtime-specifikationen beskriver et "bundle" (et rodfilsystem plus en config.json med namespaces, mounts, capabilities, cgroup-grænser og den proces, der skal køres), og image-specifikationen beskriver, hvordan bundlet distribueres. Windows har sine egne containere bygget på job objects og silos med en valgfri Hyper-V-isolation; de kører kun Windows-images.

Den vigtigste forskel til en virtuel maskine er tillidsgrænsen. En VM er adskilt af en hypervisor og hardwarevirtualisering og kører sin egen kerne, så en udnyttet fejl i gæstens kerne bliver i gæsten. Alle containere på en vært deler én kerne, så en kernefejl, der kan nås gennem de tilladte systemkald - eller en fejlkonfiguration som --privileged, en monteret Docker-socket eller en hostPath-montering af / - kan blive til et container escape. Hvor lejere ikke stoler på hinanden, bruger man sandkasse-runtimes som gVisor (en kerne i brugerrummet) eller Kata Containers (en letvægts-VM per pod) for at genindføre en stærkere grænse. NIST SP 800-190 inddeler container-risici i modforanstaltninger for image, registry, orkestrering, container og værtens styresystem og bruger den fælles kerne som begrundelse for at gruppere containere på værter efter følsomhed.