Waarom bedrijven niet zomaar op Istio's mTLS moeten vertrouwen

Containers zijn de basis voor moderne ontwikkelomgevingen. Ze bieden bedrijven een compactere en overdraagbare architectuur dan virtuele machines (VM's), ze abstraheren het besturingssysteem en leveren software met alles wat nodig is om in elke omgeving te draaien. Dus minder overhead, meer consistentie en een flexibelere toepasbaarheid, waardoor ze populair zijn bij DevOps-teams. Uit onderzoek van CNCF blijkt dat het gebruik ervan jaarlijks fors groeit.

De hausse in het gebruik van containers heeft ook geleid tot de behoefte aan een orkestratieplatform om deze omgevingen te beheren. Kubernetes is inmiddels de marktstandaard geworden die ervoor zorgt dat containers volgens de beoogde specificaties werken en schaalbaar zijn. Het wordt nu zelfs beschreven als 's werelds grootste orkestratieplatform voor gecontaineriseerde workloads. Door gecontaineriseerde omgevingen te automatiseren, maakt Kubernetes een dynamische, multi-cloud, open source omgeving mogelijk die zowel schaalbaar, kostenefficiënt als productief is, oftewel een paradijs voor ontwikkelaars. Naarmate Kubernetes volwassener werd, is er echter ook een groeiende behoefte ontstaan aan meer controle en governance.

Istio is de favoriete tool geworden voor het bieden van uniforme observatie, operationele flexibiliteit en beleidsgestuurde beveiliging in cloud-native Kubernetes-omgevingen. Istio is een open source tool die sinds kort door de CNCF wordt beheerd. Nu Kubernetes volwassen is en bedrijven meer clusters inzetten, biedt Istio de benodigde abstractielaag om de IT-governance te managen. Het inzetten van een Istio-servicemesh is in de praktijk echter niet eenvoudig. Om de integriteit van deze omgevingen te waarborgen, moet het verkeer tussen de containers uiteraard veilig zijn. Dit vereist een sterk identiteitssysteem om de integriteit van Kubernetes-omgevingen te waarborgen. Anders introduceert Istio nieuwe risico's die tot ongewenste gevolgen kunnen leiden binnen volledig geautomatiseerde omgevingen.

Waarom een Istio service mesh nodig?
Istio is voor veel organisaties een populaire oplossing geworden om grip te krijgen en te houden op hun steeds complexere Kubernetes-omgevingen. Het werkt als een open-source ‘mesh’, die het mogelijk maakt om op een transparante en eenduidige manier alle services in cloudgebaseerde applicaties met elkaar te verbinden, te beveiligen en te monitoren. Sinds eind september 2022 wordt deze tool net als Kubernetes door de CNCF beheerd.

Istio is ontworpen om het leven van ontwikkelaars en beheerders gemakkelijker te maken, door een taak uit te voeren waarvoor anders meerdere afzonderlijke oplossingen nodig zijn. De servicetool beheert welk verkeer van en naar specifieke workloads gaat, binnen clusters en tussen clusters. Met als voordeel een eenvoudigere configuratie van de eigenschappen op serviceniveau, zoals circuitonderbrekers, time-outs en retries. Ook bevat het out-of-the-box telemetrie om inkomende en uitgaande verzoeken van en naar elke Kubernetes-pod te beheren.

Met Istio hoeven ontwikkelteams hun product nog maar één keer te installeren om het voor elke container, workload en applicatie te gebruiken, in plaats van nieuwe installaties voor verschillende toepassingen. Ondanks de voordelen is het implementeren van Istio echter geen gemakkelijke taak. Het vereist voldoende kennis en vaardigheden om de tool te implementeren en te beheren. Daarom wordt deze oplossing vooral toegepast door grote ondernemingen in sterk gereguleerde markten, die over de benodigde middelen en strenge handhavingseisen beschikken om het te rechtvaardigen.

Machinecommunicatie beveiligen met Mutual TLS
In de vroeger begrensde IT-wereld waren veel securityteams gefocused op het beveiligen van zogeheten noord-zuidverkeer, dat de organisatie in en uit ging. Gebaseerd op de aanname dat alle interne communicatie een hoger vertrouwensniveau heeft. De praktijk heeft echter herhaaldelijk aangetoond dat dit niet altijd het geval is. Met telkens veranderende grenzen om te verdedigen, is de aandacht verlegd naar het onderzoeken van het interne, oost-west verkeer. Vooral organisaties die actief zijn in sterk gereguleerde markten kunnen dit verplicht stellen.

Cruciaal is dat Istio dit beleid ondersteunt door machine-naar-machine-communicatie tussen sde ervices in verschillende Kubernetes-clusters te beveiligen. Dat gebeurt met Mutual TLS ( mTLS ), de transparante, service-to-service bidirectionele codering, gebaseerd op openbare sleutelcertificaten. Deze certificaten fungeren dus als machine-identiteiten en bieden wederzijdse authenticatie als de twee partijen die verbinding maken zijn wat ze zeggen dat ze zijn, om veilig met elkaar te kunnen communiceren.

Op het eerste gezicht is dit een geweldige oplossing voor bedrijven die machine-identiteiten in de cloud beheren, omdat Istio automatisch een unieke identiteit genereert voor elke container, cluster en microservice. Dit heeft uiteraard de aandacht van veel ontwikkelaars getrokken, omdat het hen verlost van het benodigde machine-identiteitsbeheer. Wie dieper graaft ontdekt echter dat er ook grote zorgen zijn.

Uitdaging van zelfondertekende machine-identiteiten
Machine-identiteiten als authenticatiesysteem vereisen een beheeroplossing om effectief te zijn. Istio ondersteunt echter alleen out-of-the-box zelfondertekende machine-identiteiten. Dit type machine-identiteiten kan ontwikkelaars tijd en geld besparen, maar stelt organisaties ook bloot aan risico's. Dat komt door een verminderde controle en zichtbaarheid, beide belangrijke vereisten van securityteams, omdat zelfondertekende machine-identiteiten buiten de bestaande beheeroplossing voor machine-identiteiten van bedrijven vallen.

Zelfondertekende certificaten worden niet ondertekend door een onafhankelijke en vertrouwde certificeringsinstantie (CA). Ook kunnen ze niet worden ingetrokken en vervallen ze nooit. Dat klinkt als een voordeel, maar als de privésleutel wordt gestolen, kan de beperking om in te trekken de deur openzetten voor kwaadwillenden. Met Istio's machine-identiteitsbeheer hebben securityteams ook geen idee welke identiteiten er allemaal worden uitgegeven, of ze zijn uitgegeven door een vertrouwde certificeringsinstantie (CA), de context waarbinnen de identiteit is uitgegeven, of welke identiteit wordt gebruikt op welk cluster? Dat zijn natuurlijk cruciale aspecten voor het beveiligen van cloud-native omgevingen.

Genoemde risico's nemen toe door de wijze waarop organisaties Kubernetes-omgevingen beheren. Ontwikkelteams evolueren steeds vaker van het implementeren van grote clusters naar meerdere kleinere clusters, vaak gerelateerd aan een enkele app, team of bedrijfsregio. De uitdaging bij deze flexibelere aanpak is dat het nog meer complexiteit creëert en dus meer certificaten om te beheren, omdat alle clusters veilig met elkaar moeten praten. Het is daarom ook niet verwonderlijk dat 94% van de respondenten van een Red Hat-enquête vorig jaar toegaf in de afgelopen twaalf maanden een Kubernetes-beveiligingsincident te hebben meegemaakt.

Snelheid versus security
Om de securityrisico's te beperken, zijn veel zakelijke gebruikers van Istio begonnen met het uitgeven van eigen certificaten, gebaseerd op een bewezen betrouwbare CA's en infrastructuur. Vanwege de grote hoeveelheid en het feit dat de levenscycli van machine-identiteiten in deze omgevingen slechts een uur kunnen duren, kan dit echter een kostbaar, tijdrovend en moeilijk te beheren proces zijn.

Het handmatig bijhouden van alle identiteiten is een onmogelijke taak. Daarom is het onvermijdelijk dat ze verlopen zonder te worden verlengd. Ontwikkelaars die hun werk willen verlichten, kunnen identiteiten uitgeven met een langere levensduur om te voorkomen dat er continu nieuwe nodig zijn. Dat resulteert echter in meer problemen verderop, aangezien korter geldige identiteiten doorgaans als veiliger worden beschouwd. Sommige ontwikkelaars gebruiken ook wildcard-certificaten, waarbij hetzelfde certificaat wordt gebruikt voor meerdere domeinen en clusters. Dit kan de flexibiliteit vergroten en de kosten verlagen, maar ook een single point of failure creëren als een enkel certificaat wordt gecompromitteerd. Het vereist ook extra inspanning bij het volgen van de verlengingen.

De hiervoor beschreven praktijken kunnen ertoe leiden dat ontwikkelaars worden belemmerd in het toevoegen van nieuwe workloads en services aan applicaties, waardoor innovatie wordt vertraagd. Ze kunnen tevens leiden tot het niet meer voldoen aan interne beleidsregels en externe wettelijke eisen, waardoor ontwikkelaars de bijbehorende services helemaal niet in productie mogen nemen.

In het ergste geval kunnen onvoldoende beheerde machine-identiteiten leiden tot storingen, omdat een vervaldatum over het hoofd wordt gezien. Als gevolg daarvan kunnen hele applicaties en services ineens niet meer beschikbaar zijn. Deze risico’s leiden tot spanningen tussen ontwikkel- en securityteams, die constant worstelen om snelheid en security in evenwicht te brengen met de behoefte aan controle en snelle innovatie.

Machine-identiteiten veiliger beheren
Gartner verwacht dat tegen 2025 zo’n 85% van alle organisaties in de wereld gecontaineriseerde workloads gebruikt. Istio wordt daarom een steeds populairdere keuze. Tegelijkertijd brengt de mTLS-functionaliteit echter onbedoeld extra beheer- en securityuitdagingen met zich mee. Organisaties die deze tool gebruiken, hebben een effectievere en geautomatiseerde manier nodig om hun eigen identiteitsbeheer binnen Kubernetes af te handelen.

Gelukkig zijn er al alternatieven. Overweeg oplossingen die volledig X.509-certificaat (d.w.z. TLS) levenscyclusbeheer in Kubernetes bieden. Wat hebben ze nodig om waarde te bieden aan klanten? Geïntegreerde ondersteuning van machine-identiteitsverstrekkers zoals ACME en HashiCorp Vault zou een goed begin zijn, omdat organisaties dan kunnen werken met hun favoriete PKI-oplossingen. Om dit te vergemakkelijken, moet de registratieautoriteit ‘Istiod (RA) en CA worden vervangen door een nieuwe service. Deze zou dan zowel RA en gedetailleerde beleidscontroles moeten uitvoeren als integreren met de voorkeursuitgever van het bedrijf.

Elk alternatief moet het volledige proces van identiteitsafgifte en levenscyclusbeheer automatiseren, in een robuuste en betrouwbare oplossing. Dit helpt ontwikkelaars tijd te besparen en biedt de beveiliging en inzichten die securityteams nodig hebben, terwijl problemen met de naleving worden weggenomen. Het moet ook een cloud-agonistisch oplossing zijn, waarmee ontwikkelaars een gecentraliseerde en volledig geautomatiseerde aanpak van machine-identiteitsbeheer kunnen implementeren in cloud-native infrastructuren.

Andere functies die in deze context toegevoegde waarde kunnen bieden, zijn onder andere een managementinterface voor inzicht in alle clusters en het configuratiebeheer. Dit geeft securityteams de mogelijkheid om de gezondheid en status van hun beheeromgeving voor machine-identiteiten en de securityhandhaving te controleren. Dus de levenscyclus, authenticatie, autorisatie en governance van alle machine-identiteiten in hun cloudomgeving te beheren. Dit zorgt voor betere monitoring, consistentie en betrouwbaarheid. Met als resultaat een flexibel schaalbare en betere beveiliging om DevOps-teams op hoge snelheid te laten ontwikkelen en innoveren.

Innovatie faciliteren met machine-identiteitsbeheer
Service mesh-oplosisngen zoals Istio bieden een speciale infrastructuur voor het automatiseren en vereenvoudigen van processen op het gebied van beheer, beveiliging en monitoring. Dat is natuurlijk goed nieuws voor ontwikkelteams die worstelen met de toenemende omvang en complexiteit van hun containeromgevingen. Maar met ineffectief, ingebouwd machine-identiteitsbeheer kunnen ze onbedoeld nieuwe security- en compliancerisico's creëren die organisaties extra moeten beheren.

Door de juiste tools te vinden en te gebruiken om met Istio samen te werken, kunnen securityteams van bedrijven goed toezicht houden op de corporate governance en tegelijkertijd waarborgen dat machine-identiteiten worden beheerd conform dit beleid. Als dat op een volledig geautomatiseerde wijze via een centrale managementinerface gebeurt, zijn de cyberrisico’s te minimaliseren en kan men groen licht geven om de digitale transformatie van de organisatie te versnellen.