Service mesh pentru zero-trust militar: mTLS, aplicarea politicilor și observabilitate în clustere de apărare

Un cluster Kubernetes care rulează microservicii de apărare nu este în mod implicit zero-trust. Modelul implicit de rețea al podurilor permite oricărui pod să inițieze o conexiune TCP către orice alt pod din rețeaua aceluiași cluster, ceea ce înseamnă că un singur container compromis poate accesa servicii de autentificare, depozite de date și interfețe de comandă la care nu are niciun motiv legitim să ajungă. Un service mesh abordează această problemă nu prin reconfigurarea ACL-urilor de rețea — care sunt fragile în mediile containerizate dinamice — ci prin inserarea identității criptografice și a aplicării politicilor direct în calea de date a fiecărui apel serviciu-la-serviciu. Acest articol examinează ce înseamnă asta în practică pentru clusterele de apărare: cum se integrează SPIFFE/SPIRE cu arhitectura zero-trust pentru rețelele militare, cum politica bazată pe intenție înlocuiește gândirea de tip perimetru în interiorul clusterului și cum se menține observabilitatea completă fără ca vreo telemetrie să traverseze granița de clasificare.

De ce securitatea de perimetru eșuează în interiorul clusterelor de microservicii de apărare

Modelul de securitate perimetrală presupune că traficul din interiorul unei granițe de rețea de încredere este sigur. Într-o aplicație monolitică, această ipoteză are o anumită validitate: există un singur proces, o singură graniță de încredere și relativ puține căi de comunicare internă de securizat. Într-o arhitectură de microservicii implementată pe Kubernetes, ipoteza se prăbușește complet. Un cluster care rulează 20 de servicii are aproximativ 400 de perechi posibile de servicii. Nu toate ar trebui să comunice, dar fără aplicare explicită la nivelul serviciului, toate pot. O vulnerabilitate într-un serviciu — o dependență cu un defect de execuție a codului de la distanță, o variabilă de mediu configurată greșit care expune acreditările, o imagine de bază neactualizată — oferă unui adversar capacitate de mișcare laterală în întreaga rețea a clusterului.

Modul de eșec nu este teoretic. Compromiterile lanțului de aprovizionare care vizează sarcinile de lucru containerizate au demonstrat că, odată ce un adversar obține execuția de cod în interiorul unui pod, acesta sondează agresiv rețeaua clusterului. Fără autentificare mutuală, nimic nu împiedică podul compromis să apeleze direct API-urile interne: are deja o adresă IP validă de cluster, solicitările sale sosesc dintr-un interval CIDR de încredere, iar serviciul țintă nu are nicio modalitate de a verifica identitatea apelantului. Segmentarea tradițională a rețelei prin Kubernetes NetworkPolicy ajută la nivelul IP/port, dar nu face nimic pentru a preveni uzurparea identității unui pod legitim în cadrul intervalului de adrese permise și nici nu aplică nicio constrângere la nivelul aplicației privind operațiile permise.

Un service mesh rezolvă aceasta făcând obligatorie identitatea criptografică a sarcinii de lucru pentru fiecare conexiune. Fiecare proxy sidecar prezintă un SPIFFE Verifiable Identity Document (SVID) — un certificat X.509 de scurtă durată care codifică identitatea contului de serviciu a podului — și solicită sidecar-ului distant să prezinte un SVID valid înainte ca orice date de aplicație să circule. Verificarea identității are loc la nivelul de transport, transparent față de aplicație, și nu poate fi eludată de un atacator care controlează doar procesul aplicației din interiorul containerului. Mișcarea laterală este redusă de la „accesați orice pod din rețeaua clusterului" la „accesați doar podurile a căror politică permite explicit SVID-ul dvs. ca sursă."

Alegerea unui service mesh: Istio vs Linkerd vs Cilium în medii air-gapped

Trei implementări de service mesh sunt viabile în producție pentru implementările Kubernetes de apărare, fiecare cu un profil diferit de compromisuri. Istio este cel mai complet ca funcționalități: planul său de date bazat pe Envoy suportă gestionarea bogată a traficului L7, inclusiv injectarea de defecte, reîncercări, întreruperea circuitului, oglindirea solicitărilor și AuthorizationPolicy granulară. Planul de control — istiod — se integrează nativ cu SPIFFE/SPIRE pentru emiterea externă a certificatelor, iar pipeline-ul său de telemetrie emite metrici și urme compatibile OpenTelemetry din fiecare sidecar. Costul este complexitatea operațională: Istio are o curbă de învățare mai abruptă, un plan de control cu amprentă mai mare și sidecar-uri Envoy care consumă mai multă memorie per pod decât alternativele. Pentru clustere cu 16+ GB RAM per nod și echipe cu experiență în configurarea Envoy, expresivitatea politicilor Istio este greu de egalat.

Linkerd adoptă abordarea opusă. Proxy-ul său de date este scris în Rust și conceput pentru a fi ultralight: fiecare sidecar linkerd-proxy utilizează 10–20 MB de memorie rezidentă și adaugă sub 1 ms de latență per salt, față de 50–100 MB și 0,5–3 ms pentru Envoy. mTLS fără configurație al Linkerd este activat implicit pentru tot traficul de mesh fără niciun manifest PeerAuthentication necesar, ceea ce reduce riscul unei excepții de text clar configurată greșit. Compromisul constă în faptul că modelul de politici al Linkerd este mai puțin expresiv la nivelul metodelor HTTP și al căilor, iar planul său de control se integrează cu emițătorii SPIRE externi mai puțin direct decât Istio. Pentru clusterele de margine cu resurse limitate și RAM per nod redus, eficiența proxy-ului Linkerd este un avantaj operațional semnificativ.

Cilium operează la nivelul eBPF, nu ca sidecar. Prin încorporarea aplicării politicilor în programele eBPF ale kernel-ului Linux atașate la interfața de rețea a fiecărui pod, Cilium obține un overhead aproape nul per sarcină de lucru pentru aplicarea politicilor de rețea și mTLS de bază. Resursa sa CiliumNetworkPolicy suportă reguli conștiente de identitate SPIFFE prin integrarea cu API-ul SPIRE, iar componenta de observabilitate Hubble oferă vizibilitate a fluxurilor L4/L7 în cluster. Forța Cilium este performanța și înlocuirea perfectă a kube-proxy; limitarea sa constă în faptul că aplicarea politicilor HTTP/gRPC L7 via eBPF este mai puțin matură decât echivalentul bazat pe Envoy al Istio pentru scenarii complexe de autorizare. În practică, multe clustere de apărare rulează Cilium ca CNI pentru politici de rețea și criptare, cu Istio sau Linkerd adăugate deasupra pentru observabilitate L7 și AuthorizationPolicy granulară la nivel de serviciu.

mTLS: emiterea certificatelor, rotarea și integrarea SPIFFE/SPIRE

mTLS într-un service mesh înseamnă că ambele capete ale fiecărei conexiuni se autentifică reciproc cu certificate X.509 înainte ca orice date de aplicație să fie schimbate. Întrebarea critică pentru o implementare de apărare este cum sunt emise acele certificate, cât de frecvent se rotesc și cine controlează rădăcina de încredere. Istio nativ folosește propria autoritate de certificare încorporată (istiod CA), care emite certificate de sarcini de lucru valabile implicit 24 de ore. Pentru o implementare de apărare, aceasta este inadecvată din două motive: cheia rădăcină se află în interiorul clusterului (un proces istiod compromis expune toate identitățile sarcinilor de lucru) și TTL-urile de 24 de ore sunt prea lungi pentru medii în care poate fi necesară revocarea rapidă a acreditărilor.

SPIRE oferă arhitectura corectă pentru contextele de apărare. Serverul SPIRE rulează ca StatefulSet cu pachetul său de încredere și intrările de înregistrare persistate într-un datastore care poate fi ținut în afara clusterului. Agentul SPIRE rulează ca DaemonSet pe fiecare nod și gestionează atestarea sarcinilor de lucru prin verificarea token-ului de cont de serviciu Kubernetes al fiecărui pod față de serverul API înainte de emiterea unui SVID. SVID-urile emise au TTL-uri configurabile — implementările de apărare în producție folosesc TTL-uri de 1 oră pentru sarcinile de lucru standard și TTL-uri de 15 minute pentru sarcinile de lucru care gestionează date clasificate — iar agentul SPIRE gestionează rotarea automat, împingând un nou SVID la socket-ul sarcinii de lucru înainte ca cel curent să expire. Sidecar-ul de mesh citește SVID-ul prin socket-ul SPIFFE Workload API și îl prezintă pe toate conexiunile TLS de ieșire fără nicio modificare a codului aplicației.

Integrarea SPIRE cu Istio necesită configurarea istiod pentru a utiliza SPIRE ca furnizor de certificate prin interfața upstream CA plugin. Configurația CustomCA a Istio indică istiod către portul GRPC al serverului SPIRE, delegând toată emiterea și rotarea SVID-urilor către SPIRE, în timp ce Istio gestionează aplicarea PeerAuthentication și AuthorizationPolicy. Această separare a responsabilităților este importantă: SPIRE deține ciclul de viață al identității (atestare, emitere, rotare), în timp ce Istio deține ciclul de viață al politicilor (ce identități pot comunica pe ce căi). Un operator care revocă accesul unei sarcini de lucru elimină intrarea sa de înregistrare SPIRE, ceea ce face ca rotarea ulterioară a SVID să eșueze, întrerupând sarcina de lucru din mesh la următoarea reînnoire a certificatului fără a necesita nicio modificare a manifestelor de politici.

Politica de trafic bazată pe intenție: lista albă a comunicării est-vest

Principiul refuzului implicit necesită ca niciun trafic serviciu-la-serviciu să nu fie permis dacă nu este autorizat explicit prin politică. În Istio, aceasta este implementată cu un manifest AuthorizationPolicy la nivelul întregului cluster care are un bloc de reguli gol și action: DENY — care blochează tot traficul — urmat de politici de permisiune înguste pentru fiecare pereche legitimă de servicii. Fiecare politică de permisiune nominalizează principalul sursă (URI SPIFFE al contului de serviciu al serviciului apelant), serviciul destinație și setul precis de metode HTTP sau nume de servicii gRPC pentru care apelul este autorizat. O politică care autorizează un serviciu de ingestie a datelor senzorilor să facă POST către API-ul de fuziune a datelor, de exemplu, nu îi permite să facă GET la înregistrările istorice sau să apeleze endpoint-ul de administrare, chiar dacă ambele rulează pe același port al serviciului destinație. Granularitatea este la nivelul operației, nu doar la nivelul conexiunii TCP.

Scrierea și menținerea acestui set de politici necesită disciplină. Un cluster care crește de la 10 la 30 de servicii în 18 luni acumulează sute de intrări de permisiune, iar intrările obsolete pentru servicii dezafectate devin suprafață de atac latentă. Două practici previn această acumulare. În primul rând, tratați manifestele AuthorizationPolicy ca pe cod: stocați-le în același depozit versionat ca și manifestele de aplicații, solicitați revizuire pentru fiecare nouă intrare de permisiune și auditați setul de politici trimestrial față de lista serviciilor care rulează curent. În al doilea rând, folosiți jurnalizarea de acces a mesh-ului — fiecare solicitare respinsă generează o intrare în jurnalul de acces al sidecar-ului care include SVID-ul sursă, destinația și operația — pentru a identifica căile de trafic legitime cărora le lipsește o politică, în loc să ocolească silențios mesh-ul. Această jurnalizare oferă de asemenea traseul forensic cerut de multe cadre de securitate de apărare pentru a demonstra că deciziile de control al accesului sunt auditabile.

Observabilitate fără exfiltrarea datelor: metrici și urmărire în cluster

Un service mesh generează telemetrie bogată automat din proxy-urile sale sidecar: rate de solicitare per serviciu, rate de eroare detaliate după codul de stare HTTP și statusul gRPC, percentile de latență (p50, p95, p99), număr de conexiuni active și metrici de handshake TLS. Într-o implementare comercială în cloud, această telemetrie este de obicei redirecționată către o platformă de observabilitate SaaS. Într-un cluster militar clasificat, orice pipeline de telemetrie care trimite date în afara graniței de clasificare reprezintă un potențial vector de exfiltrare și este arhitectural interzis. Întreaga stivă de observabilitate trebuie implementată în interiorul graniței clusterului și trebuie ea însăși controlată de aceleași politici de mesh care guvernează traficul aplicațiilor.

Stiva standard de observabilitate în cluster pentru un service mesh constă din Prometheus pentru colectarea metricilor, Grafana pentru vizualizare și Jaeger sau Tempo pentru urmărirea distribuită. Prometheus colectează endpoint-ul de statistici Envoy (portul 15090) sau endpoint-ul de metrici linkerd-proxy pe fiecare pod de mesh la un interval configurabil. Grafana se conectează exclusiv la instanțele Prometheus și Loki din cluster — nu sunt configurate conexiuni la surse externe de date. Jaeger primește span-uri de urme redirecționate de sidecar-ul Envoy prin protocolul Zipkin sau OpenTelemetry către un endpoint de colector local clusterului. Toate stocările persistente pentru metrici, urme și jurnale folosesc PersistentVolume-uri locale ale clusterului, susținute de stocare bloc criptată. Spațiul de nume de monitorizare în sine poartă o NetworkPolicy care blochează toate egreselele la intervalele IP externe, făcând arhitectural imposibilă ieșirea telemetriei din cluster chiar dacă un pipeline greșit configurat ar fi introdus.

Pentru clusterele Kubernetes consolidate pentru sarcini de lucru de apărare, merită menționat că stiva de observabilitate trebuie de asemenea aprovizionată din registre air-gapped. Imaginile Prometheus, Grafana, Jaeger și Loki trebuie copiate în oglindă în registrul intern cu digest-uri verificate înainte ca clusterul să fie plasat în spatele graniței de clasificare. Politicile de extragere a imaginilor trebuie setate la Never sau IfNotPresent, înțelegând că imaginile nu vor fi niciodată reîmprospătate dintr-o sursă externă. Orice actualizare a stivei de observabilitate necesită un proces formal de gestionare a modificărilor care aduce imaginile actualizate prin procedura air-gap, nu o simplă actualizare a chart-ului Helm față de un depozit public.

Overhead sidecar în clusterele de margine de apărare cu resurse limitate

Clusterele de margine implementate aproape de operațiuni — rulând pe servere cu factor de formă redus sau platforme de calcul consolidate cu 32–64 GB RAM și 4–8 noduri — se confruntă cu un buget de resurse care face overhead-ul sidecar o constrângere de inginerie reală, nu o preocupare teoretică. Un sidecar Envoy Istio în stare stabilă consumă 50–100 MB de dimensiune a setului rezident și până la 0,5 vCPU în perioadele de randament ridicat. Un cluster care rulează 40 de poduri consumă 2–4 GB de memorie sidecar agregată, aproximativ 6–12% din RAM total al unui cluster de 32 GB. Planul de control în sine — istiod, Prometheus, Grafana, Jaeger — adaugă încă 2–4 GB, aducând overhead-ul total al infrastructurii de mesh la 15–25% din memoria clusterului înainte ca sarcinile de lucru ale aplicațiilor să fie luate în considerare.

Trei opțiuni reduc acest overhead în implementările restrictive. În primul rând, proxy-ul bazat pe Rust al Linkerd este cel mai eficient sidecar disponibil: 10–20 MB per pod față de 50–100 MB pentru Envoy, și overhead de latență sub 1 ms per salt. Pentru clustere unde cerințele de granularitate a politicilor L7 pot fi satisfăcute de modelul de politici al Linkerd, economiile de memorie sunt substanțiale. În al doilea rând, modul ambient mesh al Istio (disponibil din Istio 1.22) elimină complet sidecar-ele per pod, înlocuindu-le cu un proxy ztunnel per nod care gestionează mTLS pentru toate podurile de pe nod. Modul ambient reduce overhead-ul per pod la aproape zero cu costul mutării aplicării politicilor de la sidecar-e per sarcină de lucru la proxy-uri per nod, oferind o granularitate ușor mai grosieră pentru sarcinile de lucru care necesită decizii de autorizare per solicitare. În al treilea rând, injecția selectivă — injectând sidecar-e doar în podurile care necesită aplicarea politicilor L7 și folosind criptarea eBPF a Cilium pentru L4 pentru restul — echilibrează granularitatea aplicării față de consumul de resurse pentru sarcini de lucru eterogene ale clusterului.

Interacțiunea dintre consumul de resurse al sidecar-ului și gestionarea secretelor în pipeline-urile CI/CD de apărare merită menționată explicit. Sidecar-ele de injectare a secretelor (Vault Agent Injector, Secrets Store CSI Driver) adaugă un alt container per pod. Un cluster de margine care rulează atât un sidecar de mesh cât și un sidecar de injectare a secretelor per pod de aplicație are două containere de infrastructură pentru fiecare container de aplicație, dublând numărul de containere și adăugând 60–120 MB de overhead de infrastructură per pereche de poduri. Consolidarea este posibilă: agentul SPIRE poate servi atât ca emițător de identitate de mesh cât și ca mecanism de livrare a secretelor sarcinilor de lucru pentru secretele care pot fi exprimate ca roluri Vault autorizate prin SVID, eliminând sidecar-ul separat de injectare a secretelor pentru acele sarcini de lucru.

Integrarea politicii service mesh cu RBAC și gestionarea secretelor

RBAC Kubernetes guvernează cine poate citi și modifica obiectele API Kubernetes — inclusiv resursele AuthorizationPolicy, PeerAuthentication și de configurare a mesh-ului care definesc postura de securitate a service mesh-ului. Dacă configurația RBAC permite unui set larg de principali să modifice obiectele AuthorizationPolicy, stratul de control al accesului al mesh-ului poate fi slăbit de oricare dintre acei principali. O implementare corectă de apărare tratează manifestele de politici de mesh ca obiecte de securitate de înaltă valoare: doar contul de serviciu CI/CD care aplică manifestele din depozitul de politici versionat ar trebui să aibă acces de scriere la resursele AuthorizationPolicy și PeerAuthentication, iar doar administratorii de cluster ar trebui să poată modifica intrările de înregistrare SPIRE. Toți ceilalți principali — inclusiv conturile de serviciu individuale ale aplicațiilor — ar trebui să aibă acces de citire sau niciun acces la aceste obiecte.

Relația dintre stratul de identitate al mesh-ului și stratul de gestionare a secretelor este bidirecțională. Mesh-ul folosește SPIFFE SVID-uri pentru a autentifica apelurile serviciu-la-serviciu la nivelul de transport. Gestionarea secretelor (Vault, Kubernetes Secrets Store CSI Driver) folosește aceleași identități bazate pe SVID pentru a determina ce sarcini de lucru pot primi ce secrete la nivelul aplicației. O sarcină de lucru cu ID SPIFFE spiffe://cluster.local/ns/fusion/sa/data-processor poate fi mapată la un rol Vault care acordă acces de citire exact la acreditările de bază de date de care are nevoie acel serviciu — și nimic altceva. Aceasta înseamnă că sistemul de identitate al mesh-ului și sistemul de livrare a secretelor partajează o singură sursă autoritativă de identitate a sarcinilor de lucru, eliminând riscul unui decalaj în care o sarcină de lucru are acces la rețea dar nu are secretele necesare pentru a-l folosi, sau invers. Menținerea acestei alinieri necesită ca intrările de înregistrare SPIRE, definițiile rolurilor Vault și manifestele AuthorizationPolicy ale mesh-ului să fie actualizate împreună atunci când un serviciu este adăugat, modificat sau dezafectat.

Jurnalizarea de audit leagă cele trei sisteme pentru conformitate și răspuns la incidente. Sidecar-ul de mesh înregistrează fiecare decizie de acces — permis sau respins — cu SVID-ul sursă verificat, destinația, operația și timestamp-ul. Vault înregistrează fiecare acces la secret cu identitatea solicitantă și calea secretului accesat. Jurnalele de audit ale serverului API Kubernetes înregistrează fiecare apel API guvernat de RBAC. Împreună, aceste trei fluxuri de jurnale oferă un traseu complet de audit de la „ce apel de rețea a fost efectuat" prin „ce secrete au fost accesate ca rezultat" până la „cine a schimbat politica care guverna ambele." Pentru mediile de apărare care operează sub cerințe formale de acreditare, această trasabilitate pe straturile de identitate, control al accesului și secrete este adesea o cerință de conformitate obligatorie, nu o comoditate operațională.