Meshnet, Docker og tilladelsen imellem
En mesh-peer, der når en udgivet container, krydser en værtsrettighed og en Docker-oversættelse. Gennemgå de to hver for sig, ellers godkender du et forkert omfang.
To URL’er kan se ens ud fra en peers browser og betyde meget forskellige ting for firewallen. Den ene peger på en tjeneste, der lytter på værten selv. Den anden peger på en værtsadresse, hvis port er udgivet i et containernetværk, hvor et oversættelsestrin overlader forbindelsen til en anden IP. På et peer-to-peer-mesh, der styrer adgangen til det lokale netværk med en tilladelse per peer, er den forskel hele gennemgangen.
Tilladelsen handler om værtsendepunktet, oversættelsen handler om Docker, og login handler om applikationen. Tre beslutninger, tre steder at kigge.
Følg destinationen efter udgivelsen
Tag en Linux Docker-vært, der udgiver en containers port 80 på værtsport 8080. En peer opretter forbindelse til værten mesh-adresse på 8080, værten accepterer forbindelsen, og en destinationsoversættelse omskriver den mod containerens bro-adresse, typisk noget i retning af 172.17.0.2 på port 80.
Når en regel undersøger den strøm, er den interessante destination containeren, ikke værten. En politik, der kun ræsonnerer om »en tjeneste på denne maskine«, ræsonnerer om det forkerte objekt. Anmodningen landede på værten, men den leveres et andet sted.
Derfor opfører mesh-dokumentationen Docker-containere blandt de ressourcer, som tilladelsen til det lokale netværk styrer på Linux. Tilladelsen er ikke et synonym for en almindelig post på VPN-tilladelseslisten, og de to kontroller erstatter ikke hinanden. Den ene afgør, om en peer overhovedet må nå lokale ressourcer; den anden afgør, hvilke destinationer en tunelleret rute bærer.
Afgør, hvor meget lokal adgang en tilladelse giver
At give en peer adgang til det lokale netværk er ikke en beslutning om en enkelt container. Det kan blotlægge andre udgivne tjenester på samme vært, og det kan nå længere afhængigt af, hvordan værten videresender. Gennemgå det effektive omfang, før du klikker på kontakten for et enkelt dashboard.
Se derefter, hvor Docker udgiver porten. En udgivelse på 0.0.0.0 opretter en lytter på hver værtsadresse, hvilket kan tilføje en almindelig LAN-post ved siden af mesh-posten. Hvis kravet kun er mesh, bind udgivelsen til den bestemte adresse eller det interface, du sigter efter, og behandl den bredere binding som en særskilt konstatering i stedet for en bekvemmelighed.
Hold værtens videresendelsespolitik og applikationens egen godkendelse snæver nok til tjenesten. En URL, der ser privat ud, er ikke adgangskontrol, og en container, der stoler på enhver kilde på sit bronetværk, er ikke beskyttet af, at mesh-peeren er godkendt. Applikationens godkendelse er den tredje beslutning, og den er den eneste, der ved, hvem brugeren er. En tilladelse på værtsniveau kan ikke levere den viden.
Test tilladelsen, ikke kun URL’en
Fra den godkendte peer åbner du den præcise tjeneste og bekræfter, at den virker. Prøv derefter en destination, der bør forblive afvist, og bekræft, at den ikke virker. At teste kun den glade vej fortæller dig, at tilladelsen blev givet; det fortæller dig ikke, at grænsen er, hvor du tror.
Sammenlign en værtsnative tjeneste separat. Hvis en database lytter på værten, og et dashboard kører i en container, følger de forskellige veje gennem den samme tilladelse og styres muligvis ikke ens af værtens videresendelsespolitik. Notér, hvad der er hvad, før du skriver gennemgangsnoten.
Skyl ikke Dockers tabeller eller mesh-klientens regler for at »nulstille« adgang. Begge produkter installerer deres egen politikintegration, og at rydde den giver en vært, der ser ud til at virke, mens den omgår de kontroller, du blev bedt om at vurdere. Hvis en regel ser forkert ud, så læs den og ændr netop den regel. Hvis du ikke kan forklare, hvad en regel gør, er det konstateringen, ikke en grund til at slette den.
Skriv konstateringen i systemets egne termer
Det, der betyder noget, er den sondring, produktet faktisk håndhæver, ikke den i gennemgangsskabelonen: tilladelse til at nå et værtsendepunkt, tilladelse til at nå routed private ressourcer og tilladelse til at bruge applikationen. At udgive en port efterlader de tre beslutninger præcis, hvor de var, og en gennemgåer, der behandler dem som én, vil godkende det forkerte omfang.
Angiv værtsadressen, den udgivne port, containerens destination og peer-tilladelsen i samme sætning. Den sætning kan testes af en anden, og det er, hvad der gør den til en konstatering i stedet for en mening.