Containere og Kubernetes: flygtige spor, der skal sikres hurtigt

Forside › Cloud- og SaaS-forensik · Gennemgået oktober 2026 · Af John Nielsen

En container er bygget til at være kortlivet. Når en pod bliver slettet, genstartet eller flyttet til en anden node, forsvinder dens skrivbare lag, dens lokale logs og dens kørende processer typisk med den. Kubernetes gør det automatisk og ofte inden for minutter, fx når en sundhedstjek fejler, eller når en deployment opdateres. Forensisk arbejde i containermiljøer handler derfor først og fremmest om at stoppe den automatiske oprydning for de relevante containere og sikre det flygtige, før orkestreringen gør det umuligt. Bagefter kommer de mere stabile kilder: images, registrets log, Kubernetes’ auditlog og nodens egne logs.

Haster det? Når en pod slettes, genstartes eller flyttes, forsvinder dens skrivbare lag, lokale logs og kørende processer typisk med den. Ved akut behov: akut forensisk sikring; hastesager koster ekstra.

Hvad en container består af

En container kører fra et image, der består af skrivebeskyttede lag. Oven på dem lægger container-runtimen et skrivbart lag, hvor alle ændringer under kørsel havner: nye filer, ændrede konfigurationsfiler, downloadede værktøjer, slettede filer markeret som fjernet. Det skrivbare lag er derfor det vigtigste spor efter, hvad der skete inde i containeren. Det ligger på nodens disk, så længe containeren findes, og fjernes, når containeren slettes.

Imaget identificeres entydigt ved et digest, en SHA-256-værdi af dets manifest. Et tag som “latest” kan pege på forskellige images over tid; digestet kan ikke. Notér altid digestet for det image, der faktisk kørte.

Hvor sporene ligger

Containerens skrivbare lag · Til containeren slettes
Containerens standard output og fejloutput · Roteres på noden og slettes med containeren
Kørende processer og netværksforbindelser · Til processen stopper
Kubernetes-hændelser (events) · Kort, ofte omkring en time som standard
Kubernetes’ auditlog · Afhænger af konfiguration og platform
Nodens systemlogs og runtime-logs · Afhænger af nodens logrotation
Image-registrets log · Afhænger af registret
Centrale logs (logplatform, SIEM) · Afhænger af opsætningen

API-serverens standard for, hvor længe events gemmes, er én time. Containerlogs på noden roteres af kubelet, som standard ved 10 MiB og med højst fem filer pr. container. Begge værdier kan være ændret i den konkrete klynge og bør slås op i konfigurationen.

Kubernetes’ auditlog registrerer kald til API-serveren: hvem oprettede, ændrede eller slettede pods, hemmeligheder, roller og bindinger, og hvem der åbnede en shell i en container. Den er styret af en auditpolitik og skal være slået til. I administrerede Kubernetes-tjenester sendes den til platformens logtjeneste, hvis den er aktiveret der. Standarden er forskellig: I GKE skrives administrative auditlogs altid til Cloud Logging, mens auditlog i EKS og AKS skal slås til, i EKS som kontrolplanslogning og i AKS via diagnostikindstillinger.

Første skridt: stop oprydningen

Inden du sikrer noget, skal du forhindre, at Kubernetes selv sletter det:

Undgå at slette podden eller genstarte deploymentet, selv om det er det naturlige driftsvalg.
Fjern podden fra trafikken ved at ændre dens labels, så den ikke længere matcher servicen. Deploymentet starter så en ny pod, mens den gamle står urørt.
Isolér netværket for podden med en netværkspolitik, hvis den skal afskæres fra omverdenen.
Markér noden som ikke-planlægbar, så der ikke flyttes nye pods til den, og så den ikke dræneres automatisk.
Sæt automatisk skalering af noder på pause, hvis den kan fjerne noden.

Hver af disse handlinger ændrer miljøet og skal noteres med tidspunkt og person. De samme overvejelser om isolation og artefakter gælder for andre systemer; se Isolering og genopsætning.

Sikring i rækkefølge

Rækkefølgen følger flygtigheden. Princippet er beskrevet i Flygtighedsorden.

Metadata fra Kubernetes: Gem den fulde definition af podden, deploymentet, replikasættet og relevante hemmelighedsreferencer, roller og bindinger, samt de hændelser, der findes for dem. Det er tekst og hurtigt at tage.
Containerlogs: Hent standard output fra den aktuelle og den forrige instans af hver container i podden.
Processer og forbindelser: Hent proceslister og netværksforbindelser fra noden, ikke fra en shell i containeren, så du ikke ændrer containeren. Live response-overvejelserne er beskrevet i Live response.
Det skrivbare lag: Eksportér containerens filsystem eller kopiér det skrivbare lag fra nodens disk. Nyere Kubernetes-versioner har en funktion til forensisk checkpoint af en kørende container med hukommelse via kubelet. Den kræver, at container-runtime understøtter det, og dens status afhænger af versionen, så den skal afprøves, før den indgår i en sikringsplan.
Image: Hent imaget fra registret ud fra digestet, og gem det som en arkivfil.
Noden: Tag et snapshot af nodens disk, hvis den er en virtuel maskine. Se Snapshots af cloud-diske som forensisk kopi.
Auditlog og centrale logs: Eksportér for perioden.
Hashværdier for alle filer straks efter sikring.

Noden og runtime

Under containerne ligger en almindelig Linux-maskine. Nodens systemlogs, container-runtimens egen log og kubelet-loggen viser, hvornår containere blev startet, stoppet og genstartet, hvilke images der blev hentet, og om noden havde fejl. På mange noder ligger disse logs i journald. Sikringen følger samme fremgangsmåde som for andre Linux-servere; se Linux-servere i undersøgelser.

Nodens disk rummer også de images, der er hentet til den, og de skrivbare lag for containere, der stadig findes. Et snapshot af noden kan derfor bevare containere, som Kubernetes senere fjerner, men kun dem, der fandtes på snapshottidspunktet.

Hvor imaget kom fra

Mange spørgsmål handler ikke om, hvad der skete inde i containeren, men om hvordan en bestemt kode kom i drift. Svaret ligger i kæden fra kildekode til kørende container:

CI/CD-systemets log viser, hvilket build der byggede imaget, fra hvilket commit og hvornår.
Registrets log viser, hvem der skubbede imaget, og hvornår det blev hentet af klyngen.
Kubernetes’ auditlog viser, hvem der ændrede deploymentet til at bruge det nye image.

Digestet er det fælles id, der binder kæden sammen. Er imaget signeret, kan signaturen dokumentere, at det kom fra den forventede byggeproces. En uoverensstemmelse mellem digest i registret og digest på noden er et fund, der skal forklares.

Fejlkilder i fortolkningen

Delt identitet. Mange pods kører med samme tjenestekonto. En handling fra en tjenestekonto peger på et workload, ikke på en person.
Genstarter. En container, der er genstartet, har et nyt skrivbart lag. Ændringer fra før genstarten er væk, medmindre de var på et vedvarende volumen.
Vedvarende volumener overlever podden og kan være delt mellem flere pods. Ændringer på et volumen kan stamme fra en anden pod.
Image-tags kan være flyttet. Brug digest.
Tid. Containere arver nodens ur, men logplatforme kan tilføje deres eget tidsstempel ved modtagelse.
Shell i containeren. Den, der åbner en shell for at kigge, ændrer containeren og efterlader egne spor. Notér det, hvis det er sket før sikringen.

Hvad sporene kan og ikke kan bevise

Sikrede containerlag, logs og auditlog kan vise, hvad der kørte, hvilke filer der blev ændret i containeren, hvilke API-kald der blev foretaget mod klyngen og af hvilken identitet, og hvornår. De kan ikke vise noget om containere, der var slettet før sikringen, medmindre centrale logs fangede dem, og de kan ikke føre en tjenestekonto tilbage til en person uden logs fra fx CI/CD-systemet eller identitetsudbyderen.

Dokumentation

Notér klynge, version, navnerum, pods, containere, image-digests, noder, de handlinger, der blev udført for at bevare tilstanden, sikringsmetode, værktøjer og versioner samt hashværdier. Beskriv hvilke kilder der ikke fandtes, fx en auditlog, der ikke var slået til, og hvilke containere der var forsvundet, før arbejdet begyndte. Angiv også, hvilke driftshandlinger der blev udført, før sikringen begyndte, fx genstarter eller nye deployments, så læseren kan vurdere, hvad der kan være gået tabt.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Cloud- og SaaS-forensik

Læs også: Feltlog og ændringshistorik i CRM-systemer · Hostingleverandørens logs: hvad kan leveres, og hvor hurtigt forsvinder det

→ Logundersøgelse · Haster det? Forensisk sikring (hastesager koster ekstra) · For IT-sikkerhed og SOC · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik