1. Realitatea Kubernetes Air-Gapped

„Air-gapped" înseamnă rareori ce implică materialele de marketing. Într-o desfășurare clasificată, un air gap este o limită acreditată: nicio cale rutabilă spre internetul public, nicio rezoluție DNS externă, nicio ieșire implicită pentru managerii de pachete sau runtime-urile de containere. Fiecare artefact care traversează limita este înregistrat, scanat și aprobat. Clusterul se comportă ca și cum internetul nu există — pentru că pentru autoritatea de acreditare, nu există.

Prima realitate pe care inginerii o subestimeazДѓ este cДѓ Kubernetes presupune conectivitate. kubelet trage din registry.k8s.io. Charturile Helm referenИ›iazДѓ quay.io И™i docker.io. Plugin-urile CNI descarcДѓ binare la instalare. Driverele CSI descarcДѓ imagini sidecar. Operatorii reconciliazДѓ trДѓgГўnd noi digesturi de imagini. Un kubeadm init vanilla pe un host deconectat eИ™ueazДѓ Г®n primul minut.

A doua realitate este problema actualizДѓrilor recurente. Un cluster nu este ridicat o datДѓ И™i rДѓmГўne static. Versiunile minore Kubernetes apar la fiecare patru luni. CVE-urile Г®n containerd, runc, CoreDNS И™i kernel apar sДѓptДѓmГўnal. Revizuitorii de acreditare pun o singurДѓ Г®ntrebare mai presus de toate: aratДѓ-mi cadenИ›a de corecИ›ii И™i traseul de dovezi. Un cluster air-gapped fДѓrДѓ un pipeline de actualizare documentat И™i repetabil este un cluster cДѓruia i se va nega autoritatea de operare la urmДѓtoarea revizuire.

Tot ceea ce urmeazДѓ este o consecinИ›Дѓ a acestor douДѓ fapte: nimic nu se trage singur, iar clusterul trebuie sДѓ fie corectat ani de zile.

2. Alegerea Distribuției — RKE2 vs K3s vs kubeadm vs OpenShift

RKE2 (Rancher Kubernetes Engine 2). Distribuția întărită a SUSE/Rancher. RKE2 1.31 vine cu un profil CIS-1.9 din cutie: kube-apiserver este configurat cu politica de audit, controlerele de admisie și postura TLS pe care standardul CIS o cere. Arhiva tarball a versiunii include fiecare imagine de sistem — kube-apiserver, kube-controller-manager, etcd, CoreDNS, CNI (Cilium sau Canal), controllerul de ingress — într-un singur rke2-images-all.linux-amd64.tar.zst. Pentru air-gap, acesta este răspunsul corect în 80% din cazuri.

K3s. Fratele ușor. Binar unic, etcd integrat sau sqlite, ~50 MB. Excelent pentru nodurile edge din interiorul enclavei (posturi de comandă înaintate, adăposturi mobile, gateway-uri de senzori) unde clusterul rulează pe un singur aparat robust. K3s 1.31 are același tipar de tarball air-gap ca RKE2 dar un set de componente mai mic și niciun profil pre-setat întărit — aduceți propria politică de admisie.

kubeadm. Kubernetes upstream. Flexibilitate maximДѓ, muncДѓ maximДѓ. Fiecare imagine de componentДѓ trebuie oglinditДѓ manual, fiecare CNI instalat manual, fiecare control CIS aplicat de dvs. AlegeИ›i kubeadm doar cГўnd autoritatea de acreditare interzice binarele distribuite de furnizor (rar, dar real Г®n unele programe naИ›ionale).

OpenShift. Distribuția Red Hat. Instrumente mai puternice pentru air-gap (oc mirror, Operator Lifecycle Manager cu cataloage offline) și un amprentament serios de acreditare (FIPS 140-3, CC EAL4+ pe RHEL). Compromisul este licențierea — locurile OpenShift sunt costisitoare și amprentamentul platformei este greu. Pentru programele care au deja acorduri enterprise Red Hat, aceasta este calea de minimă rezistență.

Pentru cele mai multe angajamente de apДѓrare recomandДѓm RKE2 1.31 cu Rancher 2.10 ca plan de management multi-cluster, situat Г®n interiorul enclavei clasificate. K3s 1.31 ocupДѓ slotul edge. Kubeadm И™i OpenShift sunt alegeri specifice programului, conduse de achiziИ›ii И™i acreditare, nu de preferinИ›a de inginerie.

3. Registrul de Imagini Offline

Registrul este inima unei platforme Kubernetes air-gapped. Fiecare pod trage din el. DacДѓ cade, clusterul Г®ngheaИ›Дѓ la urmДѓtoarea tragere de imagini. DacДѓ este compromis, fiecare sarcinДѓ de lucru este compromisДѓ.

Harbor 2.11. Registrul de nivel enterprise, absolvit CNCF. Integrarea nativДѓ Trivy scaneazДѓ fiecare imagine Г®mpinsДѓ pentru CVE-uri faИ›Дѓ de o bazДѓ de date de vulnerabilitДѓИ›i offline pe care o sincronizaИ›i prin acelaИ™i proces de transfer aprobat pe care Г®l folosiИ›i pentru imaginile aplicaИ›iilor. Harbor suportДѓ verificarea semnДѓturii cosign la tragere, RBAC cu scop de proiect, politici de replicare И™i un model de cont robot care funcИ›ioneazДѓ bine cu webhook-urile de admisie. Pentru un registru primar Г®n interiorul enclavei, Harbor este opИ›iunea implicitДѓ.

zot. Registrul nativ OCI, binar unic golang. Mult mai uИ™or decГўt Harbor (fДѓrДѓ Postgres, fДѓrДѓ Redis, fДѓrДѓ sidecar Trivy). zot 2.1 suportДѓ referri OCI 1.1, cosign И™i un amprentament mic care se potriveИ™te nodurilor Г®naintate unde Harbor ar fi supradimensionat. AsociaИ›i zot la margine cu Harbor la situl central, replicГўnd unidirecИ›ional.

Sonatype Nexus. Managerul de artefacte poliglot. DacДѓ programul s-a standardizat deja pe Nexus pentru oglinzile Maven, npm И™i APT, adДѓugarea de depozite Docker pДѓstreazДѓ totul Г®ntr-un singur instrument И™i un singur set de jurnale de audit. Scanarea containerelor Nexus este mai slabДѓ decГўt cea a Harbor, deci se asociazДѓ cu o poartДѓ de scanare separatДѓ Г®n pipeline-ul de ingestie.

Tiparul la care converg cele mai mari programe este registrul de registre: un Harbor central în interiorul enclavei ca sursă de adevăr, un zot per sit sau cluster edge, și o topologie de replicare documentată. Clusterele de aplicații nu trag niciodată direct din Harbor-ul central — trag din oglinda zot locală. Domeniile de eșec rămân mici. Rutele de rețea rămân scurte. Diagrama de acreditare rămâne desenabilă pe o singură pagină.

4. Sneakernet И™i Diode UnidirecИ›ionale

Imagini, charturi Helm, baze de date de vulnerabilități, oglinzi de pachete OS, depozite GitOps — totul trebuie să traverseze fizic limita. Două tipare de transport domină.

Sneakernet. Medii amovibile aprobate, purtate manual. Mediul este И™ters, scris, verificat prin hash, sigilat, semnat la traversarea limitei, verificat prin hash pe partea Г®naltДѓ, ingerat Г®ntr-un registru de staging, scanat, aprobat manual, apoi promovat la registrul de producИ›ie. Ciclul complet dureazДѓ ore pГўnДѓ la zile. Este lent, auditabil И™i supravieИ›uieИ™te oricДѓrei revizuiri de acreditare.

Diode de date unidirecționale. Transfer unidirecțional impus hardware (Owl Cyber Defense, Fox-IT DataDiode, Advenica). Lățimea de bandă este reală (1–10 Gbps pe hardware-ul curent) iar lipsa unei căi de retur este impusă în fibră, nu în configurație. Diodele funcționează excelent pentru telemetria care iese din partea înaltă; pentru imaginile care intră, absența confirmărilor complică reîncercările, deci cele mai multe programe asociază o diodă cu un protocol strict de retrimis-la-eșec-de-sumă-de-control stratificat deasupra.

Ambele tipare partajeazДѓ acelaИ™i flux de lucru de acceptare etapizatДѓ: primire в†’ registru de carantinДѓ в†’ scanare automatДѓ (Trivy, ClamAV, YARA) в†’ dezarmarea И™i reconstrucИ›ia conИ›inutului pentru orice artefact non-container в†’ aprobarea manualДѓ a analistului в†’ promovare la registrul de producИ›ie. Omiterea etapei de carantinДѓ este cauza cea mai frecventДѓ a constatДѓrilor de acreditare.

5. GitOps Г®ntr-un Air Gap

GitOps funcționează în interiorul enclavei — cu condiția ca fiecare referință să fie internă. ArgoCD 2.13 și Flux 2.4 rulează ambele fericite în air-gap. Bucla de reconciliere nu îi pasă că serverul Git este o instanță Gitea sau GitLab găzduită pe partea înaltă mai degrabă decât github.com. Ceea ce se strică este fiecare chart Helm care referențiază un depozit de charturi extern, fiecare overlay Kustomize care trage o bază dintr-un remote Git public, și fiecare operator care urmărește un flux extern de imagini.

Tiparul oglindДѓ de manifeste rezolvДѓ aceasta. Un job planificat pe partea joasДѓ trage charturile Helm upstream, imaginile de containere И™i depozitele Git; rescrie fiecare referinИ›Дѓ externДѓ (repository: docker.io/bitnami/postgresql devine repository: harbor.enclave.mil/bitnami/postgresql); face commit la o oglindДѓ Git internДѓ; И™i exportДѓ bundle-ul pentru sneakernet. ГЋn interiorul enclavei, ArgoCD indicДѓ exclusiv la oglindДѓ. Nu existДѓ o cale de rezervДѓ spre internet pentru cДѓ nu existДѓ internet.

Detectarea derivei fără phone-home este simplă — ArgoCD calculează diferențele față de starea din cluster, nu față de un serviciu extern. Singura caracteristică pe care o pierdeți este notificarea automată upstream despre noile versiuni de charturi; acea detectare se mută la job-ul oglindă de pe partea joasă, unde oricum ar fi trebuit să fie.

6. Integritatea LanИ›ului de Aprovizionare

Un air gap opreИ™te exfiltrarea externДѓ; nu opreИ™te o imagine maliИ›ioasДѓ care a sosit prin canalul aprobat. Integritatea lanИ›ului de aprovizionare este a doua linie de apДѓrare.

Semnarea cosign. Fiecare imagine promovată la registrul de producție este semnată cu o cheie cosign al cărei root se află în HSM-ul enclavei. Semnarea are loc la pasul de promovare, după scanare și aprobarea analistului. Semnătura atestă „această imagine a fost verificată prin procesul nostru," nu „această imagine este autentică upstream" — proveniența upstream este verificată separat la poarta de ingestie de pe partea joasă.

Kyverno sau OPA Gatekeeper la admisie. O ClusterPolicy respinge orice pod a cărui imagine nu este semnată de o cheie din bundle-ul de încredere al enclavei și al cărui digest nu este fixat. Referințele bazate pe tag (:latest, :v1) sunt blocate complet — doar digesturile @sha256:... trec admisia. Kyverno 1.13 este alegerea mai ușoară; Gatekeeper se potrivește programelor deja investite în Rego.

Verificarea SBOM. Fiecare imagine semnatДѓ poartДѓ un SBOM SPDX sau CycloneDX ataИ™at ca referitor OCI. Politica de admisie verificДѓ semnДѓtura SBOM И™i opИ›ional verificДѓ componentele interzise (ex. log4j 2.x sub 2.17, orice pachet din lista interzisДѓ a programului).

InformaИ›ie cheie: Cheia de semnare din HSM-ul enclavei este ancora de Г®ncredere pentru Г®ntregul cluster. Ceremonia sa de chei, programul de rotaИ›ie И™i custodia cu cunoaИ™tere divizatДѓ sunt artefacte de acreditare Г®n sine. ConstruiИ›i-le Г®nainte de cluster, nu dupДѓ.

7. OperaИ›iuni Ziua 2

Cadența de corecție CVE este locul unde cele mai multe programe air-gapped pierd conversația de acreditare. Întrebarea revizuitorului este simplă: un CVE critic a fost dezvăluit ieri — când ajunge în clusterul dvs. de producție, și unde este dovada?

Un rДѓspuns apДѓrabil are trei niveluri. CorecИ›ie rapidДѓ pentru CVE-uri critice cu exploatare activДѓ: pipeline-ul de ingestie de pe partea joasДѓ acceptДѓ un patch de urgenИ›Дѓ Г®n 24 de ore, sneakernet ruleazДѓ Г®n afara ciclului, registrul de producИ›ie primeИ™te imaginea corectatДѓ Г®n 72 de ore, iar recordurile de modificare de urgenИ›Дѓ acoperДѓ desfДѓИ™urarea. FereastrДѓ planificatДѓ pentru CVE-uri Г®nalte И™i medii: ferestrele lunare de Г®ntreИ›inere trag un lot curatizat prin pipeline-ul complet de acceptare etapizatДѓ. ActualizДѓri minore trimestriale pentru planul de control Kubernetes Г®nsuИ™i: lansДѓrile de corecИ›ie RKE2 ajung mai Г®ntГўi Г®ntr-un cluster de test, apoi producИ›ie, cu un plan documentat de rollback.

Planul de ciclu de viaИ›Дѓ al clusterului care satisface revizuitorii de acreditare nu este o diagramДѓ de o paginДѓ. Este un runbook scris care acoperДѓ: procedura de upgrade a planului de control, procedura de upgrade a nodului worker, exerciИ›iul de backup И™i restaurare etcd (executat trimestrial, nu teoretic), procedura de upgrade CNI, procedura de eИ™ec al replicДѓrii registrului, И™i persoanele nominalizate responsabile pentru fiecare. Revizuitorii citesc acestea. ObservДѓ cГўnd runbook-ul referenИ›iazДѓ un instrument pe care echipa nu Г®l foloseИ™te de fapt.

8. FederaИ›ia Multi-EnclavДѓ

O organizație de apărare rareori rulează un singur cluster. Există o enclavă neclasificată, o enclavă NATO SECRET, o enclavă SECRET națională, ocazional o enclavă TOP SECRET pentru programe specifice. Instinctul este de a le „federa" prin Kubernetes Federation v2 sau un mecanism similar. Instinctul este greșit.

Federarea peste limitele de clasificare este interzisă de fiecare cadru de acreditare sub care am lucrat. Tiparul corect este clustere separate per clasificare, legate doar prin gateway-uri cross-domain. Fiecare cluster are propriul plan de control, propriul registru, propriul depozit GitOps, propriile chei de semnare. Manifestele pentru sarcinile de lucru partajate sunt duplicate — da, duplicate, cu tot riscul de derivă a versiunii pe care îl implică — pentru că alternativa este un plan de control federat care încalcă limita.

Strategia de duplicare GitOps este disciplina operaИ›ionalДѓ care face acest lucru gestionabil. AceeaИ™i oglindДѓ de pe partea joasДѓ care produce bundle-ul neclasificat produce un bundle NATO SECRET И™i un bundle SECRET naИ›ional, fiecare cu acelaИ™i conИ›inut upstream dar chei de semnare distincte И™i destinaИ›ii de registru distincte. Depozitele Git diverg doar la configuraИ›ia specificДѓ enclavei (nume de hosturi de registru, politici de reИ›ea, referinИ›e la secrete). Deriva Г®ntre enclave este detectatДѓ de un instrument de comparare de pe partea joasДѓ care citeИ™te manifestele de pe partea publicДѓ И™i versiunile redactate ale manifestelor de pe partea Г®naltДѓ care vin Г®napoi prin diodДѓ.

Fluxul de mesaje cross-domain — telemetrie în sus, comenzi în jos, informații lateral — rulează prin soluții cross-domain acreditate (Forcepoint Trusted Gateway, Owl, echivalente naționale), nu prin integrare la nivel Kubernetes. Clusterul nu știe că este multi-enclavă. Fiecare cluster crede că este singur, și aceasta este proprietatea care îi permite să fie acreditat.