Prečo je privilegovaný režim širší, než VPN potrebuje

Kontajner nechcel otvoriť svoj tunel, preto sa pridala privilegovaná vlajka a teraz to funguje. Táto postupnosť preukázala len to, že chýbalo aspoň jedno oprávnenie, a nič nehovorí o tom, ktoré. Privilegovaný režim udeľuje sadu schopností a prístup k zariadeniam oveľa širší, než tunelové rozhranie potrebuje.

Čo vlajka skutočne mení

Privilegovaný kontajner dostáva široké schopnosti a prístup k zariadeniam hostiteľa, čo je oveľa väčšie udelenie, než vyžaduje sieťová cesta. Presnú sadu dokumentuje runtime prostredie, a nie ju určuje tradícia, a dokumentácia Dockeru o spúšťaní kontajnerov opisuje dostupné možnosti privilegií. Jedno prečítanie stačí na to, aby ste videli, že tunelovanie je malá časť celku.

Dve užšie požiadavky pokrývajú väčšinu kontajnerov VPN. Konfigurácia rozhrania vyžaduje schopnosť správy siete a otvorenie tunelového zariadenia vyžaduje prístup k presne tomu uzlu zariadenia. Sú to oddelené udelenia a aj obe spolu sú užšie než plošná možnosť. Zvyšok privilegovanej sady nemá s tunelom nič spoločné. Existuje pre úlohy, ktoré skutočne potrebujú prístup na úrovni hostiteľa, a kontajner VPN medzi ne zvyčajne nepatrí.

Priraďte každú chybu k jednému predpokladu

Chybová správa vám povie, ktorý predpoklad chýba, ak ju prečítate skôr, než ju potlačíte. Správa o uzle zariadenia pomenúva zariadenie, správa o nepovolenej operácii pomenúva schopnosť a správa o module alebo sysctl pomenúva podporu jadra. Každá z nich má inú opravu a len jedna z nich je schopnosť.

Chýbajúci konfiguračný súbor zostane chýbajúci po udelení všetkých schopností, a preto privilegovaný režim niekedy nezmení vôbec nič. Kontajner sa spustí, tunel stále zlyháva a skutočná chyba nikdy nebola o oprávneniach. Podpora jadra je tretí prípad a najľahšie sa prečíta nesprávne. Modul, ktorý nie je načítaný na hostiteľovi, nie je možné načítať zvnútra neprivilegovaného kontajnera a udelenie ďalších schopností vnútri kontajnera nemení stav hostiteľa.

Kontrolujte požiadavku, nie príznak

Začnite s minimálnym volaním, ktoré obraz dokumentuje, spustite ho a uchovajte presný text zlyhania. Potom pridávajte jedno oprávnenie po druhom a poznamenajte si, ktorý prírastok zmenil výsledok.

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

Kontajner, ktorý zariadenie vidí a schopnosť má, ale napriek tomu zlyháva, vám hovorí, že problém je inde. To je užitočný výsledok a privilegovaný režim by ho skryl.

Skontrolujte aj oprávnenia zariadenia na hostiteľovi, pretože správne udelený uzol zariadenia s nesprávnym vlastníctvom skupiny dáva rovnakú chybu ako chýbajúce udelenie.

Zapíšte najužšie fungujúce oprávnenie

Zapíšte každé zariadenie a schopnosť, ktoré nasadenie potrebuje, spolu s chybou, ktorá ich ospravedlnila. Práve tento záznam umožní ďalšiemu človeku niečo bezpečne odobrať, a práve ten bude audítor žiadať, keď bude kontajner nahlásený ako privilegovaný.

Prezrite si aj okolitý kontext, pretože sieť hostiteľa, pripojenia hostiteľa a možnosti runtime prostredia môžu každé rozšíriť dopad udelenia. Izolované laboratórne volanie, ktoré ich všetky kombinuje, nie je produkčná konfigurácia, nech fungovalo akokoľvek dobre. Otestujte aplikáciu, jej správanie v DNS a zlyhanie tunela, skôr než nasadenie vyhlásite za dokončené. Oprávnenie vytvoriť rozhranie nie je výstupnou politikou a kontajner, ktorý dokáže dokonale tunelovať, stále smeruje všetko, čo aplikácia odošle.