Air-gapped Kubernetes dla zadań niejawnych: RKE2, Rancher i realia rejestru offline

1. Realia K8s odciętego od sieci

„Air-gapped” rzadko oznacza to, co sugerują materiały marketingowe. We wdrożeniu niejawnym przerwa powietrzna to akredytowana granica: brak trasowalnej ścieżki do publicznego Internetu, brak rozwiązywania DNS na zewnątrz, brak domyślnego wyjścia dla menedżerów pakietów lub środowisk uruchomieniowych kontenerów. Każdy artefakt przekraczający granicę jest logowany, skanowany i zatwierdzany. Klaster zachowuje się tak, jakby Internet nie istniał — bo dla organu akredytującego on nie istnieje.

Pierwsza rzeczywistość, którą inżynierowie niedoceniają, jest taka, że Kubernetes zakłada łączność. kubelet pobiera z registry.k8s.io. Helm charts odwołują się do quay.io i docker.io. Wtyczki CNI pobierają binarne pliki przy instalacji. Sterowniki CSI ściągają obrazy sidecar. Operatory uzgadniają się, pobierając nowe digesty obrazów. Goły kubeadm init na hoście bez łączności zawodzi w pierwszej minucie.

Druga rzeczywistość to problem powtarzających się aktualizacji. Klaster nie powstaje raz i nie stoi nieruchomo. Wydania minor Kubernetesa pojawiają się co cztery miesiące. CVE w containerd, runc, CoreDNS i jądrze pojawiają się co tydzień. Recenzenci akredytacji zadają jedno pytanie ponad wszystkimi innymi: pokażcie kadencję łatania i ślad dowodowy. Klaster air-gapped bez udokumentowanego, powtarzalnego potoku aktualizacji to klaster, który przy najbliższym przeglądzie nie dostanie zgody na działanie.

Wszystko, co następuje, jest konsekwencją tych dwóch faktów: nic nie pobiera się samo, a klaster musi być łatany przez lata.

2. Wybór dystrybucji — RKE2 vs K3s vs kubeadm vs OpenShift

RKE2 (Rancher Kubernetes Engine 2). Utwardzona dystrybucja SUSE/Rancher. RKE2 1.31 dostarcza profil CIS-1.9 od razu po wyjęciu z pudełka: kube-apiserver jest skonfigurowany z polityką audytu, kontrolerami admisji i ustawieniami TLS, których wymaga benchmark CIS. Archiwum wydania pakuje każdy obraz systemowy — kube-apiserver, kube-controller-manager, etcd, CoreDNS, CNI (Cilium lub Canal), kontroler ingress — w jeden rke2-images-all.linux-amd64.tar.zst. Dla air-gap to właściwa odpowiedź w 80% przypadków.

K3s. Lekkie rodzeństwo. Pojedyncze binarium, osadzony etcd lub sqlite, ~50 MB. Doskonały dla węzłów edge wewnątrz enklawy (wysunięte stanowiska dowodzenia, mobilne kontenery, bramy sensoryczne), gdzie klaster działa na jednym wzmocnionym urządzeniu. K3s 1.31 ma ten sam wzorzec tarballa air-gap co RKE2, ale mniejszy zestaw komponentów i brak gotowego profilu utwardzenia — politykę admisji przynosisz własną.

kubeadm. Upstreamowy Kubernetes. Maksymalna elastyczność, maksymalna praca. Każdy obraz komponentu musi być przekopiowany ręcznie, każdy CNI zainstalowany ręcznie, każda kontrola CIS zastosowana przez ciebie. Wybierz kubeadm tylko wtedy, gdy organ akredytujący zabrania binariów dostarczanych przez dostawcę (rzadkie, ale realne w niektórych programach narodowych).

OpenShift. Dystrybucja Red Hata. Silniejsze narzędzia air-gap (oc mirror, Operator Lifecycle Manager z katalogami offline) i poważny ślad akredytacyjny (FIPS 140-3, CC EAL4+ na RHEL). Kompromis to licencjonowanie — miejsca OpenShift są drogie, a ślad platformy ciężki. Dla programów już posiadających umowy enterprise z Red Hatem to ścieżka najmniejszego oporu.

Dla większości wdrożeń obronnych rekomendujemy RKE2 1.31 z Rancher 2.10 jako płaszczyzną zarządzania wieloklastrowego, mieszczącą się wewnątrz enklawy niejawnej. K3s 1.31 wypełnia gniazdo edge. Kubeadm i OpenShift to wybory specyficzne dla programu, sterowane procurementem i akredytacją, a nie preferencją inżynierską.

3. Rejestr obrazów offline

Rejestr jest sercem platformy Kubernetes air-gapped. Każdy pod z niego pobiera. Jeśli padnie, klaster zamarza na pierwszej kolejnej próbie pobrania obrazu. Jeśli zostanie skompromitowany, każde obciążenie zostaje skompromitowane.

Harbor 2.11. Rejestr klasy enterprise z dyplomem CNCF. Natywna integracja z Trivy skanuje każdy wepchnięty obraz pod kątem CVE wobec offline'owej bazy podatności, którą synchronizujesz tym samym zatwierdzonym procesem transferu, co obrazy aplikacji. Harbor obsługuje weryfikację podpisów cosign przy pobieraniu, RBAC w zakresie projektu, polityki replikacji oraz model kont robotowych, który czysto współpracuje z webhookami admisji. Dla głównego rejestru wewnątrz enklawy Harbor jest wyborem domyślnym.

zot. Rejestr natywnie OCI, w jednym binarium golang. Znacznie lżejszy niż Harbor (bez Postgresa, bez Redisa, bez sidecara Trivy). zot 2.1 obsługuje OCI 1.1 referrers, cosign oraz mały ślad pasujący do węzłów wysuniętych, gdzie Harbor byłby przewymiarowany. Spinaj zot na brzegu z Harborem w miejscu centralnym, replikując jednokierunkowo.

Sonatype Nexus. Polyglotowy menedżer artefaktów. Jeśli program już ustandaryzował Nexus dla Mavena, npm i mirrorów APT, dodanie repozytoriów Dockera trzyma wszystko w jednym narzędziu i jednym zestawie logów audytu. Skanowanie kontenerów w Nexusie jest słabsze niż w Harborze, więc parowane jest z osobną bramą skanującą w potoku przyjęcia.

Wzorzec, do którego zbiega większość dużych programów, to rejestr rejestrów: jeden centralny Harbor wewnątrz enklawy jako źródło prawdy, jeden zot na lokalizację lub klaster edge oraz udokumentowana topologia replikacji. Klastry aplikacyjne nigdy nie pobierają z centralnego Harbora bezpośrednio — pobierają z lokalnego mirroru zot. Domeny awarii pozostają małe. Rundy sieciowe pozostają krótkie. Diagram akredytacyjny pozostaje rysowalny na jednej stronie.

4. Sneakernet i diody jednokierunkowe

Obrazy, Helm charts, bazy podatności, mirrory pakietów OS, repozytoria GitOps — wszystko musi fizycznie przekroczyć granicę. Dominują dwa wzorce transportu.

Sneakernet. Zatwierdzone nośniki wymienne, przenoszone ręcznie. Nośnik jest czyszczony, zapisywany, weryfikowany skrótem, zapieczętowany, podpisany na granicy, weryfikowany skrótem po stronie wysokiej, przyjmowany do rejestru staging, skanowany, ręcznie zatwierdzany, a następnie promowany do rejestru produkcyjnego. Pełny cykl trwa godziny do dni. Jest wolny, audytowalny i przeżywa każdy przegląd akredytacyjny.

Diody danych jednokierunkowe. Sprzętowo wymuszony transfer jednokierunkowy (Owl Cyber Defense, Fox-IT DataDiode, Advenica). Przepustowość jest realna (1–10 Gb/s na obecnym sprzęcie), a brak ścieżki powrotnej jest wymuszany we włóknie, nie w konfiguracji. Diody działają znakomicie dla telemetrii wychodzącej ze strony wysokiej; dla obrazów wchodzących brak potwierdzenia komplikuje retry, więc większość programów paruje diodę z rygorystycznym protokołem wznowienia przy niezgodności sumy kontrolnej na wierzchu.

Oba wzorce mają ten sam przepływ stagowanego przyjęcia: odbiór → rejestr kwarantanny → automatyczne skanowanie (Trivy, ClamAV, YARA) → content disarm and reconstruction dla każdego nie-kontenerowego artefaktu → ręczne zatwierdzenie analityka → promocja do rejestru produkcyjnego. Pominięcie etapu kwarantanny to najczęstsza pojedyncza przyczyna uchybień akredytacyjnych.

5. GitOps w przerwie powietrznej

GitOps działa wewnątrz enklawy — pod warunkiem, że każda referencja jest wewnętrzna. ArgoCD 2.13 i Flux 2.4 oba działają szczęśliwie air-gapped. Pętla uzgadniania nie dba o to, że serwer Git to instancja Gitea lub GitLab postawiona po stronie wysokiej, a nie github.com. Pęka natomiast każdy Helm chart, który odwołuje się do zewnętrznego repozytorium chartów, każda nakładka Kustomize, która pobiera bazę ze zdalnego publicznego Gita, oraz każdy operator obserwujący zewnętrzny strumień obrazów.

Wzorzec mirroru manifestów to naprawia. Zaplanowane zadanie po stronie niskiej pobiera upstreamowe Helm charts, obrazy kontenerów i repozytoria Git; przepisuje każdą zewnętrzną referencję (repository: docker.io/bitnami/postgresql staje się repository: harbor.enclave.mil/bitnami/postgresql); commituje do wewnętrznego mirroru Git; i eksportuje paczkę dla sneakernetu. Wewnątrz enklawy ArgoCD wskazuje wyłącznie na mirror. Nie ma ścieżki awaryjnej do Internetu, ponieważ nie ma Internetu.

Wykrywanie dryfu bez phone-home jest proste — ArgoCD liczy diffy względem stanu w klastrze, a nie względem usługi zewnętrznej. Jedyna funkcjonalność, którą tracisz, to automatyczne powiadomienie upstream o nowych wersjach chartu; to wykrywanie przenosi się do zadania mirroru po stronie niskiej, gdzie i tak należało. Dla szerszego wzorca zobacz nasz przewodnik o DevSecOps i zero trust w potoku obronnym.

6. Integralność łańcucha dostaw

Przerwa powietrzna zatrzymuje eksfiltrację wychodzącą; nie zatrzymuje złośliwego obrazu, który dotarł zatwierdzonym kanałem. Integralność łańcucha dostaw to druga linia obrony.

Podpisywanie cosign. Każdy obraz wypromowany do rejestru produkcyjnego jest podpisywany kluczem cosign, którego korzeń siedzi w HSM enklawy. Podpisanie zachodzi na kroku promocji, po skanowaniu i zatwierdzeniu przez analityka. Podpis poświadcza „ten obraz przeszedł nasz proces”, a nie „ten obraz jest upstreamowo autentyczny” — pochodzenie upstream weryfikowane jest osobno na bramie przyjęcia po stronie niskiej.

Kyverno lub OPA Gatekeeper przy admisji. ClusterPolicy odrzuca każdy pod, którego obraz nie jest podpisany kluczem z trust bundle enklawy i którego digest nie jest przypięty. Referencje oparte na tagach (:latest, :v1) są blokowane wprost — przez admisję przechodzą tylko digesty @sha256:.... Kyverno 1.13 to lżejszy wybór; Gatekeeper pasuje do programów już zainwestowanych w Rego.

Weryfikacja SBOM. Każdy podpisany obraz niesie dołączony SBOM SPDX lub CycloneDX jako OCI referrer. Polityka admisji weryfikuje podpis SBOM i opcjonalnie sprawdza komponenty zakazane (np. log4j 2.x poniżej 2.17, dowolny pakiet z listy zakazanej programu). Dla szerszego obrazu zobacz egzekwowanie SBOM w obronnych potokach.

7. Operacje Day-2

Kadencja łatania CVE to miejsce, gdzie większość programów air-gapped przegrywa rozmowę akredytacyjną. Pytanie recenzenta jest proste: krytyczny CVE został ujawniony wczoraj — kiedy ląduje w klastrze produkcyjnym i gdzie są dowody?

Obronna odpowiedź ma trzy poziomy. Hot-fix dla krytycznych CVE z aktywną eksploatacją: potok przyjęcia po stronie niskiej akceptuje awaryjną łatkę w 24 godziny, sneakernet rusza poza cyklem, rejestr produkcyjny otrzymuje załataną wersję obrazu w 72 godziny, a zapisy zmian awaryjnych pokrywają wdrożenie. Okno harmonogramowe dla CVE wysokich i średnich: comiesięczne okna serwisowe przeciągają wyselekcjonowaną partię przez pełny potok stagowanego przyjęcia. Kwartalne aktualizacje minor samej płaszczyzny sterowania Kubernetes: wydania patch RKE2 lądują najpierw w klastrze testowym, potem produkcyjnym, z udokumentowanym planem rollback.

Plan cyklu życia klastra, który zadowala recenzentów akredytacji, nie jest jednostronicowym diagramem. To pisany runbook obejmujący: procedurę aktualizacji control-plane, procedurę aktualizacji węzłów roboczych, próbę backupu i restore etcd (wykonaną kwartalnie, nie teoretyczną), procedurę aktualizacji CNI, procedurę awarii replikacji rejestru oraz nazwiska osób odpowiedzialnych za każdy z punktów. Recenzenci to czytają. Zauważają, kiedy runbook odwołuje się do narzędzia, którego zespół faktycznie nie używa.

Dla szerszego kontekstu architektury chmurowej, w którym te klastry żyją, zobacz architekturę chmury suwerennej dla obronności.

8. Federacja wielu enklaw

Organizacja obronna rzadko prowadzi jeden klaster. Jest enklawa jawna, enklawa NATO SECRET, narodowa enklawa SECRET, czasem TOP SECRET dla konkretnych programów. Instynkt podpowiada „sfederować” je przez Kubernetes Federation v2 albo podobny mechanizm. Instynkt jest błędny.

Federacja przekraczająca granice klauzul jest zakazana w każdym znanym nam frameworku akredytacyjnym. Właściwy wzorzec to oddzielne klastry per klauzula, połączone wyłącznie bramami cross-domain. Każdy klaster ma własną płaszczyznę sterowania, własny rejestr, własne repozytorium GitOps, własne klucze podpisujące. Manifesty dla współdzielonych obciążeń są duplikowane — tak, duplikowane, ze wszystkimi wynikającymi z tego ryzykami dryfu wersji — ponieważ alternatywa to sfederowana płaszczyzna sterowania, która łamie granicę.

Strategia duplikacji GitOps to dyscyplina operacyjna, która czyni to zarządzalnym. Ten sam mirror po stronie niskiej, który produkuje paczkę jawną, produkuje paczkę NATO SECRET i paczkę narodowego SECRET, każda z tą samą zawartością upstream, ale odrębnymi kluczami podpisującymi i odrębnymi miejscami docelowymi rejestrów. Repozytoria Git rozchodzą się tylko w konfiguracji specyficznej dla enklawy (nazwy hostów rejestrów, polityki sieciowe, odwołania do sekretów). Dryf między enklawami wykrywa narzędzie porównawcze po stronie niskiej, które czyta manifesty po stronie publicznej i zredagowane wersje manifestów ze strony wysokiej wracające przez diodę.

Przepływ komunikatów cross-domain — telemetria w górę, komendy w dół, wywiad bokiem — odbywa się przez akredytowane rozwiązania cross-domain (Forcepoint Trusted Gateway, Owl, krajowe odpowiedniki), a nie przez integrację na poziomie Kubernetes. Klaster nie wie, że jest wielo-enklawowy. Każdy klaster wierzy, że jest sam, i to jest właściwość, która pozwala go akredytować. Dla modelu sieci, który otacza te enklawy, zobacz zero trust w sieciach wojskowych.