Waarom machine-identiteiten de sleutel zijn voor een veilige servicemesh?
Ondanks toenemende macro-economische tegenwind blijven digitale transformaties kansen bieden. Cloudmigraties maken namelijk productiviteitsverbeteringen mogelijk en vergroten de flexibiliteit. Kubernetes is een belangrijk onderdeel geworden van deze initiatieven, omdat de verantwoordelijke teams daarmee meerdere clusters in multi-clouds kunnen implementeren. Om echter te voorkomen dat de complexiteit toeneemt is het belangrijk alle machine-identiteiten goed en veilig te beheren.
Bij cloudmigraties komen ook servicenetwerken zoals Istio tot hun recht. Maar het realiseren van de mogelijke voordelen van zo’n architectuur is niet eenvoudig. Dat vereist een goede planning, deskundige begeleiding en het gebruik van cloud tooling voor het beheren van alle machine-identiteiten. Die zijn de sleutel voor het implementeren van een veilige servicemesh.
Introductie servicemesh
Het gebruik van Kubernetes is in 2022 verder toegenomen. Uit data van dit jaar blijkt dat een recordaantal van 96% van de onderzochte organisaties de technologie gebruikt of evalueert, tegen 83% in 2020 en 78% in 2019. Niet alleen het aantal organisaties dat een servicemesh gebruikt is toegenomen, ook de manier van toepassen is volwassen geworden. Naarmate men meer clusters over meerdere clouds implementeert, neemt ook de behoefte aan inzicht toe.
Servicemeshes worden steeds populairder, ze fungeren als een extra infrastructuurlaag voor Kubernetes-clusters en bieden verschillende functies voor netwerkconnectiviteit en security. Zoals wederzijdse TLS (mTLS), voor transparante service-to-service-encryptie met behulp van TLS-certificaten. Out-of-the-box zorgt dit ervoor dat alle communicatie tussen workloads met elkaar kan praten. Omdat al het netwerkverkeer door de servicemesh stroomt, is een diepere monitoring mogelijk, zoals traceerbaarheid van pod-to-pod-verzoeken en performance-inzicht. Gebruikers profiteren tevens van meer implementatieopties en aanpassing van het verkeer of onderbreken van circuits, voor situaties als pods niet kunnen communiceren.
Hoewel er meerdere servicemesh-leveranciers zijn, behoren Istio en Linkerd momenteel wel tot de bekendste. Ze fungeren als een transparant, taalonafhankelijk raamwerk en bieden alle servicemesh-voordelen van uniforme monitoring, verkeersbeheer en policy-gestuurde security. Voor deze taken zijn anders meerdere oplossingen nodig.
Bottlenecks Istio-implementatie
Behalve voordelen zijn er ook uitdagingen verbonden aan het implementeren van Istio en een servicemesh-architectuur. Dit kan organisaties afschrikken die niet de tijd, het geld en interne competenties hebben om dergelijke projecten te ondersteunen. Tot die uitdagingen behoren bijvoorbeeld de benodigde proxies (sidecars) voor alle communicatie tussen service-mesh componenten. Daar wordt namelijk het netwerkverkeer van de containers naartoe geleid.
Sidecars voegen latency toe en nemen CPU- en geheugencapaciteit in beslag, wat vanaf een bepaalde schaalgrootte teveel kan worden. Zelfs als elke sidecar maar 5 MB geheugen en 0,1 CPU in beslag neemt, levert dat vermenigvuldigd met 100.000 pods een enorme belasting op. Istio, met zijn gebruik van de open source Envoy-proxy als sidecar, is hier extra vatbaar voor.
Linkerd koos ervoor om zelf een lichtere, op Rust gebaseerde, proxy-sidecar te ontwikkelen en meer onderzoek te doen waardoor de latency-impact en hulpbronnengebruik daarbij lager zijn. Istio erkent de beperkingen van hun sidecar proxy-benadering en heeft als oplossing daarvoor de 'ambient mesh' aangekondigd. Deze biedt een op knooppunten gebaseerde proxy die een deel van de functionaliteit overneemt welke tot nu toe door Envoy wordt geleverd.
Er zijn al grote stappen gezet om het implementeren van Istio en servicemeshes verder te vereenvoudigen. Toch blijft het vooral in grote omgevingen complex om connectieproblemen op te lossen en de architectuur te configureren. Er zijn ook onbedoelde uitdagingen die worden veroorzaakt door mTLS. Hoewel het goed werkt met HTTP-verkeer, wordt mTLS problematischer bij TCP-verkeer, bijvoorbeeld als een pod met een database moet praten.
Aan de slag
In de praktijk brengt Kubernetes een enorm steile leercurve met zich mee. Voeg daar nog een servicemesh aan toe en de curve wordt alleen maar steiler. De eerste vereiste is een lijst met doelen op te stellen die de organisatie wil bereiken met het gebruik van een servicemesh en deze vervolgens te prioriteren. Bepaal waarvoor het gebruikt gaat worden: vooral mTLS en noord-zuid of oost-west gateways? Overweeg ook hoe het moet worden toegepast voor pods die moeten communiceren met externe services, zoals een database die zich niet in hetzelfde cluster bevindt. Hoe wordt het verkeer dan versleuteld? Welke routing policies gelden dan?
Het beheer van alle machine-identiteiten moet ook worden aangepakt. Elke besturing van een servicemesh heeft een component die zich bezighoudt met certificaatbeheer. Wanneer die besturing is geïnstalleerd, wordt voor elk cluster een basiscertificeringsinstantie (CA) gemaakt, die ondertekende certificaten genereert. Het beschikken over een zelfondertekende root-CA is geen goede gewoonte, zeker niet in sterk gereguleerde markten als financiële dienstverlening. Voor organisaties met meerdere servicemeshes (en zelfondertekende root-CA's) wordt dat probleem natuurlijk vermenigvuldigd. Organisaties moeten dan ook onthouden dat pods een relatief korte houdbaarheid hebben en dat elke pod zijn eigen certificaat nodig heeft.
Zelfondertekende certificaten bieden niet het inzicht en de controle die securityteams vereisen. Ze zijn niet ondertekend door een openbaar vertrouwde CA, kunnen niet worden ingetrokken en verlopen nooit. Dat zijn allemaal rode vlaggen voor de beveiliging. Teams die best practices voor beveiliging serieus nemen, kunnen beter op een cloud-agnostische, geautomatiseerde wijze het volledige proces van identiteitsuitgifte en levenscyclusbeheer gaan managen. Dat kan met een oplossing voor het inzichtelijk maken en configureren over meerdere clusters. Tools zoals cert-manager en Jetstack Secure helpen de beveiliging en het inzicht te bieden dat organisaties nodig hebben binnen hun servicemeshes, terwijl het compliancerisico wordt beperkt en ontwikkelaars tijd besparen.
Het beheren van machine-identiteiten is natuurlijk niet de enige bottleneck voor een effectieve servicemesh-implementatie, maar zeker een belangrijke stap. Met professionele begeleiding en een zorgvuldig geplande aanpak kunnen organisaties grote stappen zetten in hun digitale transformatieprojecten.
Steve Judd is Solutions Architect bij Venafi