Varför privilegierat läge är bredare än en VPN behöver

Containern ville inte öppna sin tunnel, så den privilegierade flaggan lades in, och nu fungerar det. Den sekvensen fastställde bara att minst ett behörighetstillstånd saknades, och den säger ingenting om vilket. Privilegierat läge ger en uppsättning förmågor och enhetsåtkomst som är långt bredare än en tunnelgränssnitt behöver.

Vad flaggan faktiskt ändrar

En privilegierad container får breda förmågor och åtkomst till värdens enheter, vilket är ett mycket större medgivande än nätverksvägen kräver. Den exakta uppsättningen dokumenteras av körmiljön och fastställs inte av muntlig tradition, och Docker-dokumentationen om att köra containrar beskriver de tillgängliga privilegiealternativen. En genomläsning räcker för att se att tunneln är en liten del av helheten.

Två snävare krav täcker de flesta VPN-containrar. Att konfigurera ett gränssnitt kräver förmågan till nätverksadministration, och att öppna tunnelenheten kräver åtkomst till just den enhetsnoden. Det är separata medgivanden, och även båda tillsammans är snävare än det allmänna alternativet. Resten av den privilegierade uppsättningen har ingenting med tunneln att göra. Den finns för arbetsbelastningar som verkligen behöver åtkomst på värdnivå, och en VPN-container är vanligtvis inte en av dem.

Koppla varje fel till ett förkrav

Felmeddelandet berättar vilket förkrav som saknas om du läser det innan du tystar det. Ett meddelande om en enhetsnod namnger enheten, ett meddelande om en otillåten åtgärd namnger en förmåga, och ett meddelande om en modul eller en sysctl namnger kärnstöd. Var och en av dem har en annan åtgärd, och bara en av dem är en förmåga.

En saknad konfigurationsfil förblir saknad efter att varje förmåga beviljats, och därför ändrar privilegierat läge ibland ingenting alls. Containern startar, tunneln misslyckas fortfarande, och det verkliga felet handlade aldrig om behörigheter. Kärnstöd är det tredje fallet och det som är lättast att läsa fel. En modul som inte är laddad på värden kan inte laddas inifrån en icke-privilegierad container, och att ge fler förmågor inuti containern ändrar inte värdens tillstånd.

Kontrollera kravet, inte symptomet

Börja med det minimala anrop som avbilden dokumenterar, kör det och spara den exakta feltexten. Lägg sedan till ett medgivande i taget och notera vilket tillägg som ändrade 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 och har förmågan men ändå misslyckas berättar att problemet ligger någon annanstans. Det är ett användbart resultat, och privilegierat läge skulle ha dolt det.

Kontrollera också enhetsbehörigheterna på värden, eftersom en korrekt beviljad enhetsnod med fel gruppägande ger samma fel som ett saknat medgivande.

Skriv ned det snävaste medgivande som fungerar

Skriv ned varje enhet och förmåga som driftsättningen behöver, tillsammans med felet som motiverade den. Den förteckningen är det som gör att nästa person kan ta bort något säkert, och det är den en granskare kommer att begära när en container rapporteras som privilegierad.

Gå också igenom den omgivande kontexten, eftersom värdnätverk, värdmonteringar och körmiljöalternativ var och en kan vidga effekten av ett medgivande. Ett isolerat laboratorieanrop som kombinerar dem alla är inte en produktionskonfiguration, hur bra det än fungerade. Testa applikationen, dess DNS-beteende och ett tunnelfel innan du kallar driftsättningen klar. Tillstånd att skapa ett gränssnitt är inte en utgångspolicy, och en container som kan tunnla perfekt routar fortfarande allt applikationen skickar.