{"licence":{"name":"CC BY-SA 4.0","spdx":"CC-BY-SA-4.0","url":"https://creativecommons.org/licenses/by-sa/4.0/","attribution":"Atlas, a bilingual technical dictionary (https://cmaintz.github.io/tech-atlas/)"},"id":"platform/container","url":{"en":"https://cmaintz.github.io/tech-atlas/en/terms/platform/container/","da":"https://cmaintz.github.io/tech-atlas/da/terms/platform/container/"},"term":{"en":"Container","da":"Container"},"aka":{"en":[],"da":[]},"domain":["platform"],"cluster":"containers","layer":"infrastructure","status":"current","era":2013,"summary":{"en":"A sealed-off box for one program and everything it needs, sharing the host computer's kernel instead of carrying its own.","da":"En afskærmet kasse til ét program og alt, hvad det skal bruge, som deler værtscomputerens kerne i stedet for at have sin egen."},"body":{"formal":{"en":"One or more processes that the kernel keeps apart from the rest of the system - with their own view of files, network and running programs, and limits on memory and processor use - started from a container image and sharing the host's kernel.","da":"En eller flere processer, som kernen holder adskilt fra resten af systemet - med deres eget syn på filer, netværk og kørende programmer og grænser for hukommelse og processorforbrug - startet fra et container-image og med værtens kerne til fælles."},"plain":{"en":"Like shipping containers on one cargo ship - each holds its own goods in a standard box, but they all ride on the same hull and engine.","da":"Som skibscontainere på ét fragtskib - hver rummer sine egne varer i en standardkasse, men de sejler alle på det samme skrog og den samme motor."},"inPractice":{"en":"A developer at a municipality packs the citizen booking site into a container, so the exact same box runs on a laptop, in testing and in production, ending “it worked on my machine” surprises.","da":"En udvikler i en kommune pakker borgernes bookingside i en container, så præcis den samme kasse kører på en bærbar, i test og i drift, og “det virkede på min maskine”-overraskelserne forsvinder."},"whyItMatters":{"en":"Containers start in seconds and use little memory, but because they share one kernel, a flaw there can let one container break out and reach the others on the host.","da":"Containere starter på sekunder og bruger lidt hukommelse, men fordi de deler én kerne, kan en fejl dér lade én container bryde ud og nå de andre på værten."}},"deepDive":{"en":"A Linux container is not a kernel object but a convention: an ordinary process tree started with a particular combination of isolation and resource-control primitives. Namespaces give the process its own view of a global resource - mount (filesystem tree), PID (process numbering, with the entrypoint as PID 1), network (interfaces, routes, iptables/nftables rules), UTS (hostname), IPC, user (UID/GID mapping), cgroup and, since Linux 5.6, time. Control groups (cgroups, today usually the unified v2 hierarchy) cap and account for CPU, memory, PIDs and block I/O; a container that exceeds its memory limit is killed by the kernel's OOM killer rather than slowing the host down. The root filesystem is typically an overlay (overlayfs) of the image's read-only layers plus a thin writable layer that disappears with the container.\n\nNamespaces and cgroups alone are a weak boundary, so runtimes layer further restrictions on top: dropping most Linux capabilities (a container \"root\" usually lacks CAP_SYS_ADMIN, CAP_NET_ADMIN and similar), a seccomp-bpf filter that blocks rarely needed or dangerous system calls, a mandatory access control profile from AppArmor or SELinux, no_new_privs, and read-only mounts of sensitive parts of /proc and /sys. User namespaces can additionally map container UID 0 to an unprivileged host UID, so that a process that escapes is still unprivileged on the host; this is the default in rootless Podman and Docker rootless mode, but not in a typical Docker or Kubernetes setup.\n\nThe format and lifecycle are standardised by the Open Container Initiative (OCI, founded 2015): the runtime specification describes a \"bundle\" (a root filesystem plus a config.json listing namespaces, mounts, capabilities, cgroup limits and the process to run), and the image specification describes how that bundle is distributed. Windows has its own containers built on job objects and silos, with an optional Hyper-V isolation mode; they run Windows images only.\n\nThe main contrast with a virtual machine is the trust boundary. A VM is separated by a hypervisor and hardware virtualisation and runs its own kernel, so a guest kernel exploit stays in the guest. Every container on a host shares one kernel, so a kernel bug reachable through the allowed syscall surface - or a misconfiguration such as --privileged, a mounted Docker socket or a hostPath mount of / - can become a container escape. Where tenants do not trust each other, sandboxed runtimes such as gVisor (a user-space kernel) or Kata Containers (a lightweight VM per pod) are used to put a stronger boundary back. NIST SP 800-190 organises container risk into image, registry, orchestrator, container and host OS countermeasures, and treats the shared kernel as the reason to group containers on hosts by sensitivity.","da":"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.\n\nNamespaces 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.\n\nFormatet 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.\n\nDen 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."},"edges":[{"type":"requires","to":"cs/process","confidence":"high","strength":"normal"},{"type":"requires","to":"cs/kernel","confidence":"high","strength":"normal"},{"type":"contrasts-with","to":"platform/virtual-machine","why":{"en":"A virtual machine carries its own full operating system; a container shares the host's kernel, which makes it lighter but less strongly separated.","da":"En virtuel maskine har sit eget fulde styresystem; en container deler værtens kerne, hvilket gør den lettere, men mindre stærkt adskilt."},"confidence":"high","strength":"primary"},{"type":"used-with","to":"platform/microservices","confidence":"high","strength":"normal"},{"type":"used-with","to":"ai/model-serving","why":{"en":"Models are usually packed into containers with everything they need to run, so they can be served the same way everywhere.","da":"Modeller pakkes normalt i containere sammen med alt, hvad de skal bruge for at køre, så de kan serveres ens overalt."},"confidence":"medium","strength":"normal"}],"depth":2,"sources":[{"title":"NIST SP 800-190 - Application Container Security Guide","tier":"standard","publisher":"NIST"},{"title":"CNCF Cloud Native Glossary - Container","url":"https://glossary.cncf.io/container/","tier":"reference","publisher":"CNCF"}],"draft":true}