Docker eller Podman: Rootless-sikkerhed har en målbar pris

Docker og Podman kan begge køre rootless, og ingen af dem er automatisk hurtigst. Dockers rootless-dokumentation beskriver, at både daemonen og containerne kører uden root-rettigheder i et brugernavnerum. For en eksisterende Compose-installation kan rootless Docker derfor være den korteste vej til drift uden en root-privilegeret daemon; Podman kan være mere oplagt, hvis tjenesternes livscyklus skal ligge i systemd.

Ydelsen bør afgøres af den konkrete arbejdsbelastning: tid til at hente et image, starte en container, behandle trafik og skrive data er forskellige mål. Podmans manual beskriver en daemonløs motor, som i rootless-tilstand opretter et brugernavnerum og normalt kræver tildelte UID- og GID-områder; den peger også på Quadlet til drift via systemd. Filadgang, netværksopsætning og arbejdet med at flytte eksisterende tjenester hører derfor med i valget.

Samme privilegier giver en brugbar sammenligning

Rootful Docker over for rootless Podman blander motorvalg og sikkerhedsmodel i ét tal. Sammenlign først begge motorer som rootless på samme Linux-vært med samme image, lagerplacering, netværksvej og applikationsopgave. Hvis rootful-drift stadig er en mulighed, hører den til i et særskilt forsøg, hvor begge motorer igen får samme rettighedsniveau. Ellers kan en forskel i opstart eller netværk fejlagtigt blive tilskrevet produktet.

Brugernavnerum betyder, at identiteten inde i containeren skal mappes til identiteter på værten. Et bind mount kan derfor opføre sig anderledes end forventet, selv om containeren starter: tjenesten skal også kunne læse sine filer, skrive vedvarende data og starte igen under den tiltænkte bruger. Ved Podman ligger rootless-images som udgangspunkt i brugerens eget lager, og netværksfilsystemer, som ikke forstår brugernavnerum, kan give problemer. Placeringen af data og de faktiske filrettigheder er derfor en del af både sikkerheds- og ydelsesvurderingen.

Benchmarket skifter vinder med opgaven

I forsøgets tabel over containeropgaver tog instansiering fra et lokalt image på 2 GB i gennemsnit 0,70 sekund med Docker og 0,35 sekund med Podman, mens pull af et image på 2 GB fra en fjern server tog 229,78 mod 267,65 sekunder. Tallene stammer fra forsøg på én Debian-vært med bestemte programversioner, images og netværksforhold. De viser en forskel mellem opgaver, ikke en universel rangordning af motorerne.

Et image, der allerede er hentet, lægger vægten på containerens opstart. Et nyt image lægger desuden vægt på registry, forbindelsen, lagene i imaget og arbejdet med at gemme dem lokalt. Derfor kan et kortlivet job med hyppige starter give en anden vurdering end en tjeneste, der sjældent genstartes, men ofte udrulles til nye værter. Stop og fjernelse bliver relevante, når mange midlertidige containere oprettes og ryddes væk.

Eksperimentet måler administration af containere og images; det specificerer ikke et kontrolleret forsøg med både rootless og rootful drift. Tallene kan derfor ikke bruges som mål for rootless-overhead eller som et løfte om applikationens CPU- og netværksydelse. Forskellen mellem lokal opstart og pull viser, hvorfor de enkelte delopgaver skal måles hver for sig.

Netværk og lager bestemmer, hvad der mærkes

For en netværkstjeneste kan den valgte rootless-netværksvej være vigtigere end selve startkommandoen. Dockers oversigt over rootless-netværk angiver, at netværks- og portdriver påvirker gennemløb og videresendelse af klientens kilde-IP, og at en TCP/IP-stak i brugerrum generelt er langsommere end en i kernen. Portpublicering, forbindelser mellem tjenester og den kildeadresse, applikationen ser, skal fungere med den samme trafik på begge platforme. En måling uden indgående forbindelser siger lidt om en webtjeneste, hvor belastningen primært består af forespørgsler.

Lager bør deles op på samme måde. Første pull og gentagen opstart fra et allerede hentet image er forskellige hændelser; skrivning i containerens lag og skrivning til et bind mount er forskellige stier. Hvis Podmans brugerlager ligger på et andet filsystem end Dockers rootless-lager, måler man også filsystemet. Det er især vigtigt ved vedvarende data, hvor rettigheder og mount-placering kan afgøre, om tjenesten fungerer efter en genstart.

Image-størrelse er heller ikke et enkelt mål for hastighed. Et større image kan kræve mere overførsel og håndtering af lag, men den oplevede tid afhænger af, om lagene allerede findes lokalt, og hvor registry ligger. Den relevante måling er den hændelse, driften faktisk gentager: kold pull, varm start, trafik under drift eller oprydning efter et job.

Compose og systemd tæller med i migrationen

Eksisterende Compose-filer kan fortsat indgå i en Podman-løsning, men kommandoen er ikke en selvstændig implementering af hele arbejdsgangen. Podmans Compose-beskrivelse angiver, at kommandoen starter en ekstern udbyder, eksempelvis Docker Compose eller podman-compose, som taler med den lokale Podman-socket. Hvilken udbyder der er installeret, bliver dermed en konkret del af kompatibiliteten. Projektets faktiske tjenester, afhængigheder, healthchecks, navngivne volumes og CI-kommandoer afgør, hvor meget arbejde skiftet kræver.

Quadlet giver Podman en måde at beskrive containere og tilhørende ressourcer til drift via systemd. Det kan passe til en vært med få langlivede tjenester, men en eksisterende Compose-gruppe kan kræve ændringer i enheder og afhængigheder. Docker rootless kan også køre som brugertjeneste. Valget handler derfor om, hvilken driftsform der opfylder kravene med færrest ændringer, og hvem der skal eje tjenestens opstart og genstart.

Migrationskontrol for den konkrete tjeneste

Et repræsentativt forløb bør gå fra login i registry til pull, start, trafik, skrivning af data, genstart og oprydning. Brug samme privilegieniveau og vært, og skriv image-reference, filsystem og netværksvej ned for begge motorer. Så kan målt tid holdes adskilt fra arbejdet med at ændre driften.

• Compose: Kør den eksisterende definition med den valgte udbyder. Kontrollér afhængigheder, healthchecks, volumes og de kommandoer, som udvikling og CI bruger.
• Systemd: Afprøv opstart efter genstart af værten, genstart ved fejl og adgang til logs under den tiltænkte bruger. Afgør, om Compose eller særskilte brugerenheder skal eje tjenestens livscyklus.
• Netværk: Kontrollér publicerede porte, kommunikation mellem tjenester og synlig kildeadresse. Mål den trafik, applikationen normalt behandler.
• Registries og lager: Brug fuldt kvalificerede image-navne, og kontrollér login, pull og vedvarende data for rootless-brugeren. Hold kolde pulls adskilt fra varme starter.

Hvis begge motorer leverer samme funktion under samme rettigheder, kan de målte forskelle i netop denne belastning afgøre, om et skifte betaler sig. Hvis Compose-definitionen, filrettighederne eller tjenestestyringen skal ændres, hører den arbejdstid med i beslutningen sammen med ydelsen.

Læs også:

• ChatGPT, Claude eller Gemini til 20 dollar? Pakken afgør valget
• n8n, Make eller Zapier: 10 trin kan ændre hele AI-regningen
• RAG eller finjustering? Fejlvalget gør virksomhedens viden forældet