Hvorfor privilegeret tilstand er bredere, end en VPN har brug for

Containeren ville ikke åbne sin tunnel, så det privilegerede flag kom ind, og nu virker det. Den sekvens fastslog kun, at mindst én tilladelse manglede, og den siger intet om hvilken. Privilegeret tilstand giver et sæt evner og enhedsadgang, der er langt bredere, end en tunnelgrænseflade har brug for.

Hvad flaget faktisk ændrer

En privilegeret container får brede evner og adgang til værtens enheder, hvilket er en meget større bevilling, end netværksvejen kræver. Det præcise sæt dokumenteres af runtime-miljøet og fastlægges ikke af overleveringer, og Docker-dokumentationen om at køre containere beskriver de tilgængelige privilegiumindstillinger. Én gennemlæsning er nok til at se, at tunnellering er en lille del af det hele.

To snævrere krav dækker de fleste VPN-containere. At konfigurere en grænseflade kræver evnen til netværksadministration, og at åbne tunnelenheden kræver adgang til netop den enhedsknude. Det er separate bevillinger, og selv begge tilsammen er snævrere end den samlede indstilling. Resten af det privilegerede sæt har intet med tunnelen at gøre. Det findes for arbejdsbelastninger, der virkelig har brug for adgang på værtsniveau, og en VPN-container er normalt ikke en af dem.

Knyt hver fejl til én forudsætning

Fejlmeddelelsen fortæller dig, hvilken forudsætning der mangler, hvis du læser den, før du undertrykker den. En meddelelse om en enhedsknude navngiver enheden, en meddelelse om en handling, der ikke er tilladt, navngiver en evne, og en meddelelse om et modul eller en sysctl navngiver kernestøtte. Hver af dem har en anden løsning, og kun én af dem er en evne.

En manglende konfigurationsfil forbliver manglende, efter alle evner er givet, og derfor ændrer privilegeret tilstand nogle gange slet intet. Containeren starter, tunnelen fejler stadig, og den egentlige fejl handlede aldrig om tilladelser. Kernestøtte er det tredje tilfælde og det letteste at læse forkert. Et modul, der ikke er indlæst på værten, kan ikke indlæses indefra en uprivilegeret container, og at give flere evner inde i containeren ændrer ikke værtens tilstand.

Kontrollér kravet, ikke symptomet

Start med det minimale kald, som image’et dokumenterer, kør det, og gem den præcise fejltekst. Tilføj derefter én bevilling ad gangen, og notér hvilken tilføjelse der ændrede resultatet.

ls -l /dev/net/tun
docker run --rm --cap-add NET_ADMIN --device /dev/net/tun image:tag
ip -br link show type tun

En container, der kan se enheden og har evnen, men stadig fejler, fortæller dig, at problemet er et andet sted. Det er et nyttigt resultat, og privilegeret tilstand ville have skjult det.

Kontrollér også enhedstilladelserne på værten, fordi en korrekt tildelt enhedsknude med det forkerte gruppeejerskab giver den samme fejl som en manglende bevilling.

Skriv den snævreste bevilling ned, der virker

Skriv hver enhed og evne ned, som udrulningen har brug for, sammen med fejlen, der begrundede den. Den registrering er det, der gør det muligt for den næste person at fjerne noget sikkert, og det er det, en revisor vil bede om, når en container rapporteres som privilegeret.

Gennemgå også den omkringliggende kontekst, fordi værtsnetværk, værtsmonteringer og runtime-indstillinger hver kan udvide virkningen af en bevilling. Et isoleret laboratoriekald, der kombinerer dem alle, er ikke en produktionskonfiguration, hvor godt det end virkede. Test applikationen, dens DNS-adfærd og en tunnelfejl, før du kalder udrulningen færdig. Tilladelse til at oprette en grænseflade er ikke en udgangspolitik, og en container, der kan tunnellere perfekt, ruter stadig alt, hvad applikationen sender.