Kubernetes între enclave de securitate: clustere multi-clasificare

Programele de apărare operează rareori la un singur nivel de clasificare. Același software de misiune care ingerează fluxuri open-source într-o enclavă Unclassified are adesea o variantă Secret care îl fuzionează cu colectare sensibilă și uneori o variantă Top Secret deasupra. Instinctul unui inginer obișnuit cu Kubernetes comercial este să modeleze aceste niveluri ca spații de nume, chiriași sau clustere virtuale în cadrul unei singure platforme. Acel instinct este greșit pentru munca clasificată, iar greșeala este costisitor de remediat. Într-un mediu multi-level secure (MLS), clusterul Kubernetes – și rețeaua pe care se află – este granița de clasificare, nu un detaliu de chiriaș din interiorul său. Acest articol parcurge cum să rulezi Kubernetes între enclave de securitate: un cluster acreditat per nivel de clasificare, izolare strictă a politicilor în cadrul fiecăruia, proveniență verificabilă a imaginilor și promovare controlată, unidirecțională a artefactelor între domenii.

Granița este clusterul, nu spațiul de nume

Kubernetes îți oferă mai multe mecanisme care arată ca izolare: spații de nume, NetworkPolicies, RBAC, cote de resurse și control de admitere. Fiecare dintre ele este un control de chiriaș care operează în interiorul unei singure granițe de încredere. Toate partajează același server API, aceeași magazie de date etcd, același kernel Linux pe fiecare nod și același runtime de container. O evadare de container printr-o vulnerabilitate de kernel, o eroare în calea de autorizare a serverului API sau un singur ClusterRoleBinding prea larg poate trece simultan fiecare dintre acele granițe moi.

Un acreditator care examinează un sistem MLS pune o întrebare simplă: ce împiedică fizic sau criptografic datele Secret să ajungă pe partea Unclassified? „O NetworkPolicy" nu este un răspuns acceptabil, deoarece o NetworkPolicy este impusă de același plugin CNI și kernel pe care rulează chiar sarcinile de lucru. Răspunsul acceptat este separarea: clustere separate, rețele separate, hardware separat sau partiții separate izolate criptografic, fiecare acreditată să proceseze exact un nivel. Spațiile de nume rămân utile – dar doar ca compartimente administrative în cadrul unei singure enclave, niciodată ca linia dintre Unclassified și Secret.

Acesta este același principiu care stă la baza soluțiilor cross-domain pentru apărare: datele se mută între niveluri doar printr-o gardă acreditată, niciodată printr-un control software partajat la care ambele părți pot ajunge. Kubernetes multi-enclavă pur și simplu aplică acel principiu stratului de orchestrare.

Un cluster per enclavă: topologia de referință

Topologia de referință pentru un program cu trei niveluri este de trei implementări Kubernetes complet independente, una per enclavă:

Enclavă Unclassified / de dezvoltare. Aici se desfășoară cea mai mare parte a ingineriei. Are cea mai largă conectivitate (adesea o cale către internet printr-un proxy pentru a trage dependențe upstream), cea mai permisivă cadență de schimbare și conducta de build care produce artefactele pe care enclavele superioare le vor consuma în cele din urmă. Este totuși întărită – rețea de tip refuz implicit, imagini semnate, fără pod-uri privilegiate – dar este singura enclavă în care se nasc imagini noi.

Enclavă Secret. Deconectat de internetul public, acest cluster rulează varianta Secret a software-ului de misiune. Trage imagini doar din propriul registru intra-enclavă, care este populat exclusiv prin promovare de jos. Cadența sa de schimbare este mai lentă și fiecare implementare este legată de o lansare acreditată. Disciplina operațională de aici seamănă cu o implementare Kubernetes air-gapped – registre offline, fără trageri upstream în timp real și un proces de upgrade care trebuie să supraviețuiască acreditării.

Enclavă Top Secret. Cel mai restricționat cluster, pe cea mai izolată rețea, cu cele mai stricte controale de personal și fizice. Primește un subset curat de artefacte de pe partea Secret, din nou doar printr-un transfer acreditat.

Fiecare enclavă este un univers Kubernetes complet și autosuficient: propriul plan de control și etcd, propriul CNI și clase de stocare, propriul registru de imagini, propriul furnizor de identitate și RBAC, propriul controler GitOps și propria stivă de observabilitate. Nimic dintr-o enclavă superioară nu depinde de accesibilitatea unui serviciu dintr-o enclavă inferioară la runtime. Acea independență este ceea ce permite fiecărui cluster să fie acreditat în propriii termeni.

De ce federația între niveluri este un canal ascuns

Scurtătura tentantă este să federezi identitatea, distribuția imaginilor sau GitOps între enclave astfel încât operatorii să aibă o singură consolă. Rezistă-i. O federație de autentificare în timp real care emite un token utilizabil atât pe partea Unclassified cât și pe cea Secret este, prin definiție, un canal în timp real între cele două niveluri – exact lucrul pe care separarea este menită să-l prevină. Prezența sau absența unei conectări reușite, momentul reîmprospătărilor de token, chiar și codurile de eroare pot codifica informații peste graniță. Aceeași logică exclude un registru partajat la care ambele părți scriu sau un singur controler GitOps care reconciliază clustere la niveluri diferite. Orice menține o conexiune sincronă peste graniță este un potențial canal ascuns și nu va trece revizuirea.

Izolarea politicilor în cadrul fiecărei enclave

Separarea între enclave este necesară, dar nu suficientă. În cadrul fiecărui cluster ai nevoie în continuare de compartimentare riguroasă, deoarece o enclavă găzduiește multe sarcini de lucru, servicii și echipe care nu ar trebui să se atingă liber. Aici controalele native Kubernetes își câștigă locul.

Începe cu controlul de admitere. Un motor de politici precum Kyverno sau OPA Gatekeeper impune reguli nenegociabile în momentul în care o sarcină de lucru este admisă: doar imaginile semnate din propriul registru al enclavei pot rula; niciun pod nu poate solicita modul privilegiat, rețea de gazdă sau montări de cale de gazdă; fiecare container rulează ca utilizator non-root cu un sistem de fișiere rădăcină doar-citire și un set de capabilități eliminat; și fiecare spațiu de nume îndeplinește profilul restricționat Pod Security Standards. Acestea sunt aceleași controale de întărire tratate în profunzime în întărirea Kubernetes pentru sarcinile de lucru de apărare, aplicate identic în fiecare enclavă astfel încât baza de referință să nu devieze între niveluri.

Rețeaua din interiorul enclavei este de tip refuz implicit. Fiecare spațiu de nume începe cu o NetworkPolicy care elimină tot traficul de intrare și ieșire, iar conectivitatea este acordată explicit per pereche de servicii. Traficul est-vest între compartimente sensibile rulează peste mutual TLS, de obicei printr-un service mesh, astfel încât identitatea unei sarcini de lucru – nu doar poziția sa în rețea – controlează accesul. Cotele de resurse și intervalele de limită împiedică o singură sarcină de lucru compromisă sau care se comportă greșit să înfometeze clusterul.

RBAC și disciplina break-glass

RBAC în cadrul fiecărei enclave urmează cel mai mic privilegiu fără excepție. Operatorii de zi cu zi primesc roluri limitate la spațiul de nume; nimeni nu deține cluster-admin permanent. Capabilitatea cluster-admin trăiește în spatele unei proceduri break-glass: o credențială care este sigilată, a cărei utilizare declanșează o alertă și a cărei fiecare acțiune este înregistrată într-o stocare de audit imuabilă. Deoarece enclavele sunt independente, procedura break-glass este și ea independentă – folosirea ei în enclava Secret nu acordă nimic în cea Unclassified. Conturile de serviciu sunt limitate la un singur spațiu de nume, token-urile lor sunt de scurtă durată și legate de o sarcină de lucru specifică, și niciunul dintre ele nu este reutilizat vreodată între clustere.

Proveniența imaginilor: încredere câștigată la build, verificată la rulare

Într-o arhitectură multi-enclavă, lanțul de aprovizionare este cea mai atractivă suprafață de atac, deoarece o imagine construită o dată pe partea joasă poate ajunge în cele din urmă să ruleze la Top Secret. Fiecare imagine trebuie, prin urmare, să poarte o proveniență verificabilă pe care cea mai înaltă enclavă o poate verifica fără a avea încredere în vreo enclavă inferioară la runtime.

Disciplina este: construiește în cea mai joasă enclavă care poate construi imaginea, generează o listă completă de materiale software (SBOM) în format SPDX sau CycloneDX, scaneaz-o față de o bază de date de vulnerabilități oglindită în acea enclavă și semnează atât imaginea cât și SBOM cu o cheie Sigstore Cosign. Semnătura leagă amprenta imaginii de un proces de build cunoscut. Fiecare enclavă rulează propriul registru – Harbor și zot sunt alegerile comune pentru operarea deconectată – iar controlerul de admitere al fiecărui cluster verifică semnătura Cosign față de o cheie publică specifică enclavei înainte de a permite imaginii să ruleze. O imagine nesemnată, sau una a cărei amprentă nu corespunde înregistrării promovate, nu pornește niciodată.

Acest lucru contează peste graniță deoarece clusterul din partea înaltă nu are încredere în registrul din partea joasă; el are încredere în semnătura criptografică și în amprenta înregistrată în timpul promovării. Chiar dacă registrul din partea joasă ar fi compromis după ce o imagine a fost promovată, partea înaltă ar respinge orice înlocuitor a cărui amprentă diferă de cea pe care a înregistrat-o.

Promovare controlată între domenii

Promovarea este singura modalitate sancționată prin care un artefact trece o graniță de enclavă și este strict de jos în sus. Calea trece printr-o soluție cross-domain acreditată sau, pentru cele mai stricte legături, o diodă de date hardware care permite fizic transferul într-o singură direcție.

Garda de transfer face muncă reală, nu doar o copie. Validează amprenta imaginii și semnătura Cosign față de o listă de permisiuni de artefacte aprobate; inspectează SBOM și respinge orice imagine care conține o componentă interzisă, o licență neaprobată sau un pachet cunoscut ca vulnerabil peste pragul programului; elimină sau normalizează metadatele care ar putea purta date ascunse; și înregistrează transferul cu identitatea operatorului, marca temporală și amprenta artefactului într-o înregistrare de audit pe ambele părți. Doar după ce fiecare verificare trece, artefactul este scris în registrul din partea înaltă, de unde clusterul înalt îl poate trage.

Mișcarea de sus în jos este direcția periculoasă și este tratată în consecință. Tragerea jurnalelor, metricilor sau a telemetriei de build dintr-o enclavă Secret într-una Unclassified este o scurgere potențială, așa că este fie interzisă de-a dreptul, fie direcționată printr-o revizuire separată, mult mai strictă, cu adjudecare umană a fiecărei înregistrări eliberate. Postura implicită este că datele curg în sus și rămân sus.

GitOps și operațiuni fără a trece linia

Fiecare enclavă rulează propriul controler GitOps – Argo CD sau Flux – reconciliând față de un depozit Git care trăiește în cadrul acelei enclave. Manifestele de stare dorită pentru enclava superioară sunt ele însele artefacte care sunt promovate în sus prin soluția cross-domain, revizuite în același mod ca imaginile. Acest lucru păstrează pista de audit (depozitul din partea înaltă înregistrează exact ce a fost promovat și de către cine) fără a conecta vreodată un controler peste graniță.

Observabilitatea urmează aceeași regulă. Falco pentru detectarea amenințărilor la runtime, jurnalul de audit Kubernetes, metricile Prometheus și jurnalele de container centralizate rulează toate în cadrul fiecărei enclave și alimentează un SIEM local enclavei. Telemetria nu curge niciodată în afara unei enclave înalte către un tablou de bord din partea joasă; dacă o imagine operațională fuzionată, inter-nivel este cu adevărat necesară, ea este construită prin exportarea rezumatelor revizuite în sus către cea mai înaltă enclavă, nu prin tragerea telemetriei brute în jos. Retenția de audit este setată per enclavă pentru a îndeplini cerința de acreditare a acelei enclave, iar monitorizarea continuă – rescanări de vulnerabilități față de oglinda intra-enclavă, detectarea derivei, reverificarea periodică a semnăturilor imaginilor – rulează independent în fiecare cluster.

Cât costă acest lucru și de ce merită

Rularea a trei clustere independente în loc de un singur cluster multi-tenant este cu adevărat mai multă muncă: trei planuri de control de patch-uit, trei registre de populat, trei furnizori de identitate, trei conducte GitOps și un proces de promovare între ele. Inginerii simt fricțiunea de fiecare dată când o imagine care funcționează pe partea joasă trebuie promovată înainte de a putea rula mai sus. Dar acea fricțiune este proprietatea de securitate, nu un defect al ei. Poarta de promovare este locul în care proveniența este verificată, componentele interzise sunt prinse și se creează o înregistrare completă, imuabilă a ceea ce a trecut granița. Comprimarea enclavelor într-un singur cluster pentru a economisi efort ar schimba o arhitectură acreditabilă, apărabilă cu un singur kernel partajat și server API stând între Unclassified și Secret – un schimb pe care niciun acreditator nu îl va accepta și pe care niciun program nu ar trebui să-l dorească.

Pentru echipele care trebuie să mențină și enclavele superioare deconectate, modelele operaționale se împerechează natural cu o practică Kubernetes air-gapped: registre offline, dependențe oglindite și o disciplină de upgrade care nu presupune o cale în timp real către lumea exterioară.