Du kan køre Docker i production i månedsvis uden at se problemer. Containere starter, apps svarer, intet går galt. Så åbner én port eller én forkert permission en dør, som angribere ikke selv skulle have åbnet. De fleste Docker-sikkerhedsfejl ser ikke ud som fejl, før noget går helt galt.
Denne artikel dækker de specifikke opsætninger, der udsætter containeromgivelser for risiko, hvad hver enkelt muliggør for en angriber, og afsluttes med en tjekliste, du kan køre mod din egen opsætning i dag.
Hvorfor Docker-sikkerhed er sværere end det virker
Containere virker isolerede. Du starter én, den kører sit eget procesrum, og indefra ser den næste container ikke ud til at eksistere. Du får isolering, men det er kun delvis. Containere deler værtsmaskinens kernel, hvilket betyder, at en proces indeni en container under bestemte betingelser kan nå værtsystemet helt.
Docker-containere er konfigureret for udvikler-bekvemmelighed, ikke hardening til production. Root-adgang er tændt. Alle porte kan bindes til alle interfaces. Ingen runtime-overvågning. De fleste udvikler accepterer disse indstillinger, udrulles containeren og går videre. Det er en rimelig tilgang til at komme i gang; det er ikke en færdig sikkerhedsstilling.
Ifølge Red Hat's 2024 State of Kubernetes Security-rapport, 67 % af organisationerne forsinket eller bremset applikationsudrulning på grund af container- eller Kubernetes-sikkerhedsproblemer. Den friktion kommer som regel ikke fra angreb. Det kommer fra hold, der opdager, at deres container-opsætninger havde brug for hardening, som de ikke havde bygget ind.
Vi ser ofte containere køre i production med den samme opsætning, som de havde på en developers lokale maskine. Det er her, Docker-sikkerhedsfejl har tendens til at ophobe sig stille og fredeligt uden synlige symptomer, før noget bliver revideret eller fejler.
De fejl, der skaber disse huller, er specifikke, forudsigelige og for det meste undgåelige, startende på konfigurationsniveauet.
Almindelige Docker-konfigurationsfejl
De fleste container-brud starter ikke med en zero-day-udnyttelse. De starter med en konfiguration sat på dag et, uden meget tanke på netværkseksponering eller privilegieomfang.
Standard-Docker-indstillinger er bygget til at fungere. Hullet mellem funktionelt og sikkert er der, hvor Docker-container-sikkerhedsrisici samler sig, især i selvhostede opsætninger, der bliver udrullet og aldrig genbesøgt.
Vi ser dette mønster ofte: containere på offentlige-IP-servere med port-bindinger, brugerindstillinger og netværkskonfigurationer præcis som de var ved den oprindelige udrulning.
Kørsel af containere som root
Når du starter en Docker-container uden at specificere en bruger, køres den som root. Det betyder, at enhver proces indeni containeren, herunder din applikation, har root-niveau-privilegier inden for containerens namespace.
Root indeni en container er ikke det samme som root på værtsserien, men adskillelsen er ikke absolut. Privilege-escalation-exploits rettet mod runtime, som den velkendte runc CVE-2019-5736 og lignende runtime-fejl, kræver ofte en root-container-proces for at lykkes.
Ikke-root-containere fjerner root-proceskravet, som disse exploits er afhængige af, og indsnævrer betydeligt angrebsfladen for denne klasse af sårbarhed, selvom de ikke helt eliminerer container-escape-risiko.
Tilføjelse af en USER-direktiv til din Dockerfile løser dette. Nogle officielle images leveres med en ikke-privilegeret bruger, som du kan aktivere med en USER-direktiv, men mange bruger stadig som standard root uden en klar bruger til appen. I disse tilfælde opretter du brugeren i Dockerfile, før du skifter til den. For de fleste selvhostede opsætninger fjerner denne enkelt ændring en helt kategori af eskaleringsrisiko.
Eksponering af for mange porte til det offentlige internet
Når du udgiver en port med Docker, skriver Docker sine egne iptables-regler direkte. Disse regler køres før værtsmaskine-niveau firewall-regler. Dette er en velkendt adfærd rapporteret af fællesskabet og dokumenteret i Docker's pakkefiltreringsvejledning, ikke en fejlkonfiguration, og det betyder, at UFW og lignende værktøjer ikke blokerer det, som Docker allerede har åbnet.
Docker skriver direkte til iptables og omgår UFW- og firewalld-standardindstillinger på mange Linux-værter. Det betyder, at en port bundet til 0.0.0.0 kan være offentligt tilgængelig, selv når din firewall ser ud til at være konfigureret. Cloud-sikkerhedsgrupper og DOCKER-USER chain-regler kan stadig blokere den trafik, så den faktiske eksponering afhænger af dit specifikke netværksopsætning.
Bind tjenester til 127.0.0.1, hvor det er muligt, direccionér offentligt trafikerede trafik gennem en omvendt proxy, og udgiv kun det, der virkelig kræver ekstern adgang. En omvendt proxy er den mest pålidelige måde at kontrollere, hvad der vises udefra værten.
Ignorering af netværksisolation mellem containere
Enhver container på det netværk kan nå enhver anden container på det uden begrænsninger. Standard-broen anvender ikke trafikfiltrering mellem containere, der deler den, og de fleste opsætninger ændrer aldrig denne konfiguration.
Hvis en container bliver kompromitteret, bliver den åbne kommunikation til en lateral bevægelsessti. En frontend-container kan nå en database, en intern API, eller alt andet på det samme standard-bridge-netværk, selv når den adgang aldrig var tiltænkt.
Brugerdefinerede netværk giver dig eksplicit kontrol over, hvilke containere der kan kommunikere, men et enkelt brugerdefineret netværk, der deles af alle dine tjenester, tillader stadig fri inter-container-trafik. Reel isolering kræver, at tjenester, der ikke bør kommunikere med hinanden, sættes på separate netværk. Sluk for standard-broen er udgangspunktet, ikke målstregen.
Overseelse af Docker-soklen
Docker-soklen på /var/run/docker.sock er kontrolgrænsefladen for hele Docker-motoren. Montering af den ind i en container giver den container direkte API-adgang til daemonen, der kører på værten.
Med denne adgang kan en container starte nye containere, montere værtskataloger, inspicere og ændre kørende containere og effektivt kontrollere værtsmaskinen. Angrebsfladen svarer til root på værten, hvilket er grunden til, at ethvert værktøj, der kræver sokeladgang, fortjener omhyggelig vurdering.
For de fleste brugstilfælde findes der mere sikre alternativer: omfang API'er eller Docker-administrationværktøjer der ikke kræver sokeladgang. Docker-i-Docker har sine egne sikkerhed og operationelle kompromiser og er ikke en ligetil erstatning.
Konfigurationsfejl skaber den indledende eksponering. Billedvalg og afhængigheder afgør, hvordan den eksponering forstærkes over tid.
Billede- og hemmeligehedsfejl, der overlever containeren
Når du stopper en container, stopper konfigurationsfejlene i den med den. Når du genopbygger fra et billede, der indeholder en sårbarhed eller hardkodet legitimationsoplysninger, genstarter problemet med containeren. Fejl på billedniveau nulstilles ikke mellem installationer.
De rejser med billedet til hvert miljø, der henter det, hvert register, der lagrer det, og hvert teammedlem, der kører det. Den vedholdenhed gør billede- og hemmeligehedsstyring til en særlig risikokategori, der er værd at revidere separat fra konfiguration.
Vi ser dette mønster ofte: et billede valgt omhyggeligt ved projektstart og aldrig genopbygget siden, der langsomt driver væk fra det sikkerhedsgrundlag, det oprindeligt repræsenterede.
Brug af upålidelige eller forældede billeder
Offentlige registre er åbne for alle. Ondsindede billeder er blevet distribueret gennem Docker Hub med crypto-minere og bagdøre indlejret i laghistorik, der vedvarer på tværs af containergenstart. Verifikation før pull betyder noget, især for billeder fra uofficielle eller ukendte udgivere.
Det separate problem er foraldelse. Et officielt billede, du hentede for seks måneder siden og aldrig genopbyggede siden, har akkumuleret urettet Docker-sårbarheder med hver CVE, der blev offentliggjort mod dets pakker. Billedet er ikke ødelagt. Det er bare ikke længere aktuel.
Sonatype's 2024 State of the Software Supply Chain-rapport viste, at 95% af tiden, hvor en sårbar komponent forbruges, er en rettet version allerede tilgængelig, og 80% af programafhængigheder forbliver ikke-opgraderede i over et år. Det mønster er også relevant for Docker-basis-billeder, da de bygger på de samme open source-pakker.
Brug officielle images fra verificerede forlag og fastgør specifikke versionsmærker i stedet for at stole på "latest". Etabler en regelmæssig genopbygningscyklus for at holde dine images opdaterede.
Hardcodede hemmeligheder i Docker-filer og Compose-filer
Legitimationsoplysninger, der er skrevet ind i en Docker-fil via ENV eller ARG-instruktion, hardkodet i en Compose-miljøblok, sendt som build-argumenter eller gemt i en .env-fil committed til versionskontrol, forsvinder ikke når du stopper containeren. De bliver tilbage i image layer-historikken eller kildekontrol, tilgængelige for enhver, der kan nå en af dem.
Det er en af de mest overset sikkerhedsfejl, fordi det ikke forårsager synlige problemer under udvikling. En API nøgle i en ENV-instruktion fungerer korrekt. Den er også i dit repository, bagt ind i dit image, og distribueret overalt hvor det image bliver sendt hen.
Modern Docker Compose har en indbygget mekanisme til hemmeligheder, der monterer loginoplysninger under kørsel uden at bake dem ind i afbildet. Docker's hemmeligheder API og eksterne hemmeligheds-managere følger det samme princip. Det er disse muligheder, der holder loginoplysninger helt uden for build-artefakter og committed filer.
Miljøvariabler under kørsel er bedre end hardcodede legitimationsoplysninger, men de er stadig synlige i Docker inspect-output, logs og crash dumps. Det er et fremskridt fra secrets bagt ind i koden, men ikke en endelig løsning.
Ikke regelmæssigt opdatering af containerafbilder
Det er almindeligt at køre det samme image i månedsvis. Hver dag der går efter, at en ny sårbarhed bliver offentliggjort, men før du genbygger, bærer dine containere et eksponeringsvindue der vokser uden nogen synlig ændring.
Etabler en fast genopbygningsplan. Automatiser processen hvor det er muligt, og kør en sårbarhedscanner regelmæssigt mod dine nuværende images. Målet er ikke perfektion. Det er at reducere tiden mellem en patch bliver udgivet og den bliver deployed.
Adgangskontrol og overvågning kommer ofte i baggrunden ved hurtige deployments. Og det er netop de områder, hvor hændelser forbliver uopdagede længst.
Manglende adgangskontrol og indsyn
Når en container kører med en solid konfiguration og aktuelle images, er der stadig to kategorier af fejl tilbage. Begge er usynlige af natur: du mærker ikke et svagt adgangskontrol-problem før nogen udnytter det, og du opdager ikke et monitoringhuller før du skal undersøge aktivitet, der aldrig blev logget.
Det samme Red Hat 2024-forskning fandt, at 42% af teams manglede tilstrækkelige muligheder til at håndtere containersikkerhed og relaterede trusler.
Vi ser ofte, at mangler i overvågningen først bliver synlige, når der skal udredes en hændelse. Når synlighed pludselig bliver vigtig, handler det som regel om at reagere på noget, der allerede er sket, i stedet for at forebygge det.
Svag godkendelse og eksponerede administrationspaneler
Et containeradministrationsdashboard på en offentlig IP uden godkendelse kræver ikke en sofistikeret angriber. Det kræver bare, at de kender adressen. Det er en lavere risiko end de fleste teams er klar over.
Selvhostede overvågnings- og administrationværktøjer leveres typisk med en webgrænseflade, der er tilgængelig på alle netværksgrænseflader. Hvis du lader dem køre på en offentlig IP-adresse uden godkendelse foran dem, svarer det til at lade et adminpanel stå ulåst - bare i containerformat.
Godkendelse, en omvendt proxy og privat netværksplacering er udgangspunktet. Adgangskontrol er et konfigurationstrin, du tilføjer til ethvert administrationsgrænsesnit – ikke noget, der leveres aktiveret.
Det samme princip gælder for Docker CLI og GUI-administration; adgang på administratorniveau til daemonen medfører samme risiko uanset interface.
Du Overvåger Ikke, Hvad Dine Containere Laver
Hvis en container bliver kompromitteret, efterlader angriberen et spor: ændringer i procesadfærd, uventede netværksforbindelser og uventede filmodifikationer. Uden logindsamling på plads eksisterer sporet ikke i en form, du kan handle på.
Centraliseret logindsamling, container-auditlogning og runtime-overvågningsværktøjer giver dig dataene til at opdage unormal aktivitet, før den eskalerer. Målet er ikke at analysere hver linje. Det er at have dataene tilgængelige, når du skal undersøge.
Container-opsætninger, der kører stille i produktion uden logpipeline og uden alarmer, er ikke lavvarteret. De er uinspicerede. Det er to forskellige driftstilstande.
Hvorfor infrastrukturmiljøet også betyder noget
Container-sikkerhed starter med konfiguration, men konfigurationen kører oven på infrastruktur. En host med fejlkonfigureret netværk, delte ressourcer eller ingen filtrering på netværksniveau skaber forhold, der påvirker alle containere ovenfor. At få containeropsætningen rigtigt og serveropsætningen rigtigt er to separate opgaver.
Mange sikkerhedsgab forstørres af forhold, som containerene selv arver:
- En delt-lejer-server uden hardwareisolation mellem lejere
- En host-kernel uden patches
- En host uden indbygget filtrering på netværksniveau
Det fjerner ikke behovet for konfigurationstrinene ovenfor, da korrekt container-hardening betyder noget uanset infrastrukturflagen. Start på isoleret infrastruktur fjerner ét lag af bekymring fra ligningen.
Hos os tilbyder vi to veje alt efter hvad din opsætning kræver:
- Linux VPS: et rent miljø til at implementere selv og anvende hardening-trin fra denne artikel
- Portainer VPS: et one-click-alternativ med forudinstalleret; serveren starter, og du er allerede i dashboard'et
Begge muligheder kører på samme infrastruktur: KVM-virtualisering, AMD EPYC Ryzen 9-processorer ved op til 5,7 GHz boost-clock, DDR5-hukommelse, NVMe SSD-lager, op til 40 Gbps netværk, og gratis DDoS-beskyttelse via BuyVM-filtrering på tværs af 12 globale lokationer med 99,95% oppetidsgaranti.
For et dybere blik på at køre på en VPS dækker vi det i en dedikeret artikel.
Et praktisk sikkerhedstjekliste til containerimplementeringer
Sikkerhedsfejlene ovenfor kommer for det meste fra enkelt konfigurationsbeslutninger, som er taget én gang og aldrig genbesøgt. Kør dette tjekliste mod en eksisterende opsætning og find disse gab. Det fungerer som en revision, ikke en implementeringsvejledning.
Disse sikkerhedspraksisser dækker, hvordan du sikrer containere mod de mest almindelige konfigurationsfejl, der er beskrevet ovenfor.
Hurtig reference: Alle 9 fejl
| Fejl | Kategori | One-liner rettelse |
| Kører som root | Konfiguration | Tilføj USER direktiv til din Dockerfile |
| Porte bundet til 0.0.0.0 | Konfiguration | Bind til 127.0.0.1 og rut gennem en reverse proxy |
| Ingen netværksisolation | Konfiguration | Del tjenester på tværs af separate brugerdefinerede netværk baseret på adgangsbehov. |
| Docker socket monteret | Konfiguration | Fjern monteringen; brug scoped API-tokens eller alternativer |
| Upålidelige eller forældede images | Billede | Brug officielle images med fastlagte versionsmærker |
| Hardcodede hemmeligheder | Billede | Flyt legitimationsoplysninger til miljøvariabler ved kørsel eller en secrets manager |
| Ingen tidsplan for genbygning af image | Billede | Etabler en månedlig genbygningscyklus og automatiser hvor det er muligt |
| Uautentificerede dashboards | Adgang | Tilføj godkendelse og flyt administrationsgrænsefladerne til private netværk |
| Ingen indsamling af containerlogge | Adgang | Opsæt centraliseret logning og kørselsorientering |
Vi anbefaler at køre det mod eksisterende opsætninger først, da det er der, gapene højest sandsynligt allerede er til stede.
Containere kører som ikke-root-bruger: Tjek dine Docker-filer for en USER-direktiv. Hvis den ikke findes, kører containeren som root.
Portbindinger begrænset til localhost eller via proxy: Kør docker ps og gennemgå portbindinger. En 0.0.0.0:PORT-post kan være offentligt tilgængelig på værter, hvor ingen upstream security group, ekstern firewall eller DOCKER-USER chain-regel blokerer den.
Brugerdefinerede bridge-netværk i brug: Containere på Docker's standard bridge kan nå hinanden frit. Containere på det samme brugerdefinerede bridge kan stadig kommunikere med hinanden, så opdel tjenester på separate netværk efter tillidsgrænse for faktisk isolation.
Docker socket ikke monteret i containere: Tjek Compose-filer og kørselargumenter. Hvis /var/run/docker.sock vises som et volumen, skal du bekræfte, at det er påkrævet og bevidst.
Basis-images fra verificerede udgiver med fastlagte versioner: En FROM ubuntu:latest trækker en uspecificeret, potentielt forældet version. Fastlæg en specifik release.
Ingen hemmeligheder i Docker-filer, Compose-filer eller buildargumenter: Image layer-historik bevarer legitimationsoplysninger efter sletning af container. Brug Compose secrets, Swarm secrets, build secret mounts eller en ekstern secrets manager. Miljøvariabler ved kørsel er bedre end hardcodede værdier, men vises stadig i inspect-output og logge.
Genbygningsplan for image defineret: Gamle images samler sårbarheder. En månedlig genbygningscyklus holder eksponeringsvinduer håndterbare for de fleste opsætninger.
Administrationsgrænsefladerne beskyttet af godkendelse: En hvilken som helst dashboard på en offentlig IP uden godkendelse er et åbent indgangspunkt. Placering på et privat netværk er at foretrække hvor det er muligt.
Containerlogfiler bliver indsamlet: Uden en logpipeline afhænger opdagelse af hændelser af synlig systembelastning. Det er et sent signal at handle på.
Konklusion
Docker's standardkonfiguration er bygget for bekvemmelighed, ikke sikkerhed. De fleste fejl dækket i denne artikel stammer fra indstillinger, der aldrig blev ændret efter første installation, ikke fra sofistikerede angreb.
Løsningerne er primært engangs-konfigurationsbeslutninger: en USER-direktiv, en ændring af portbinding, et brugerdefineret netværk, en genopbygningsplan. Ingen af dem kræver nye værktøjer for de fleste setups.
At få containerens konfiguration rigtig er den første opgave. Den infrastruktur, den kører på, er den anden. Begge betyder noget, og ingen erstatter den anden.
