Service Mesh Field Report #1
Als "veilig" alleen een onderbuikgevoel is
Dit is een Nederlandse vertaling. Het report verscheen eerst in het Duits. Lees het Duitse origineel
Typisch beeld bij Istio-audits: mTLS overal geactiveerd, dashboards groen, compliance-vinkje gezet.
Drie uur later staat vast: niemand in het team kan met zekerheid zeggen welke services daadwerkelijk versleuteld communiceren. De setup is “veilig”, op gevoel.
Geen uitzondering. Dit is het patroon.
Istio wordt ingevoerd om security en stabiliteit te verhogen. In de praktijk zie ik regelmatig het tegenovergestelde. Istio is niet het probleem. De invoering wel: technisch aangevlogen, niet structureel.
Wat dat kost:
Een engineer neemt ontslag en met hem verdwijnt de kennis over hoe incidents in het mesh überhaupt geanalyseerd worden. Bus-factor 1 als bedrijfsrisico dat in geen enkel risk register staat.
Een auditor vraagt welke traffic policies waar gelden. Het antwoord duurt twee dagen en is uiteindelijk niet eenduidig.
Bij een production incident hangt de time-to-recovery ervan af of “die ene” op dat moment bereikbaar is.
Het eigenlijke probleem is zelden de configuratie. Het is het gebrek aan duidelijkheid over wie er echt verantwoordelijk is voor het netwerkgedrag in het cluster, welke regels bindend zijn (en niet alleen gedocumenteerd), en of een incident reproduceerbaar te analyseren is of van personen afhangt.
Zonder die basis wordt Istio met elke nieuwe service risicovoller, niet veiliger.
De vraag is niet of Istio goed geconfigureerd is. De vraag is of het systeem erachter schaalbaar is opgezet, of dat jullie op dit moment technische schuld aan het certificeren zijn.
Welke symptomen herkennen jullie in je eigen setup? Daar maak ik de onderwerpen van voor de komende weken.
Discussie over dit report op LinkedIn (Duitstalig)
Uit de praktijk, voor de praktijk
Achter elk report zitten patronen uit echte mesh-omgevingen. Klinkt er één als jullie cluster? In een architectuurgesprek kijken we er samen naar.
Architectuurgesprek aanvragen