Meshnet, Docker och behörigheten däremellan

Två URL:er kan se identiska ut i en peers webbläsare och ändå betyda helt olika saker för brandväggen. Den ena pekar på en tjänst som lyssnar på värden själv. Den andra pekar på en värdadress vars port är publicerad i ett containernätverk, där ett översättningssteg lämnar över anslutningen till en annan IP. I ett peer-till-peer-mesh som styr åtkomsten till det lokala nätverket med en behörighet per peer är den skillnaden hela granskningen.

Behörigheten handlar om värdens slutpunkt, översättningen handlar om Docker och inloggningen handlar om applikationen. Tre beslut, tre ställen att titta på.

Följ målet efter publiceringen

Ta en Linux Docker-värd som publicerar en containers port 80 på värdens port 8080. En peer ansluter till värdens mesh-adress på 8080, värden accepterar anslutningen och en målöversättning skriver om den mot containerns bro-adress, vanligtvis något som 172.17.0.2 på port 80.

När en regel granskar det flödet är det intressanta målet containern, inte värden. En policy som bara resonerar om ”en tjänst på den här maskinen” resonerar om fel objekt. Begäran landade på värden, men den levereras någon annanstans.

Därför listar mesh-dokumentationen Docker-containrar bland de resurser som behörigheten för lokalt nätverk styr på Linux. Behörigheten är inte en synonym för en vanlig post i en VPN-tillåtelselista, och de två kontrollerna ersätter inte varandra. Den ena avgör om en peer alls får nå lokala resurser; den andra avgör vilka mål en tunnlad rutt bär.

Avgör hur mycket lokal åtkomst en behörighet ger

Att ge en peer åtkomst till det lokala nätverket är inte ett beslut om en enda container. Det kan exponera andra publicerade tjänster på samma värd, och det kan nå längre beroende på hur värden vidarebefordrar. Granska den faktiska omfattningen innan du klickar på reglaget för en instrumentpanel.

Titta sedan var Docker publicerar porten. En publicering på 0.0.0.0 skapar en lyssnare på varje värdadress, vilket kan lägga till en vanlig LAN-post bredvid mesh-posten. Om kravet bara är mesh, bind publiceringen till den specifika adress eller det gränssnitt du avser, och behandla den bredare bindningen som ett eget fynd i stället för en bekvämlighet.

Håll värdens vidarebefordringspolicy och applikationens egen autentisering tillräckligt snäva för tjänsten. En URL som ser privat ut är inte åtkomstkontroll, och en container som litar på varje källa i sitt bronätverk skyddas inte av att mesh-peeren godkändes. Applikationens autentisering är det tredje beslutet, och det är det enda som vet vem användaren är. En behörighet på värdnivå kan inte ge den kunskapen.

Testa behörigheten, inte bara URL:en

Från den godkända peeren, öppna den exakta tjänsten och bekräfta att den fungerar. Prova sedan ett mål som ska förbli nekat och bekräfta att det inte fungerar. Att bara testa den lyckliga vägen säger att behörigheten gavs; det säger inte att gränsen är där du tror.

Jämför en värdnära tjänst separat. Om en databas lyssnar på värden och en instrumentpanel körs i en container följer de olika vägar genom samma behörighet och styrs kanske inte likadant av värdens vidarebefordringspolicy. Anteckna vad som är vad innan du skriver granskningsanteckningen.

Töm inte Dockers tabeller eller mesh-klientens regler för att ”återställa” åtkomst. Båda produkterna installerar sin egen policyintegrering, och att rensa den ger en värd som ser ut att fungera medan den kringgår de kontroller du ombads utvärdera. Om en regel ser fel ut, läs den och ändra just den regeln. Om du inte kan förklara vad en regel gör är det fyndet, inte en anledning att radera den.

Skriv fyndet i systemets egna termer

Det som spelar roll är den åtskillnad som produkten faktiskt upprätthåller, inte den i granskningsmallen: behörighet att nå en vändpunkt för värden, behörighet att nå routade privata resurser och behörighet att använda applikationen. Att publicera en port lämnar de tre besluten precis där de var, och en granskare som behandlar dem som ett kommer att godkänna fel omfattning.

Ange värdadressen, den publicerade porten, containerns mål och peer-behörigheten i samma mening. Den meningen kan testas av någon annan, och det är det som gör den till ett fynd i stället för en åsikt.