Hvorfor privilegert modus er bredere enn en VPN trenger

Containeren ville ikke åpne tunnelen sin, så det privilegerte flagget ble lagt inn, og nå virker det. Den sekvensen fastslo bare at minst én tillatelse manglet, og den sier ingenting om hvilken. Privilegert modus gir et sett med evner og enhetstilgang som er langt bredere enn et tunellgrensesnitt trenger.

Hva flagget faktisk endrer

En privilegert container får brede evner og tilgang til vertens enheter, noe som er en mye større innvilgelse enn nettverksveien krever. Det nøyaktige settet dokumenteres av kjøretidsmiljøet og fastsettes ikke av overlevering, og Docker-dokumentasjonen om å kjøre containere beskriver de tilgjengelige privilegiealternativene. Én gjennomlesning er nok til å se at tunnelen er en liten del av helheten.

To snevrere krav dekker de fleste VPN-containere. Å konfigurere et grensesnitt krever evnen til nettverksadministrasjon, og å åpne tunellenheten krever tilgang til nettopp den enhetsnoden. Dette er separate innvilgelser, og selv begge sammen er snevrere enn det generelle alternativet. Resten av det privilegerte settet har ingenting med tunnelen å gjøre. Det finnes for arbeidsbelastninger som virkelig trenger tilgang på vertsnivå, og en VPN-container er vanligvis ikke en av dem.

Koble hver feil til én forutsetning

Feilmeldingen forteller deg hvilken forutsetning som mangler hvis du leser den før du undertrykker den. En melding om en enhetsnode navngir enheten, en melding om en operasjon som ikke er tillatt navngir en evne, og en melding om en modul eller en sysctl navngir kjernestøtte. Hver av dem har en annen løsning, og bare én av dem er en evne.

En manglende konfigurasjonsfil forblir manglende etter at hver evne er gitt, og derfor endrer privilegert modus noen ganger ingenting i det hele tatt. Containeren starter, tunnelen feiler fortsatt, og den egentlige feilen handlet aldri om tillatelser. Kjernestøtte er det tredje tilfellet og det letteste å lese feil. En modul som ikke er lastet på verten, kan ikke lastes innenfra en uprivilegert container, og å gi flere evner inne i containeren endrer ikke vertens tilstand.

Kontroller kravet, ikke symptomet

Start med det minimale kallet som image-filen dokumenterer, kjør det, og ta vare på den nøyaktige feilteksten. Legg deretter til én innvilgelse om gangen og noter hvilket tillegg som endret 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 som ser enheten og har evnen, men likevel feiler, forteller deg at problemet er et annet sted. Det er et nyttig resultat, og privilegert modus ville ha skjult det.

Kontroller også enhetstillatelsene på verten, fordi en korrekt tildelt enhetsnode med feil gruppeeierskap gir samme feil som en manglende innvilgelse.

Skriv ned den snevrste innvilgelsen som virker

Skriv ned hver enhet og evne som utrullingen trenger, sammen med feilen som begrunnet den. Den oversikten er det som gjør at neste person kan fjerne noe trygt, og det er den en revisor vil be om når en container rapporteres som privilegert.

Gå også gjennom den omkringliggende konteksten, fordi vertsnettverk, vertsmonteringer og kjøretidsvalg hver kan utvide virkningen av en innvilgelse. Et isolert laboratoriekall som kombinerer dem alle, er ikke en produksjonskonfigurasjon, uansett hvor godt det virket. Test applikasjonen, dens DNS-atferd og en tunnelfeil før du kaller utrullingen ferdig. Tillatelse til å opprette et grensesnitt er ikke en utgangspolicy, og en container som kan tunnellere perfekt, ruter fortsatt alt applikasjonen sender.