Proč je privilegovaný režim širší, než VPN potřebuje

Kontejner nechtěl otevřít svůj tunel, tak se přidal privilegovaný příznak a teď to funguje. Tato posloupnost prokázala jen to, že chybělo alespoň jedno oprávnění, a nic neříká o tom které. Privilegovaný režim uděluje sadu schopností a přístup k zařízením mnohem širší, než tunelové rozhraní potřebuje.

Co příznak skutečně mění

Privilegovaný kontejner dostává široké schopnosti a přístup k zařízením hostitele, což je mnohem větší oprávnění, než vyžaduje síťová cesta. Přesnou sadu dokumentuje běhové prostředí, nikoli tradované zvyklosti, a dokumentace Dockeru ke spouštění kontejnerů popisuje dostupné volby privilegií. Jedno přečtení stačí k tomu, abyste viděli, že tunelování je malá část celku.

Dva užší požadavky pokrývají většinu kontejnerů VPN. Konfigurace rozhraní potřebuje schopnost správy sítě a otevření tunelového zařízení potřebuje přístup k tomu konkrétnímu uzlu zařízení. To jsou oddělená oprávnění a i obě dohromady jsou užší než plošná volba. Zbytek privilegované sady nemá s tunelem nic společného. Existuje pro úlohy, které skutečně potřebují přístup na úrovni hostitele, a kontejner VPN mezi ně obvykle nepatří.

Přiřaďte každou chybu k jednomu předpokladu

Chybová zpráva vám řekne, který předpoklad chybí, pokud ji přečtete dřív, než ji potlačíte. Zpráva o uzlu zařízení pojmenuje zařízení, zpráva o nepovolené operaci pojmenuje schopnost a zpráva o modulu nebo sysctl pojmenuje podporu jádra. Každá z nich má jinou opravu a jen jedna z nich je schopnost.

Chybějící konfigurační soubor zůstane chybějící po udělení všech schopností, a proto privilegovaný režim někdy nezmění vůbec nic. Kontejner se spustí, tunel stále selhává a skutečná chyba nikdy nebyla o oprávněních. Podpora jádra je třetí případ a nejsnáze se přečte špatně. Modul, který není na hostiteli načten, nelze načíst z neprivilegovaného kontejneru a udělení dalších schopností uvnitř kontejneru nemění stav hostitele.

Kontrolujte požadavek, ne symptom

Začněte u minimálního volání, které obraz dokumentuje, spusťte ho a uchovejte přesný text selhání. Potom přidávejte jedno oprávnění po druhém a poznamenejte si, který přírůstek změnil výsledek.

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

Kontejner, který zařízení vidí a schopnost má, ale přesto selhává, vám říká, že problém je jinde. To je užitečný výsledek a privilegovaný režim by ho skryl.

Zkontrolujte také oprávnění zařízení na hostiteli, protože správně udělený uzel zařízení se špatným vlastníkem skupiny dává stejnou chybu jako chybějící oprávnění.

Zapište nejužší oprávnění, které funguje

Zapište každé zařízení a schopnost, které nasazení potřebuje, spolu s chybou, která je ospravedlnila. Právě tento záznam umožní dalšímu člověku něco bezpečně odebrat a právě ten bude auditor chtít, když bude kontejner nahlášen jako privilegovaný.

Projděte si i okolní souvislosti, protože síť hostitele, připojení hostitele a volby běhového prostředí mohou každé rozšířit dopad uděleného oprávnění. Izolované laboratorní volání, které je všechny kombinuje, není produkční konfigurace, ať fungovalo jakkoli dobře. Otestujte aplikaci, její chování v DNS a selhání tunelu, než nasazení prohlásíte za hotové. Oprávnění vytvořit rozhraní není výstupní politikou a kontejner, který umí dokonale tunelovat, stále směruje vše, co aplikace odešle.