Kvifor privilegert modus er breiare enn ein VPN treng

Containeren ville ikkje opna tunnelen sin, så det privilegerte flagget vart lagt inn, og no verkar det. Den sekvensen slo berre fast at minst éi løyve mangla, og han seier ingenting om kva. Privilegert modus gjev eit sett med evner og einingstilgang som er langt breiare enn eit tunellgrensesnitt treng.

Kva flagget faktisk endrar

Ein privilegert container får breie evner og tilgang til einingane til verten, noko som er ei mykje større innvilging enn nettverksvegen krev. Det nøyaktige settet vert dokumentert av køyretidsmiljøet og ikkje fastsett av overlevering, og Docker-dokumentasjonen om å køyra containere skildrar dei tilgjengelege privilegiealternativa. Éin gjennomlesing er nok til å sjå at tunnelen er ein liten del av heilskapen.

To snevrare krav dekkjer dei fleste VPN-containerane. Å konfigurera eit grensesnitt krev evna til nettverksadministrasjon, og å opna tunelleininga krev tilgang til nettopp den eininga noden. Dette er separate innvilgingar, og sjølv begge saman er snevrare enn det generelle alternativet. Resten av det privilegerte settet har ingenting med tunnelen å gjera. Det finst for arbeidslastar som verkeleg treng tilgang på vertsnivå, og ein VPN-container er vanlegvis ikkje ein av dei.

Kople kvar feil til éin føresetnad

Feilmeldinga fortel deg kva føresetnad som manglar viss du les ho før du undertrykkjer ho. Ei melding om ein eining node nemner eininga, ei melding om ein operasjon som ikkje er tillaten nemner ei evne, og ei melding om ein modul eller ein sysctl nemner kjernestøtte. Kvar av dei har ei anna løysing, og berre éi av dei er ei evne.

Ei manglande konfigurasjonsfil vert verande manglande etter at kvar evne er gjeven, og difor endrar privilegert modus stundom ingenting i det heile. Containeren startar, tunnelen feilar framleis, og den eigentlege feilen handla aldri om løyve. Kjernestøtte er det tredje tilfellet og det lettaste å lesa feil. Ein modul som ikkje er lasta på verten, kan ikkje lastast innanfrå ein uprivilegert container, og å gje fleire evner inne i containeren endrar ikkje tilstanden til verten.

Kontroller kravet, ikkje symptomet

Start med det minimale kallet som image-fila dokumenterer, køyr det, og ta vare på den nøyaktige feilteksten. Legg deretter til éi innvilging om gongen og noter kva tillegg som endra 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

Ein container som ser eininga og har evna, men likevel feilar, fortel deg at problemet er ein annan stad. Det er eit nyttig resultat, og privilegert modus ville ha skjult det.

Kontroller òg einingstilgangane på verten, fordi ein korrekt tildelt eining node med feil gruppeeige gjev same feil som ei manglande innvilging.

Skriv ned den snevraste innvilginga som verkar

Skriv ned kvar eining og kvar evne som utrullinga treng, saman med feilen som grunngav ho. Den oversikta er det som gjer at neste person kan fjerna noko trygt, og det er den ein revisor vil be om når ein container vert rapportert som privilegert.

Gå òg gjennom den omkringliggjande konteksten, fordi vertsnettverk, vertsmonteringar og køyretidsval kvar kan utvida verknaden av ei innvilging. Eit isolert laboratoriekall som kombinerer dei alle, er ikkje ein produksjonskonfigurasjon, uansett kor godt det verka. Test applikasjonen, DNS-åtferda hans og ein tunellfeil før du kallar utrullinga ferdig. Løyve til å oppretta eit grensesnitt er ikkje ein utgangspolicy, og ein container som kan tunnellera perfekt, rutar framleis alt applikasjonen sender.