Meshnet, Docker en de toestemming ertussen

Twee URL’s kunnen er in de browser van een peer identiek uitzien en toch heel verschillende dingen voor de firewall betekenen. De ene wijst naar een dienst die op de host zelf luistert. De andere wijst naar een hostadres waarvan de poort in een containernetwerk is gepubliceerd, waar een vertaalstap de verbinding aan een ander IP overdraagt. In een peer-to-peer-mesh dat de toegang tot het lokale netwerk met een toestemming per peer regelt, is dat verschil de hele beoordeling.

De toestemming gaat over het host-eindpunt, de vertaling gaat over Docker en de aanmelding gaat over de applicatie. Drie beslissingen, drie plekken om te kijken.

Volg de bestemming na publicatie

Neem een Linux-Docker-host die poort 80 van een container op hostpoort 8080 publiceert. Een peer verbindt met het mesh-adres van de host op 8080, de host accepteert de verbinding en een bestemmingsvertaling herschrijft die naar het bridge-adres van de container, meestal iets als 172.17.0.2 op poort 80.

Tegen de tijd dat een regel die stroom inspecteert, is de interessante bestemming de container, niet de host. Een beleid dat alleen redeneert over ‘een dienst op deze machine’, redeneert over het verkeerde object. Het verzoek landde op de host, maar het wordt elders afgeleverd.

Daarom noemt de mesh-documentatie Docker-containers onder de resources die de toestemming voor het lokale netwerk op Linux beheert. De toestemming is geen synoniem voor een gewone vermelding in een VPN-toelatingslijst, en de twee controles vervangen elkaar niet. De ene bepaalt of een peer überhaupt lokale resources mag bereiken; de andere bepaalt welke bestemmingen een getunnelde route draagt.

Bepaal hoeveel lokale toegang een toestemming geeft

Een peer toegang geven tot het lokale netwerk is geen beslissing over één container. Het kan andere gepubliceerde diensten op dezelfde host blootleggen, en het kan verder reiken afhankelijk van hoe de host doorstuurt. Beoordeel de effectieve scope voordat u de schakelaar voor één dashboard omzet.

Kijk dan waar Docker de poort publiceert. Een publicatie op 0.0.0.0 maakt een listener op elk hostadres, wat een gewone LAN-vermelding naast de mesh-vermelding kan toevoegen. Als de eis alleen mesh is, bind de publicatie dan aan het specifieke adres of de interface die u bedoelt, en behandel de bredere binding als een aparte bevinding en niet als een gemak.

Houd het doorstuurbeleid van de host en de authenticatie van de applicatie zelf smal genoeg voor de dienst. Een URL die privé lijkt is geen toegangsbeheer, en een container die elke bron op zijn bridgenetwerk vertrouwt, is niet beschermd door het feit dat de mesh-peer is goedgekeurd. De authenticatie van de applicatie is de derde beslissing, en die is de enige die weet wie de gebruiker is. Een toestemming op hostniveau kan die kennis niet leveren.

Test de toestemming, niet alleen de URL

Open vanaf de goedgekeurde peer de exacte dienst en bevestig dat die werkt. Probeer daarna een bestemming die geweigerd moet blijven en bevestig dat die niet werkt. Alleen het gelukkige pad testen vertelt u dat de toestemming is gegeven; het vertelt u niet dat de grens ligt waar u denkt.

Vergelijk een host-eigen dienst apart. Als een database op de host luistert en een dashboard in een container draait, volgen ze verschillende paden door dezelfde toestemming en worden ze mogelijk niet gelijk door het doorstuurbeleid van de host beheerd. Noteer wat wat is voordat u de beoordelingsnotitie schrijft.

Leeg niet de tabellen van Docker of de regels van de mesh-client om toegang te ‘resetten’. Beide producten installeren hun eigen beleidsintegratie, en die wissen levert een host op die lijkt te werken terwijl hij de controles omzeilt die u moest beoordelen. Als een regel verkeerd lijkt, lees hem en wijzig precies die regel. Als u niet kunt uitleggen wat een regel doet, is dat de bevinding, geen reden om hem te verwijderen.

Schrijf de bevinding in de termen van het systeem zelf

Wat telt is het onderscheid dat het product werkelijk afdwingt, niet dat in de beoordelingssjabloon: toestemming om een host-eindpunt te bereiken, toestemming om gerouteerde privéresources te bereiken en toestemming om de applicatie te gebruiken. Een poort publiceren laat die drie beslissingen precies waar ze waren, en een beoordelaar die ze als één behandelt, keurt de verkeerde scope goed.

Noem het hostadres, de gepubliceerde poort, de containerbestemming en de peertoestemming in dezelfde zin. Die zin is door iemand anders te testen, en dat maakt hem een bevinding in plaats van een mening.