1. Air-Gapped K8s -todellisuus

"Air-gapped" tarkoittaa harvoin sitä, mitä markkinointimateriaalit vihjailevat. Luokitellussa käyttöönotossa air-gap on akkreditoitu raja: ei reititettävää polkua julkiseen internetiin, ei DNS-resoluutiota ulospäin, ei implisiittistä ulostuloa paketinhallintajärjestelmille tai konttien suoritusympäristöille. Jokainen raja ylittävä artefakti kirjataan, skannataan ja hyväksytään. Klusteri käyttäytyy kuin internetiä ei olisi — koska akkreditointiviranomaiselle sitä ei ole.

Ensimmäinen todellisuus, jota insinöörit aliarvioivat, on se, että Kubernetes olettaa yhteyden. kubelet vetää registry.k8s.io:sta. Helm-kaaviot viittaavat quay.io:hin ja docker.io:hin. CNI-liitännäiset hakevat binaareja asennuksessa. CSI-ajurit hakevat sivuvaunukuvia. Operaattorit täsmäyttyvät vetämällä uusia kuvan tiivisteitä. Tavallinen kubeadm init katkaistulla isännällä epäonnistuu ensimmäisessä minuutissa.

Toinen todellisuus on toistuvan päivityksen ongelma. Klusteri ei nouse pystyyn kerran ja pysy paikallaan. Kubernetesin vähäiset julkaisut saapuvat joka neljäs kuukausi. CVE-haavoittuvuudet containerdissa, runcissa, CoreDNS:ssä ja kernelissä saapuvat viikoittain. Akkreditointitarkastajat kysyvät yhden kysymyksen kaikkien muiden yläpuolella: näytä korjaustiheys ja todistusketju. Air-gapped-klusteri ilman dokumentoitua, toistettavaa päivitysputkea on klusteri, jolta evätään toimintavaltuutus seuraavassa tarkastuksessa.

Kaikki seuraava on seurausta näistä kahdesta tosiasista: mikään ei vedä itse itseään, ja klusteri on oltava korjattavissa vuosien ajan.

2. Jakelun valinta — RKE2 vs K3s vs kubeadm vs OpenShift

RKE2 (Rancher Kubernetes Engine 2). SUSE/Rancherin kovennettu jakelu. RKE2 1.31 toimittaa CIS-1.9-profiilin heti pakkauksesta: kube-apiserver on konfiguroitu tarkastuskäytännöllä, pääsyohjaimilla ja TLS-asenteella, joita CIS-vertailu vaatii. Julkaisun tarball niputtaa jokaisen järjestelmäkuvan — kube-apiserver, kube-controller-manager, etcd, CoreDNS, CNI (Cilium tai Canal), sisääntuloohjain — yhteen rke2-images-all.linux-amd64.tar.zst:iin. Air-gapille tämä on oikea vastaus 80% ajasta.

K3s. Kevyt sisarus. Yksittäinen binaari, upotettu etcd tai sqlite, ~50 MB. Erinomainen enklaavien sisällä oleville reunasolmuille (etujohtoasemat, mobiilit suojat, anturien yhdyskäytävät), joissa klusteri toimii yhdellä lujatekoisella laitteistolla. K3s 1.31:llä on sama air-gap-tarball-malli kuin RKE2:lla, mutta pienempi komponenttijoukko eikä kovennettua profiilipreset — tuot oman pääsykäytäntösi.

kubeadm. Ylöspäin suunnattu Kubernetes. Maksimaalinen joustavuus, maksimaalinen työ. Jokainen komponenttikuva on peilattava manuaalisesti, jokainen CNI asennettava manuaalisesti, jokainen CIS-ohjaus sovellettava sinun toimestasi. Valitse kubeadm vain, kun akkreditointiviranomainen kieltää toimittajan jakelemat binaarit (harvinainen mutta todellinen joillakin kansallisilla ohjelmilla).

OpenShift. Red Hatin jakelu. Vahvempi air-gap-työkalustus (oc mirror, Operator Lifecycle Manager offline-luetteloilla) ja vakava akkreditointijälki (FIPS 140-3, CC EAL4+ RHEL:llä). Kompromissi on lisensointi — OpenShift-paikkojen hinta on korkea ja alustan jalanjälki raskas. Ohjelmille, joilla on jo Red Hat -yrityssopimukset, tämä on pienimmän vastustuksen tie.

Useimmissa puolustuksen tehtävissä suosittelemme RKE2 1.31:tä Rancher 2.10:n kanssa moniklusteri-hallintatasona, joka sijaitsee luokitellun enklaavissa. K3s 1.31 täyttää reunapaikan. Kubeadm ja OpenShift ovat ohjelmakohtaisia valintoja, joita ohjaavat hankinta ja akkreditointi, ei insinöörillinen mieltymys.

3. Offline-kuvarekisteri

Rekisteri on air-gapped Kubernetes -alustan sydän. Jokainen pod vetää siitä. Jos se kaatuu, klusteri jäätyy seuraavassa kuvanvedossa. Jos se vaarantuu, jokainen työkuorma vaarantuu.

Harbor 2.11. CNCF-valmistunut, yritystason rekisteri. Natiivi Trivy-integrointi skannaa jokaisen työnnetyn kuvan CVE:ille offline-haavoittuvuustietokantaa vasten, jonka synkronoit sisään samalla hyväksytyllä siirtoprosessilla kuin sovelluskuvat. Harbor tukee cosign-allekirjoituksen vahvistusta vedon aikana, projektilaajuista RBAC:ia, replikaatiokäytäntöjä ja robottitilimallia, joka toimii puhtaasti pääsyohjaimen webhookien kanssa. Enklaavissa olevan ensisijaisen rekisterin osalta Harbor on oletus.

zot. OCI-natiivi, golang yksittäinen binaari -rekisteri. Paljon kevyempi kuin Harbor (ei Postgresia, ei Redisiä, ei Trivy-sivuvaunua). zot 2.1 tukee OCI 1.1 -viittaajia, cosignia ja pientä jalanjälkeä, joka sopii etenemissolmuille, joissa Harbor olisi yliprosessoitu. Yhdistä zot reunalla Harborin kanssa keskuspaikalla, replikoiden yksisuuntaisesti.

Sonatype Nexus. Polyglottinen artefaktinhallinta. Jos ohjelma on jo standardoitunut Nexusiin Mavenille, npm:lle ja APT-peileille, Docker-repositorioiden lisääminen pitää kaiken yhdessä työkalussa ja yhdessä tarkastuslokiryhmässä. Nexusin konttiskannaus on heikompaa kuin Harborin, joten se yhdistetään erilliseen skannausporttiiin syöttöputkessa.

Malli, johon useimmat suuret ohjelmat päätyvät, on rekisterien rekisteri: yksi keskusHarbor enklaavissa totuuden lähteenä, yksi zot per sivusto tai reunaklusteri, ja dokumentoitu replikaatiotopologia. Sovellusklustedit eivät koskaan vedä keskusHarborista suoraan — ne vetävät paikallisesta zot-peilistä. Vikadomeenit pysyvät pieninä. Verkon edestakaiset matkat pysyvät lyhyinä. Akkreditointikaavio pysyy piirrettävissä yhdellä sivulla.

4. Sneakernet ja yksisuuntaiset diodelit

Kuvat, Helm-kaaviot, haavoittuvuustietokannat, käyttöjärjestelmäpakettiapeilit, GitOps-repositoriot — kaiken on fyysisesti ylitettävä raja. Kaksi kuljetusmallia hallitsee.

Sneakernet. Hyväksytty irrotettava media, käsin kuljetettu. Media pyyhitään, kirjoitetaan, hash-varmennetaan, sinetöidään, allekirjoitetaan rajan yli, hash-varmennetaan korkean tason puolella, syötetään staging-rekisteriin, skannataan, hyväksytään manuaalisesti, sitten siirretään tuotantorekisteriin. Koko sykli kestää tunteja tai päiviä. Se on hidasta, tarkastettavissa ja selviää mistä tahansa akkreditointitarkastuksesta.

Yksisuuntaiset datadiodelit. Laitteistolla pakotettu yksisuuntainen siirto (Owl Cyber Defense, Fox-IT DataDiode, Advenica). Kaistanleveys on todellinen (1–10 Gbps nykyisellä laitteistolla) ja paluupolun puuttuminen on pakotettu kuidussa, ei konfiguraatiossa. Diodelit toimivat erinomaisesti korkean tason puolelta lähtevään telemtriaan; sisääntuleviin kuviin, kuittauksen puuttuminen monimutkaistaa uudelleenyrityksiä, joten useimmat ohjelmat yhdistävät diodin tiukan uudelleenlähetys-tarkistussummavikaantumisessa -protokollan kanssa.

Molemmat mallit jakavat saman vaiheistetun hyväksynnän työnkulun: vastaanota → karanteenirekisteri → automatisoitu skannaus (Trivy, ClamAV, YARA) → sisällön purkaminen ja uudelleenrakentaminen kaikille ei-kontti-artefakteille → manuaalinen analyytikon hyväksyntä → ylennys tuotantorekisteriin. Karanteenivaiheen ohittaminen on yksittäisin yleisin akkreditointilöydösten syy.

5. GitOps air-gapissa

GitOps toimii enklaavissa — edellyttäen, että jokainen viittaus on sisäinen. ArgoCD 2.13 ja Flux 2.4 molemmat toimivat iloisesti air-gapped-tilassa. Täsmäytyssilmukka ei välitä siitä, että Git-palvelin on Gitea tai GitLab -instanssi korkean tason puolella eikä github.com. Mikä hajoaa on jokainen Helm-kaavio, joka viittaa ulkoiseen kaaviorepositorioon, jokainen Kustomize-overlay, joka vetää perustan julkisesta Git-etäkoneesta, ja jokainen operaattori, joka seuraa ulkoista kuvavirtaa.

Manifestipeilin malli korjaa tämän. Aikataulutettu työ matalan tason puolella vetää ylävirrasta Helm-kaaviot, konttikuvat ja Git-repositoriot; kirjoittaa uudelleen jokaisen ulkoisen viittauksen (repository: docker.io/bitnami/postgresql muuttuu repository: harbor.enclave.mil/bitnami/postgresql); tekee commitin sisäiseen Git-peiliin; ja vie paketin sneakernetille. Enklaavissa ArgoCD osoittaa yksinomaan peiliin. Ei varapolkua internetiin, koska internetiä ei ole.

Ajautumisen havaitseminen ilman phone-home on suoraviivaista — ArgoCD laskee erot klusterin sisäistä tilaa vasten, ei ulkoista palvelua vasten. Ainoa ominaisuus, jonka menetät, on automatisoitu ylävirran ilmoitus uusista kaavioversioista; tämä havaitseminen siirtyy matalan tason peili-työntehtävään, mihin se kuuluikin.

6. Toimitusketjun eheys

Air-gap pysäyttää lähtevän suodattamisen; se ei pysäytä haitallista kuvaa, joka saapui hyväksytyn kanavan kautta. Toimitusketjun eheys on toinen puolustuslinja.

cosign-allekirjoitus. Jokainen tuotantorekisteriin ylennetty kuva allekirjoitetaan cosign-avaimella, jonka juuri sijaitsee enklaavissa olevassa HSM:ssä. Allekirjoitus tapahtuu ylennysvaiheessa, skannauksen ja analyytikon hyväksynnän jälkeen. Allekirjoitus todistaa "tämä kuva on tarkistettu prosessimme kautta," ei "tämä kuva on ylävirrassa autenttinen" — ylävirran alkuperä tarkistetaan erikseen matalan tason syöttöportissa.

Kyverno tai OPA Gatekeeper pääsyssä. ClusterPolicy hylkää minkä tahansa podin, jonka kuvaa ei ole allekirjoitettu avaimella enklaavilla trust-paketissa ja jonka tiivistettä ei ole kiinnitetty. Tageihin perustuvat viittaukset (:latest, :v1) estetään kokonaan — vain @sha256:... -tiivisteet läpäisevät pääsyn. Kyverno 1.13 on kevyempi vaihtoehto; Gatekeeper sopii ohjelmille, jotka ovat jo investoineet Regoon.

SBOM-vahvistus. Jokainen allekirjoitettu kuva kantaa liitettyä SPDX- tai CycloneDX-SBOM:ia OCI-viittaajana. Pääsykäytäntö tarkistaa SBOM-allekirjoituksen ja tarkistaa valinnaisesti kielletyt komponentit (esim. log4j 2.x alle 2.17, mikä tahansa ohjelman kielletylle listalle oleva paketti).

Keskeinen havainto: Enklaavissa olevan HSM:n allekirjoitusavain on koko klusterin luottamusankkuri. Sen avainseremonia, kiertoaikataulu ja jaetun tietämyksen säilytys ovat akkreditointiartefakteja sinänsä. Rakenna ne ennen klusteria, ei sen jälkeen.

7. Päivä 2 -operaatiot

CVE-korjaustiheys on missä useimmat air-gapped-ohjelmat häviävät akkreditointikeskustelun. Tarkastajan kysymys on yksinkertainen: kriittinen CVE paljastui eilen — milloin se laskeutuu tuotantoklusteriisi, ja missä on todiste?

Puolustettava vastaus on kolmitasoinen. Hätäkorjaus kriittisille CVE:ille, joita hyödynnetään aktiivisesti: matalan tason syöttöputki hyväksyy hätäkorjauksen 24 tunnin sisällä, sneakernet toimii syklin ulkopuolella, tuotantorekisteri vastaanottaa korjatun kuvan 72 tunnin sisällä ja hätämuutostietueet kattavat käyttöönoton. Aikataulutettu ikkuna korkean ja keskitason CVE:ille: kuukausittaiset ylläpitoikkunat vetävät kuratoidun erän täydellisen vaiheistetun hyväksynnän putken kautta. Neljännesvuosittaiset vähäiset päivitykset itse Kubernetesin ohjaustasoa varten: RKE2:n korjausjulkaisut laskeutuvat ensin testiclusteriin, sitten tuotantoon, dokumentoidulla palautussuunnitelmalla.

Akkreditointitarkastajia tyydyttävä klusterin elinkaarisuunnitelma ei ole yksisivuinen kaavio. Se on kirjallinen käsikirja, joka kattaa: ohjaustason päivitysmenettely, työntekijäsolmun päivitysmenettely, etcd:n varmuuskopiointi- ja palautusharjoitus (suoritetaan neljännesvuosittain, ei teoreettisesti), CNI-päivitysmenettely, rekisterin replikoinnin vikaantumismenettely ja kunkin vastuulliset nimetyt henkilöt. Tarkastajat lukevat nämä. He huomaavat, kun käsikirja viittaa työkaluun, jota tiimi ei oikeasti käytä.

Laajemmasta pilvarkkitehtuurin kontekstista, jossa nämä klusterit elävät, katso suvereeni pilvarkkitehtuuri puolustukselle.

8. Monienklaavin federaatio

Puolustusorganisaatio ajaa harvoin vain yhtä klusteria. On luokittelematon enklaavi, NATO SECRET -enklaavi, kansallinen SECRET-enklaavi, toisinaan TOP SECRET -enklaavi tietyille ohjelmille. Vaisto on "federoida" ne Kubernetes Federation v2:n tai vastaavan mekanismin kautta. Vaisto on väärässä.

Federaatio luokitusrajojen yli on kielletty jokaisessa akkreditointikehyksessä, jonka alla olemme toimineet. Oikea malli on erilliset klusterit per luokitus, yhdistettynä vain verkkotason yhdyskäytävien kautta. Jokaisella klusterilla on oma ohjaustasonsa, oma rekisterinsä, oma GitOps-repositorionsa, omat allekirjoitusavaimensa. Jaettujen työkuormien manifestit on kopioitu — kyllä, kopioitu, kaikkine versioajautumisriskeineen — koska vaihtoehtona on federoitu ohjaustaso, joka rikkoo rajan.

GitOps-kopiointistrategia on operatiivinen kurinalaisuus, joka tekee tästä hallittavan. Sama matalan tason peili, joka tuottaa luokittelemattoman paketin, tuottaa NATO SECRET -paketin ja kansallisen SECRET-paketin, kumpikin samalla ylävirran sisällöllä, mutta erilliset allekirjoitusavaimet ja erilliset rekisterikohteet. Git-repositoriot eriävät vain enklaavikohtaisessa konfiguraatiossa (rekisterin isäntänimet, verkkokäytännöt, salaisuuksien viitteet). Enklaavien välinen ajautuminen havaitaan matalan tason vertailutyökalulla, joka lukee julkisen puolen manifestit ja diodin kautta palautuvat korkean tason manifestien peitetyt versiot.

Verkkotasoinen viestien kulku — telemetria ylös, komennot alas, tiedustelutieto sivusuunnassa — kulkee akkreditoitujen verkkotason ratkaisujen kautta (Forcepoint Trusted Gateway, Owl, kansalliset vastineet), ei Kubernetes-tason integraation kautta. Klusteri ei tiedä olevansa monienklaaviinen. Jokainen klusteri uskoo olevansa yksin, ja tämä on ominaisuus, joka mahdollistaa sen akkreditoinnin. Verkkomallista, joka ympäröi nämä enklaaavit, katso zero trust sotilasverkoille.