Bruggen Bouwen tussen On-Prem en Azure: van Private Endpoint tot StrongSwan
Wanneer bedrijven migreren naar de cloud, stuiten ze soms op technische uitdagingen. Een recent project bij Krane Labs is hiervan een perfect voorbeeld, waar we een verbinding tot stand probeerden te brengen tussen een Kubernetes-omgeving in Azure en een on-prem service.
De Azure-manier
Onlangs hadden we een project op Azure dat toegang nodig had tot een on-prem service vanuit hun Kubernetes omgeving, opgezet door Krane Labs. Onze aanpak? We verkenden eerst de integratie met Azure's “Network Gateway”, “Private Endpoint”, en “Private Link”.
Deze configuratie maakt een VPN verbinding binnen een Site-to-Site setup mogelijk. De Azure Network Gateway nam hier de zware last van de VPN-details op zich, terwijl het on-prem netwerk in een virtueel subnet werd geplaatst. Alles leek aanvankelijk soepel te verlopen, vooral gezien de gebruiksvriendelijke interface van Azure.
De tweede fase bracht ons bij de Private Endpoint/Link. Dit prachtige stukje technologie kan een service binnen een subnet beschikbaar stellen aan een ander subnet – zelfs overstijgend naar andere netwerken en tenants. Maar, zoals vaak het geval is met technologie, zit de duivel in de details. Om de private endpoint te laten werken, is een Azure load balancer nodig. Hoewel het logisch zou zijn om gewoon een IP-adres toe te wijzen als backend-target, is dit niet mogelijk. Je moet een VM als endpoint gebruiken, en deze VM moet deel uitmaken van een scale-set zonder gebonden publieke adressen.
Uiteindelijk, na wat puzzelen, hebben we een haproxy geïmplementeerd op deze VM, wat de brug vormde tussen de private endpoint/link en de on-prem service. Een ander detail waar we tegenaan liepen, waren de verschillende SKU's in Azure, wat de koppeling wat complexer maakte.
Een Andere Aanpak
Natuurlijk staan we open voor innovatie, en dus verkenden we een alternatieve methode: Kubernetes als spil van onze oplossing. Hier bouwden we een container met de Strongswan software en deployden deze als een pod, naast een haproxy-container. Alles werd netjes binnen Kubernetes gedefinieerd, en voila, we hadden een stateless oplossing.
Resultaat?
Deze container-gebaseerde oplossing bleek veel gestroomlijnder. Het was volledig ingebed in Kubernetes, gebruik makend van herbruikbare componenten. Bovendien was de kostenbesparing merkbaar; de twee kleine containers waren aanzienlijk goedkoper dan de Azure Virtual Gateway: we bespaarde de klant hierbij ongeveer 200 euro per maand.
Afsluitende Gedachten
Dit project was zeker leerzaam. Een belangrijke overweging is dat deze methode niet altijd haalbaar is, afhankelijk van specifieke behoeften en de VPN-oplossing in gebruik.
