Pod, node of cluster: wat een VPN-sidecar echt omleidt

Een VPN-sidecar in een Kubernetes-Pod lijkt op een VPN op hostniveau met betere manieren, en de gelijkenis stopt bij de grens van de namespace. Containers in één Pod delen de netwerknamespace, inclusief de adres- en poortruimte, dus een sidecar die routes en beleid installeert, verandert werkelijk waar de pakketten van de applicatie heen gaan. Hij verandert niets voor de andere Pods op de node, en raakt de eigen stack van de node niet aan tenzij je hem zo configureert. Die grens goed begrijpen bepaalt zowel wat je kunt uitrollen als wat je moet testen. De secties hieronder volgen het van de namespace naar buiten.

Gedeelde namespace, gedeelde gevolgen

Twee containers in een Pod praten via loopback en zien dezelfde interfaces, en daarom werkt het sidecar-patroon überhaupt: de applicatie hoeft niet te weten dat er een tunnel bestaat, omdat de route die zij oplost is geïnstalleerd in de namespace die zij gebruikt. Dezelfde eigenschap betekent dat de fouten van de sidecar de fouten van de applicatie zijn. Een route die te veel vangt, of een DNS-wijziging die naar een resolver in de tunnel wijst, geldt onmiddellijk voor elk proces in die Pod. In een gedeelde namespace is er geen routing per container, dus een sidecar kan niet tot één proces worden beperkt.

Dit is het mechanisme om bij de beoordeling in gedachten te houden: de impactradius is de Pod, niet de node en niet het cluster.

Wat de sidecar niet bereikt

Andere Pods houden hun eigen namespaces en hun eigen routing, dus een workload die dezelfde uitgang nodig heeft, heeft dezelfde sidecar nodig of in plaats daarvan een ontwerp op nodeniveau. Ook het verkeer van de node valt buiten de namespace van de Pod, en Pods met hostnetwerk kiezen er bewust voor om deze isolatie volledig te laten varen. Als je de sidecar met hostnetwerk draait om iets handigs te bereiken, heb je de reikwijdte van één Pod naar de hele node uitgebreid en dat zou je hardop moeten zeggen.

Verkeer naar de services van het cluster is de andere veelvoorkomende verrassing. Een brede standaardroute in de Pod kan verzoeken onderscheppen die voor de API-server of een ClusterIP-service bedoeld zijn, en die falen dan op manieren die lijken op een kapotte tunnel.

Routeplan: Pod-, service-, node- en VPN-bereiken

Schrijf de vier bereiken op en controleer ze op overlap voordat je iets uitrolt: Pod-CIDR, service-CIDR, nodeadressen en de bestemmingen achter de VPN. Overlap tussen de privébereiken van de VPN en de eigen ruimte van het cluster is niet zeldzaam, en een standaardroute is daar de verkeerde oplossing voor. Het routeplan hoort in dezelfde repository als het manifest, want het volgende cluster kan heel andere Pod- en servicebereiken uitdelen.

DNS is onderdeel van het plan en geen aparte zorg. Een sidecar die de resolver-configuratie herschrijft, kan service discovery in het cluster breken terwijl externe opzoekingen perfect werken.

Starten en falen zijn expliciete toestanden

Een draaiend sidecar-proces is geen egress-beleid. Bepaal welk verkeer mag stromen voordat de tunnel klaar is en wat er gebeurt als hij daarna sterft, en implementeer die beslissing dan: een probe die de applicatiecontainer gate't, een netwerkbeleid dat standaard weigert, of beide. Zonder een van beide start de applicatie, lost op en stuurt verkeer buiten het normale pad van de node terwijl de tunnel nog verbinding maakt.

Dat gat is kort in een gezond cluster en permanent in een kapot cluster, en dat is precies de eigenschap die een aanvaller of een toevallige datalek prefereert.

Koppel de volgorde aan een faaltest. Dood de sidecar en bevestig dat de applicatie haar bedoelde uitgang verliest in plaats van stil terug te vallen.

Capabilities, beleid en tests vanuit de app-container

De capabilities toekennen die nodig zijn om interfaces te maken en routes te wijzigen is een privilegebeslissing, en een privilege dat past bij een geïsoleerde Pod is niet automatisch passend op de stack van de node. Gebruik de netwerk- en beveiligingsbeleidsmechanismen die het cluster ondersteunt, en ga er niet van uit dat elke CNI- of beleidsimplementatie een VPN-interface hetzelfde behandelt; de verschillen komen juist naar voren in de faalgevallen die je aangaan.

Test vanuit de echte applicatiecontainer, met nieuwe verzoeken naar een privébestemming, een clusterservice en het openbare internet. Een test vanuit de sidecar bewijst dat de tunnel werkt, niet dat de applicatie bereikt wat zij nodig heeft.

Documenteer de netwerkaannames van het cluster naast de VPN-configuratie. De workload naar een ander cluster verplaatsen is dan een oefening in het controleren van het routeplan in plaats van een imagewijziging die stil ophoudt te werken.