Service mesh voor militaire zero-trust: mTLS, beleidshandhaving en observabiliteit in defensieclusters

Een Kubernetes-cluster met defensie-microservices is niet inherent zero-trust. Het standaard pod-netwerkmodel staat elke pod toe een TCP-verbinding te initiëren naar elke andere pod op hetzelfde clusternetwerk, wat betekent dat één gecompromitteerde container authenticatiediensten, gegevensopslag en commandointerfaces kan bereiken waartoe hij geen legitieme reden heeft toegang te hebben. Een service mesh lost dit niet op door netwerk-ACL's opnieuw te configureren — die zijn kwetsbaar in dynamische containeromgevingen — maar door cryptografische identiteit en beleidshandhaving rechtstreeks in het datapad van elke service-naar-service-aanroep in te voegen. Dit artikel onderzoekt wat dat in de praktijk betekent voor defensieclusters: hoe SPIFFE/SPIRE integreert met zero-trust-architectuur voor militaire netwerken, hoe op intentie gebaseerd beleid perimeterdenken binnen het cluster vervangt, en hoe volledige observabiliteit te behouden zonder dat telemetrie de classificatiegrens overschrijdt.

Waarom perimeterbeveiliging faalt binnen defensie-microservice-clusters

Het perimetermodernbeveiligingsmodel gaat ervan uit dat verkeer binnen een vertrouwde netwerkgrens veilig is. In een monolithische applicatie heeft deze aanname enige geldigheid: er is één proces, één vertrouwensgrens en relatief weinig interne communicatiepaden te beveiligen. In een microservice-architectuur ingezet op Kubernetes stort de aanname volledig in. Een cluster met 20 services heeft in de orde van 400 mogelijke serviceparen. Niet alle mogen communiceren, maar zonder expliciete handhaving op serviceniveau kunnen ze dat allemaal. Een kwetsbaarheid in één service — een afhankelijkheid met een fout die externe code-uitvoering mogelijk maakt, een verkeerd geconfigureerde omgevingsvariabele die inloggegevens blootlegt, een niet-bijgewerkte basisimage — geeft een tegenstander laterale bewegingscapaciteit over het volledige clusternetwerk.

De faalwijze is niet theoretisch. Supply-chain-compromissen gericht op containerworkloads hebben aangetoond dat zodra een tegenstander code-uitvoering heeft binnen een pod, hij het clusternetwerk agressief verkent. Zonder wederzijdse authenticatie is er niets dat de gecompromitteerde pod ervan weerhoudt interne API's rechtstreeks aan te roepen: hij heeft al een geldig cluster-IP, zijn verzoeken komen aan vanuit een vertrouwd CIDR-bereik, en de doelservice heeft geen manier om de identiteit van de aanroeper te verifiëren. Traditionele netwerksegmentatie via Kubernetes NetworkPolicy helpt op de IP/poortlaag maar doet niets om te voorkomen dat de identiteit van een legitieme pod wordt nagebootst binnen het toegestane adresbereik, noch handhaaft het toepassingslaagbeperkingen op welke bewerkingen zijn toegestaan.

Een service mesh lost dit op door cryptografische werklaadidentiteit verplicht te stellen voor elke verbinding. Elke sidecar-proxy presenteert een SPIFFE Verifiable Identity Document (SVID) — een kortlevend X.509-certificaat dat de serviceaccount-identiteit van de pod codeert — en vereist dat de externe sidecar een geldig SVID terugpresenteert voordat applicatiegegevens stromen. De identiteitscontrole vindt plaats op de transportlaag, transparant voor de applicatie, en kan niet worden omzeild door een aanvaller die alleen het applicatieproces binnen de container beheerst. Laterale beweging wordt gereduceerd van "bereik elke pod op het clusternetwerk" tot "bereik alleen pods waarvan het beleid uw SVID expliciet toestaat als bron."

Een service mesh kiezen: Istio vs Linkerd vs Cilium in air-gapped omgevingen

Drie service mesh-implementaties zijn productiegeschikt voor defensie-Kubernetes-implementaties, elk met een ander afwegingsprofiel. Istio is de meest complete: het op Envoy gebaseerde datavlak ondersteunt rijke L7-verkeersbeheerfuncties waaronder foutinjectie, hertries, circuit breaking, verzoekspiegeling en fijnkorrelig AuthorizationPolicy. Het controlevlak — istiod — integreert native met SPIFFE/SPIRE voor externe certificaatuitgifte, en zijn telemetriepijplijn zendt OpenTelemetry-compatibele statistieken en traces uit vanuit elke sidecar. De kosten zijn operationele complexiteit: Istio heeft een steilere leercurve, een grotere controlevlakvoetafdruk en Envoy-sidecars die meer geheugen per pod verbruiken dan alternatieven. Voor clusters met 16+ GB RAM per knooppunt en teams die ervaren zijn met Envoy-configuratie, is Istio's beleidsexpressiviteit moeilijk te evenaren.

Linkerd neemt de tegengestelde aanpak. De datavlakproxy is geschreven in Rust en ontworpen om ultralight te zijn: elke linkerd-proxy-sidecar gebruikt 10–20 MB resident geheugen en voegt minder dan 1 ms latentie toe aan elke hop, vergeleken met 50–100 MB en 0,5–3 ms voor Envoy. Linkerd's zero-configuratie mTLS is standaard ingeschakeld voor al het meshed verkeer zonder dat een PeerAuthentication-manifest vereist is, wat het risico op een verkeerd geconfigureerde plaintext-uitzondering vermindert. Het nadeel is dat Linkerd's beleidsmodel minder expressief is op het HTTP-methode- en padniveau, en dat het controlevlak minder direct integreert met externe SPIRE-uitgevers dan Istio. Voor resource-beperkte edge-clusters met beperkt RAM per knooppunt is Linkerd's proxy-efficiëntie een aanzienlijk operationeel voordeel.

Cilium werkt op de eBPF-laag in plaats van als een sidecar. Door beleidshandhaving in te bedden in de eBPF-programma's van de Linux-kernel die zijn gekoppeld aan de netwerkinterface van elke pod, bereikt Cilium vrijwel nul per-werklast overhead voor netwerkbeleidshandhaving en basis mTLS. De CiliumNetworkPolicy-resource ondersteunt SPIFFE-identiteitsbewuste regels via integratie met de SPIRE API, en de Hubble-observabiliteitscomponent biedt L4/L7-stroomzichtbaarheid binnen het cluster. Cilium's sterkte is prestatie en de naadloze vervanging van kube-proxy; de beperking is dat L7 HTTP/gRPC-beleidshandhaving via eBPF minder volwassen is dan Istio's op Envoy gebaseerde equivalent voor complexe autorisatiescenario's. In de praktijk draaien veel defensieclusters Cilium als de CNI voor netwerkbeleid en versleuteling, met Istio of Linkerd er bovenop gelaagd voor L7-observabiliteit en fijnkorrelig AuthorizationPolicy op serviceniveau.

Wederzijdse TLS: certificaatuitgifte, rotatie en SPIFFE/SPIRE-integratie

Wederzijdse TLS in een service mesh betekent dat beide zijden van elke verbinding elkaar authenticeren met X.509-certificaten voordat applicatiegegevens worden uitgewisseld. De kritieke vraag voor een defensie-implementatie is hoe die certificaten worden uitgegeven, hoe vaak ze roteren en wie de vertrouwensanker beheert. Native Istio gebruikt zijn eigen ingebouwde certificeringsinstantie (de istiod CA), die werklaadcertificaten uitgeeft die standaard 24 uur geldig zijn. Voor een defensie-implementatie is dit op twee punten ontoereikend: de rootsleutel bevindt zich in het cluster (een gecompromitteerd istiod-proces stelt alle werklaadidentiteiten bloot), en TTLs van 24 uur zijn te lang voor omgevingen waar snelle intrekking van inloggegevens vereist kan zijn.

SPIRE biedt de juiste architectuur voor defensiecontexten. De SPIRE-server draait als een StatefulSet met zijn vertrouwensbundel en registratievermelding opgeslagen in een gegevensopslag die buiten het cluster kan worden gehouden. De SPIRE-agent draait als een DaemonSet op elk knooppunt en behandelt werklaadattestatie door het Kubernetes-serviceaccounttoken van elke pod te verifiëren bij de API-server voordat een SVID wordt uitgegeven. Uitgegeven SVIDs hebben configureerbare TTLs — productie-defensie-implementaties gebruiken 1-uur TTLs voor standaardwerklasten en 15-minuten TTLs voor werklasten die geclassificeerde gegevens verwerken — en de SPIRE-agent behandelt rotatie automatisch, waarbij een nieuw SVID naar de werklastsocket wordt gepusht voordat het huidige verloopt. De mesh-sidecar leest de SVID via de SPIFFE Workload API-socket en presenteert deze op alle uitgaande TLS-verbindingen zonder enige wijziging in de applicatiecode.

SPIRE integreren met Istio vereist dat istiod wordt geconfigureerd om SPIRE als zijn certificaatprovider te gebruiken via de upstream CA-plugin-interface. Istio's CustomCA-configuratie wijst istiod naar de GRPC-poort van de SPIRE-server, waarbij alle SVID-uitgifte en rotatie aan SPIRE wordt gedelegeerd terwijl Istio de PeerAuthentication- en AuthorizationPolicy-handhaving afhandelt. Deze scheiding van verantwoordelijkheden is belangrijk: SPIRE is eigenaar van de identiteitslevenscyclus (attestatie, uitgifte, rotatie), terwijl Istio eigenaar is van de beleidslevenscyclus (welke identiteiten mogen communiceren op welke paden). Een operator die de toegang van een werklast intrekt, verwijdert de SPIRE-registratievermelding, waardoor de volgende SVID-rotatie mislukt en de werklast bij de volgende certificaatverlenging van de mesh wordt afgesneden zonder dat beleidsmanifestwijzigingen vereist zijn.

Op intentie gebaseerd verkeersbeleid: oost-westcommunicatie op de allowlist zetten

Het standaard-weiger-principe vereist dat geen service-naar-service-verkeer is toegestaan tenzij het beleid dit expliciet toestaat. In Istio wordt dit geïmplementeerd met een clusterbreed AuthorizationPolicy-manifest met een leeg rules-blok en action: DENY — wat al het verkeer blokkeert — gevolgd door smalle toestemmingsbeleidsregels voor elk legitiem servicepaar. Elk toestemmingsbeleid benoemt de bronprincipal (de SPIFFE URI van het serviceaccount van de aanroepende service), de doelservice en de precieze set HTTP-methoden of gRPC-servicenamen waarvoor de aanroep is geautoriseerd. Een beleid dat een sensorgegevensingestieservice autoriseert om te POSTen naar de datafusie-API staat hem bijvoorbeeld niet toe ook GET te doen op historische records of het beheereindpunt aan te roepen, ook al draaien beide op dezelfde doelservicepoort. De korrelheid is op het bewerkingsniveau, niet slechts op het TCP-verbindingsniveau.

Het schrijven en onderhouden van deze beleidsset vereist discipline. Een cluster dat in 18 maanden groeit van 10 naar 30 services accumuleert honderden toestemmingsvermeldingen, en verouderde vermeldingen voor buiten gebruik gestelde services worden latent aanvalsoppervlak. Twee praktijken voorkomen deze accumulatie. Ten eerste, behandel AuthorizationPolicy-manifesten als code: sla ze op in dezelfde versiebeheerde repository als de applicatiemanifesten, vereist peer review voor elke nieuwe toestemmingsvermelding en controleer de beleidsset elk kwartaal op de lijst van momenteel actieve services. Ten tweede, gebruik de toegangslogboekregistratie van de mesh — elk geweigerd verzoek genereert een toegangslogboekvermelding in de sidecar die de bron-SVID, bestemming en bewerking bevat — om legitieme verkeerspaden te identificeren die een beleid missen in plaats van de mesh stilzwijgend te omzeilen. Deze logboekregistratie biedt ook het forensisch spoor dat vereist is door veel defensiebeveiligingskaders om aan te tonen dat toegangscontrolebeslissingen auditeerbaar zijn.

Observabiliteit zonder data-exfiltratie: in-cluster statistieken en tracering

Een service mesh genereert automatisch rijke telemetrie vanuit zijn sidecar-proxy's: per-service aanvraagsnelheden, foutpercentages uitgesplitst naar HTTP-statuscode en gRPC-status, latentiepercentielwaarden (p50, p95, p99), actieve verbindingsaantallen en TLS-handshake-statistieken. In een commerciële cloudimplementatie wordt deze telemetrie doorgaans doorgestuurd naar een SaaS-observabiliteitsplatform. In een geclassificeerd militair cluster is elke telemetriepijplijn die gegevens buiten de classificatiegrens stuurt een potentieel exfiltratievector en architecturaal verboden. De volledige observabiliteitstack moet worden ingezet binnen de clustergrens en moet zelf worden toegangsgecontroleerd door hetzelfde meshbeleid dat applicatieverkeer regelt.

De standaard in-cluster observabiliteitstack voor een service mesh bestaat uit Prometheus voor het verzamelen van statistieken, Grafana voor visualisatie en Jaeger of Tempo voor gedistribueerde tracering. Prometheus scrapt het Envoy stats-eindpunt (poort 15090) of het linkerd-proxy metrics-eindpunt op elke gemeshte pod met een configureerbaar interval. Grafana maakt uitsluitend verbinding met de in-cluster Prometheus- en Loki-instanties — er zijn geen externe gegevensbronverbindingen geconfigureerd. Jaeger ontvangt trace-spans doorgestuurd door de Envoy-sidecar via het Zipkin- of OpenTelemetry-protocol naar een clusterlocaal collector-eindpunt. Alle persistente opslag voor statistieken, traces en logboeken gebruikt clusterlocale PersistentVolumes ondersteund door versleutelde blokopslag. De monitoring-namespace zelf draagt een NetworkPolicy die al het egress naar externe IP-bereiken blokkeert, waardoor het architecturaal onmogelijk is dat telemetrie het cluster verlaat, zelfs als een verkeerd geconfigureerde pijplijn zou worden geïntroduceerd.

Voor Kubernetes-clusters gehard voor defensiewerklasten is het vermeldenswaard dat de observabiliteitstack ook moet worden betrokken van air-gapped registers. Prometheus-, Grafana-, Jaeger- en Loki-images moeten worden gespiegeld naar het interne register met geverifieerde digests voordat het cluster achter de classificatiegrens wordt geplaatst. Image-pullbeleidsregels moeten worden ingesteld op Never of IfNotPresent, met het begrip dat de images nooit worden vernieuwd vanuit een externe bron. Elke update van de observabiliteitstack vereist een formeel wijzigingsbeheerproces dat bijgewerkte images door de air-gap-procedure brengt in plaats van een eenvoudige Helm-chart-upgrade tegen een openbare chartrepository.

Sidecar-overhead in resource-beperkte defensie-edge-clusters

Edge-clusters ingezet dicht bij operaties — draaiend op kleinformaatservers of geharde computerplatforms met 32–64 GB RAM en 4–8 knooppunten — staan voor een resourcebudget dat sidecar-overhead tot een echte engineeringbeperking maakt in plaats van een theoretische zorg. Een Istio Envoy-sidecar verbruikt in stabiele toestand 50–100 MB resident set size en tot 0,5 vCPU tijdens perioden met hoge doorvoer. Een cluster met 40 pods verbruikt 2–4 GB totaal sidecar-geheugen, ruwweg 6–12% van het totale RAM van een 32 GB cluster. Het controlevlak zelf — istiod, Prometheus, Grafana, Jaeger — voegt nog eens 2–4 GB toe, waardoor de totale mesh-infrastructuuroverhead op 15–25% van het clustergeheugen komt voordat applicatiewerklasten worden overwogen.

Drie opties verminderen deze overhead in beperkte implementaties. Ten eerste is Linkerd's op Rust gebaseerde proxy de meest efficiënte sidecar beschikbaar: 10–20 MB per pod in plaats van 50–100 MB voor Envoy, en latentieoverhead onder 1 ms per hop. Voor clusters waar aan L7-beleidskorreligheidsvereisten kan worden voldaan door Linkerd's beleidsmodel zijn de geheugenbesparingen aanzienlijk. Ten tweede elimineert Istio's ambient mesh-modus (beschikbaar vanaf Istio 1.22) per-pod sidecars volledig en vervangt ze door een per-knooppunts ztunnel-proxy die mTLS afhandelt voor alle pods op het knooppunt. Ambient-modus vermindert de per-pod overhead tot vrijwel nul ten koste van het verplaatsen van beleidshandhaving van per-werklast sidecars naar per-knooppunts proxy's, wat een iets grovere beleidskorrelheid biedt voor werklasten die per-verzoek autorisatiebeslissingen nodig hebben. Ten derde balanceert selectieve injectie — alleen sidecars injecteren in pods die L7-beleidshandhaving vereisen, en Cilium's eBPF-gebaseerde L4-versleuteling gebruiken voor de rest — handhavingskorrelheid tegen resourceverbruik voor heterogene clusterworkloads.

De interactie tussen sidecar-resourceverbruik en geheimenbeheer in defensie-CI/CD-pijplijnen is het waard expliciet te vermelden. Geheimeninjectieside cars (Vault Agent Injector, Secrets Store CSI Driver) voegen een extra container per pod toe. Een edge-cluster dat zowel een mesh-sidecar als een geheimeninjectie-sidecar per applicatiepod draait, heeft twee infrastructuurcontainers voor elke applicatiecontainer, waardoor het containeraantal verdubbelt en 60–120 MB aan infrastructuuroverhead per podpaar wordt toegevoegd. Consolidatie is mogelijk: de SPIRE-agent kan dienen als zowel de mesh-identiteitsuitgever als het bezorgmechanisme voor werklaadgeheimen voor geheimen die kunnen worden uitgedrukt als SVID-geautoriseerde Vault-rollen, waardoor de afzonderlijke geheimeninjectie-sidecar voor die werklasten wordt geëlimineerd.

Service mesh-beleid integreren met RBAC en geheimenbeheer

Kubernetes RBAC regelt wie Kubernetes API-objecten kan lezen en wijzigen — inclusief de AuthorizationPolicy-, PeerAuthentication- en mesh-configuratiebronnen die de beveiligingshouding van de service mesh definiëren. Als de RBAC-configuratie een brede set principals toestaat AuthorizationPolicy-objecten te wijzigen, kan de toegangscontrolaag van de mesh worden verzwakt door elk van die principals. Een correcte defensie-implementatie behandelt mesh-beleidsmanifesten als hoogwaardige beveiligingsobjecten: alleen het CI/CD-serviceaccount dat manifesten toepast vanuit de versiebeheerde beleidsrepository mag schrijftoegang hebben tot AuthorizationPolicy- en PeerAuthentication-bronnen, en alleen clusterbeheerders mogen SPIRE-registratievermelding wijzigen. Alle andere principals — inclusief individuele applicatieserviceaccounts — moeten alleen-lezen of geen toegang hebben tot deze objecten.

De relatie tussen de mesh-identiteitslaag en de geheimensbeheerlaag is bidirectioneel. De mesh gebruikt SPIFFE SVIDs om service-naar-service-aanroepen op de transportlaag te authenticeren. Geheimenbeheer (Vault, Kubernetes Secrets Store CSI Driver) gebruikt diezelfde SVID-gebaseerde identiteiten om te bepalen welke werklasten welke geheimen mogen ontvangen op de applicatielaag. Een werklast met SPIFFE ID spiffe://cluster.local/ns/fusion/sa/data-processor kan worden toegewezen aan een Vault-rol die leestoegang verleent tot precies de databaseinloggegevens die die service nodig heeft — en niets anders. Dit betekent dat het mesh-identiteitssysteem en het geheimensbezorgsysteem één gezaghebbende bron van werklaadidentiteit delen, waardoor het risico op een mismatch wordt geëlimineerd waarbij een werklast netwerktoegang heeft maar niet de geheimen die nodig zijn om deze te gebruiken, of omgekeerd. Het handhaven van deze afstemming vereist dat SPIRE-registratievermelding, Vault-roldefinities en mesh-AuthorizationPolicy-manifesten allemaal samen worden bijgewerkt wanneer een service wordt toegevoegd, gewijzigd of buiten gebruik gesteld.

Auditlogboekregistratie verbindt de drie systemen voor compliance en incidentrespons. De mesh-sidecar registreert elke toegangsbeslissing — toestaan of weigeren — met de geverifieerde bron-SVID, bestemming, bewerking en tijdstempel. Vault registreert elke geheimtoegang met de aanvragende identiteit en het pad van het benaderde geheim. Kubernetes API-server-auditlogboeken registreren elke RBAC-gestuurde API-aanroep. Samen bieden deze drie logstromen een volledig auditspoor van "welke netwerkoproep werd gedaan" via "welke geheimen werden daardoor benaderd" tot "wie het beleid wijzigde dat beide regelde." Voor defensieomgevingen die opereren onder formele accreditatievereisten is deze traceerbaarheid over de identiteits-, toegangscontrole- en geheimenslagen vaak een niet-onderhandelbare compliancevereiste in plaats van een operationeel gemak.