Meshnet, Docker a oprávnění mezi nimi

Dvě URL mohou z prohlížeče uzlu vypadat stejně, ale pro firewall znamenají velmi odlišné věci. Jedna ukazuje na službu, která naslouchá přímo na hostiteli. Druhá ukazuje na adresu hostitele, jejíž port je publikován do sítě kontejneru, kde krok překladu předá spojení jiné IP. V síti typu peer-to-peer, která řídí přístup k místní síti oprávněním pro každý uzel, je tento rozdíl celou recenzí.

Oprávnění se týká koncového bodu hostitele, překlad se týká Dockeru a přihlášení se týká aplikace. Tři rozhodnutí, tři místa, kam se dívat.

Sledujte cíl po publikaci

Vezměte hostitele s Linuxem a Dockerem, který publikuje port 80 kontejneru na portu hostitele 8080. Uzel se připojí na síťovou adresu hostitele na 8080, hostitel spojení přijme a překlad cíle ho přepíše na mostovou adresu kontejneru, obvykle na něco jako 172.17.0.2 na portu 80.

Než pravidlo tento tok prozkoumá, zajímavým cílem je kontejner, ne hostitel. Zásada, která uvažuje jen o „službě na tomto stroji“, uvažuje o špatném objektu. Požadavek přistál na hostiteli, ale doručuje se jinam.

Proto dokumentace sítě uvádí kontejnery Dockeru mezi zdroji, které oprávnění místní sítě na Linuxu řídí. Oprávnění není synonymem běžné položky v seznamu povolených VPN a obě kontroly se navzájem nenahrazují. Jedna rozhoduje, zda uzel vůbec smí dosáhnout místních zdrojů; druhá rozhoduje, které cíle tunelovaná trasa nese.

Rozhodněte, kolik místního přístupu oprávnění dává

Udělení přístupu k místní síti uzlu není rozhodnutím o jednom kontejneru. Může odhalit další publikované služby na stejném hostiteli a může dosáhnout dál podle toho, jak hostitel předává. Před kliknutím na přepínač pro jeden panel zkontrolujte skutečný rozsah.

Pak se podívejte, kde Docker port publikuje. Publikace na 0.0.0.0 vytvoří naslouchající prvek na každé adrese hostitele, což může přidat běžnou položku LAN vedle síťové. Pokud je požadavkem jen síť, přivažte publikaci ke konkrétní adrese nebo rozhraní, které zamýšlíte, a širší vazbu berte jako samostatný nález, ne jako pohodlí.

Držte zásadu předávání hostitele a vlastní autentizaci aplikace dost úzké pro službu. URL, která vypadá soukromě, není řízení přístupu, a kontejner, který důvěřuje každému zdroji ve své mostové síti, není chráněn tím, že byl uzel schválen. Autentizace aplikace je třetí rozhodnutí a jediné, které ví, kdo je uživatel. Oprávnění na úrovni hostitele tuto znalost poskytnout nemůže.

Testujte oprávnění, ne jen URL

Ze schváleného uzlu otevřete přesnou službu a potvrďte, že funguje. Pak zkuste cíl, který má zůstat zakázaný, a potvrďte, že nefunguje. Testování jen šťastné cesty vám řekne, že oprávnění bylo uděleno; neřekne vám, že hranice je tam, kde si myslíte.

Samostatně porovnejte službu nativní pro hostitele. Pokud databáze naslouchá na hostiteli a panel běží v kontejneru, jdou různými cestami přes stejné oprávnění a zásada předávání hostitele je nemusí řídit stejně. Než napíšete poznámku k recenzi, poznamenejte si, co je co.

Nevyprazdňujte tabulky Dockeru ani pravidla klienta sítě, abyste přístup „resetovali“. Oba produkty instalují vlastní integraci zásad a její smazání vytvoří hostitele, který vypadá funkčně, ale obchází kontroly, které jste měli vyhodnotit. Pokud pravidlo vypadá špatně, přečtěte si ho a změňte právě to pravidlo. Pokud nedokážete vysvětlit, co pravidlo dělá, je to nález, ne důvod ho smazat.

Napište nález termíny samotného systému

Důležité je rozlišení, které produkt skutečně vynucuje, ne to v šabloně recenze: oprávnění dosáhnout koncového bodu hostitele, oprávnění dosáhnout směrovaných soukromých zdrojů a oprávnění používat aplikaci. Publikování portu nechává tato tři rozhodnutí přesně tam, kde byla, a recenzent, který je bere jako jedno, schválí špatný rozsah.

Uveďte adresu hostitele, publikovaný port, cíl kontejneru a oprávnění uzlu v jedné větě. Ta věta je ověřitelná někým jiným, a právě to z ní dělá nález, ne názor.