Kubernetes turvallisuusenklaavien välillä: monitasoluokitellut klusterit

Puolustusohjelmat toimivat harvoin yhdellä luokitustasolla. Sama tehtäväohjelmisto, joka käsittelee avoimen lähteen syötteitä Unclassified-enklaavissa, omaa usein Secret-variantin, joka yhdistää sen arkaluonteiseen keräykseen, ja joskus vielä Top Secret -variantin sen päällä. Kaupalliseen Kubernetesiin tottuneen insinöörin vaisto on mallintaa nämä tasot nimiavaruuksina, vuokralaisina tai virtuaaliklustereina yhden alustan sisällä. Tuo vaisto on väärä luokitellulle työlle, ja sen tekeminen väärin on kallista korjata. Monitasoturvallisessa (MLS) ympäristössä Kubernetes-klusteri – ja verkko, jolla se sijaitsee – on luokitusraja, ei sen sisäinen vuokralaisuuden yksityiskohta. Tämä artikkeli käy läpi, kuinka ajaa Kubernetesia turvallisuusenklaavien välillä: yksi akkreditoitu klusteri per luokitustaso, tiukka käytäntöeristys kunkin sisällä, todennettava levykuvien alkuperä ja artefaktien valvottu, yksisuuntainen ylennys domainien välillä.

Raja on klusteri, ei nimiavaruus

Kubernetes antaa useita mekanismeja, jotka näyttävät eristykseltä: nimiavaruudet, NetworkPolicyt, RBAC, resurssikiintiöt ja pääsynvalvonta. Jokainen niistä on vuokralaishallinnan kontrolli, joka toimii yhden luottamusrajan sisällä. Ne kaikki jakavat saman API-palvelimen, saman etcd-tietovaraston, saman Linux-ytimen kullakin solmulla ja saman konttiajoympäristön. Konttipakko ydinhaavoittuvuuden kautta, vika API-palvelimen valtuutuspolussa tai yksittäinen liian laaja ClusterRoleBinding voi ylittää jokaisen näistä pehmeistä rajoista kerralla.

Akkreditoija, joka tarkastelee MLS-järjestelmää, esittää yksinkertaisen kysymyksen: mikä fyysisesti tai kryptografisesti estää Secret-tietoa pääsemästä Unclassified-puolelle? "NetworkPolicy" ei ole hyväksyttävä vastaus, koska NetworkPolicyn pakottaa sama CNI-laajennus ja ydin, jolla työkuormat itse toimivat. Hyväksytty vastaus on erottelu: erilliset klusterit, erilliset verkot, erilliset laitteistot tai erilliset kryptografisesti eristetyt osiot, kukin akkreditoituna käsittelemään täsmälleen yhtä tasoa. Nimiavaruudet pysyvät hyödyllisinä – mutta vain hallinnollisina lokeroina yhden enklaavin sisällä, ei koskaan rajana Unclassified- ja Secret-tasojen välillä.

Tämä on sama periaate, joka on puolustuksen cross-domain-ratkaisujen taustalla: data liikkuu tasojen välillä vain akkreditoidun vahdin kautta, ei koskaan jaetun ohjelmistokontrollin kautta, jonka molemmat puolet voivat saavuttaa. Monienklaavinen Kubernetes yksinkertaisesti soveltaa tuota periaatetta orkestrointikerrokseen.

Yksi klusteri per enklaavi: viitetopologia

Kolmitasoisen ohjelman viitetopologia on kolme täysin itsenäistä Kubernetes-käyttöönottoa, yksi per enklaavi:

Unclassified- / kehitysenklaavi. Tässä tapahtuu suurin osa insinöörityöstä. Sillä on laajin yhteys (usein polku internetiin välityspalvelimen kautta ylävirran riippuvuuksien vetämiseksi), sallivin muutostahti ja rakennusputki, joka tuottaa artefaktit, joita korkeammat enklaavit lopulta kuluttavat. Se on silti kovennettu – oletuskielto-verkotus, allekirjoitetut levykuvat, ei etuoikeutettuja podeja – mutta se on ainoa enklaavi, jossa uudet levykuvat syntyvät.

Secret-enklaavi. Irti julkisesta internetistä, tämä klusteri ajaa tehtäväohjelmiston Secret-varianttia. Se vetää levykuvia vain omasta enklaavinsisäisestä rekisteristään, joka täytetään yksinomaan alhaalta tapahtuvalla ylennyksellä. Sen muutostahti on hitaampi ja jokainen käyttöönotto on sidottu akkreditoituun julkaisuun. Operatiivinen kuri täällä muistuttaa ilmavälisen Kubernetes-käyttöönoton kuria – offline-rekisterit, ei eläviä ylävirtavetoja ja päivitysprosessi, jonka on selvittävä akkreditoinnista.

Top Secret -enklaavi. Rajoitetuin klusteri, eristetyimmässä verkossa, tiukimmilla henkilöstö- ja fyysisillä kontrolleilla. Se vastaanottaa kuratoidun osajoukon artefakteja Secret-puolelta, jälleen vain akkreditoidun siirron kautta.

Kukin enklaavi on täydellinen, itseriittoinen Kubernetes-universumi: oma hallintatasonsa ja etcd, oma CNI ja tallennusluokkansa, oma levykuvarekisterinsä, oma identiteetintarjoajansa ja RBAC, oma GitOps-ohjaimensa ja oma havainnoitavuuspinonsa. Mikään korkeammassa enklaavissa ei riipu matalamman enklaavin palvelun saavutettavuudesta ajonaikana. Tuo itsenäisyys on se, mikä antaa kunkin klusterin tulla akkreditoiduksi omilla ehdoillaan.

Miksi federointi tasojen välillä on peitelty kanava

Houkutteleva oikopolku on federoida identiteetti, levykuvien jakelu tai GitOps enklaavien välillä, jotta operaattoreilla on yksi konsoli. Vastusta sitä. Elävä todennusfederaatio, joka myöntää tokenin, joka on käytettävissä sekä Unclassified- että Secret-puolella, on määritelmän mukaan reaaliaikainen kanava kahden tason välillä – juuri se asia, jonka erottelu on tarkoitettu estämään. Onnistuneen kirjautumisen läsnäolo tai poissaolo, tokenin uusimisen ajoitus, jopa virhekoodit voivat koodata tietoa rajan yli. Sama logiikka sulkee pois jaetun rekisterin, johon molemmat puolet kirjoittavat, tai yksittäisen GitOps-ohjaimen, joka sovittaa klustereita eri tasoilla. Mikä tahansa, joka ylläpitää synkronista yhteyttä rajan yli, on mahdollinen peitelty kanava eikä läpäise tarkastusta.

Käytäntöeristys kunkin enklaavin sisällä

Erottelu enklaavien välillä on välttämätöntä mutta ei riittävää. Kunkin klusterin sisällä tarvitaan silti tiukka lokerointi, koska enklaavi isännöi monia työkuormia, palveluita ja tiimejä, joiden ei pitäisi vapaasti saavuttaa toisiaan. Tässä Kubernetes-natiivit kontrollit ansaitsevat paikkansa.

Aloita pääsynvalvonnasta. Käytäntömoottori, kuten Kyverno tai OPA Gatekeeper, pakottaa neuvottelemattomat säännöt sillä hetkellä, kun työkuorma otetaan vastaan: vain allekirjoitetut levykuvat enklaavin omasta rekisteristä saavat toimia; mikään pod ei saa pyytää etuoikeutettua tilaa, isäntäverkotusta tai isäntäpolkukiinnityksiä; jokainen kontti toimii non-root-käyttäjänä vain luku -juuritiedostojärjestelmällä ja pudotetulla oikeusjoukolla; ja jokainen nimiavaruus täyttää Pod Security Standards -rajoitetun profiilin. Nämä ovat samat koventamiskontrollit, jotka käsitellään syvällisesti artikkelissa Kubernetesin koventaminen puolustustyökuormille, sovellettuina identtisesti kussakin enklaavissa siten, ettei perustaso ajaudu erilleen tasojen välillä.

Verkotus enklaavin sisällä on oletuskielto. Jokainen nimiavaruus alkaa NetworkPolicyllä, joka pudottaa kaiken sisään- ja ulosliikenteen, ja yhteys myönnetään nimenomaisesti palvelupareittain. Itä-länsi-liikenne arkaluonteisten lokeroiden välillä kulkee keskinäisen TLS:n kautta, tyypillisesti palveluverkon kautta, niin että työkuorman identiteetti – ei vain sen verkkosijainti – portittaa pääsyn. Resurssikiintiöt ja rajavälit estävät yksittäistä vaarantunutta tai väärin käyttäytyvää työkuormaa näännyttämästä klusteria.

RBAC ja break-glass-kuri

RBAC kunkin enklaavin sisällä noudattaa vähimmän oikeuden periaatetta poikkeuksetta. Päivittäiset operaattorit saavat nimiavaruusrajatut roolit; kenelläkään ei ole pysyvää cluster-adminia. Cluster-admin-ominaisuus elää break-glass-menettelyn takana: tunnus, joka on sinetöity, jonka käyttö laukaisee hälytyksen ja jonka jokainen toimi kirjataan muuttumattomaan auditsäilytykseen. Koska enklaavit ovat itsenäisiä, break-glass-menettely on myös itsenäinen – sen käyttö Secret-enklaavissa ei myönnä mitään Unclassified-enklaavissa. Palvelutilit on rajattu yhteen nimiavaruuteen, niiden tokenit ovat lyhytikäisiä ja sidottuja tiettyyn työkuormaan, eikä mitään niistä koskaan uudelleenkäytetä klustereiden välillä.

Levykuvien alkuperä: luottamus ansaittu rakennuksessa, varmennettu ajossa

Monienklaavisessa arkkitehtuurissa toimitusketju on houkuttelevin hyökkäyspinta, koska kerran matalalla puolella rakennettu levykuva voi lopulta toimia Top Secret -tasolla. Jokaisen levykuvan on siksi kannettava todennettavaa alkuperää, jonka korkein enklaavi voi tarkistaa luottamatta mihinkään matalampaan enklaaviin ajonaikana.

Kuri on: rakenna matalimmassa enklaavissa, joka pystyy rakentamaan levykuvan, luo täydellinen ohjelmiston materiaaliluettelo (SBOM) SPDX- tai CycloneDX-muodossa, skannaa se kyseiseen enklaaviin peilattua haavoittuvuustietokantaa vasten ja allekirjoita sekä levykuva että SBOM Sigstore Cosign -avaimella. Allekirjoitus sitoo levykuvan tiivisteen tunnettuun rakennusprosessiin. Kukin enklaavi ajaa omaa rekisteriään – Harbor ja zot ovat yleisiä valintoja yhteydettömään käyttöön – ja kunkin klusterin pääsynvalvoja varmentaa Cosign-allekirjoituksen enklaavikohtaista julkista avainta vasten ennen kuin sallii levykuvan toimia. Allekirjoittamaton levykuva, tai sellainen, jonka tiiviste ei vastaa ylennettyä tietuetta, ei koskaan käynnisty.

Tämä on tärkeää rajan yli, koska korkean puolen klusteri ei luota matalan puolen rekisteriin; se luottaa kryptografiseen allekirjoitukseen ja ylennyksen aikana kirjattuun tiivisteeseen. Vaikka matalan puolen rekisteri vaarannettaisiin levykuvan ylentämisen jälkeen, korkea puoli hylkäisi minkä tahansa korvikkeen, jonka tiiviste eroaa siitä, jonka se kirjasi.

Valvottu ylennys domainien välillä

Ylennys on ainoa hyväksytty tapa, jolla artefakti ylittää enklaavin rajan, ja se on tiukasti matalalta korkealle. Polku kulkee akkreditoidun cross-domain-ratkaisun kautta tai, tiukimmissa linkeissä, laitteistollisen datadiodin kautta, joka fyysisesti sallii siirron vain yhteen suuntaan.

Siirtovahti tekee todellista työtä, ei vain kopiota. Se validoi levykuvan tiivisteen ja Cosign-allekirjoituksen hyväksyttyjen artefaktien sallittujen luetteloa vasten; se tarkastaa SBOM:n ja hylkää minkä tahansa levykuvan, joka sisältää kielletyn komponentin, hyväksymättömän lisenssin tai tunnetusti haavoittuvan paketin yli ohjelman kynnyksen; se poistaa tai normalisoi metatiedot, jotka voisivat kantaa piilotettua dataa; ja se kirjaa siirron operaattorin identiteetillä, aikaleimalla ja artefaktin tiivisteellä audittietueeseen molemmilla puolilla. Vasta kun jokainen tarkistus on läpäisty, artefakti kirjoitetaan korkean puolen rekisteriin, josta korkea klusteri voi vetää sen.

Siirto korkealta matalalle on vaarallinen suunta ja sitä kohdellaan vastaavasti. Lokien, mittareiden tai rakennustelemetrian vetäminen alas Secret-enklaavista Unclassified-enklaaviin on mahdollinen vuoto, joten se on joko suoraan kielletty tai reititetty erillisen, paljon tiukemman tarkastuksen kautta, jossa jokainen julkaistu tietue ratkaistaan ihmisen toimesta. Oletusasento on, että data virtaa ylös ja pysyy ylhäällä.

GitOps ja operaatiot ylittämättä rajaa

Kukin enklaavi ajaa omaa GitOps-ohjaintaan – Argo CD tai Flux – sovittaen Git-tietovarastoa vasten, joka sijaitsee kyseisen enklaavin sisällä. Korkeamman enklaavin halutun tilan manifestit ovat itsessään artefakteja, jotka ylennetään ylös cross-domain-ratkaisun kautta, tarkistettuina samalla tavalla kuin levykuvat. Tämä säilyttää auditjäljen (korkean puolen tietovarasto kirjaa täsmälleen, mitä ylennettiin ja kenen toimesta) yhdistämättä koskaan ohjainta rajan yli.

Havainnoitavuus noudattaa samaa sääntöä. Falco ajonaikaiseen uhkien havaitsemiseen, Kubernetesin auditloki, Prometheus-mittarit ja keskitetyt konttilokit kaikki toimivat kunkin enklaavin sisällä ja syöttävät enklaavipaikallista SIEM:iä. Telemetria ei koskaan virtaa ulos korkeasta enklaavista matalan puolen koontinäyttöön; jos yhdistettyä, tasojen välistä operatiivista kuvaa todella tarvitaan, se rakennetaan viemällä tarkistettuja yhteenvetoja ylös korkeimpaan enklaaviin, ei vetämällä raakatelemetriaa alas. Auditsäilytys asetetaan per enklaavi täyttämään kyseisen enklaavin akkreditointivaatimus, ja jatkuva valvonta – haavoittuvuuksien uudelleenskannaukset enklaavinsisäistä peiliä vasten, ajautumisen havaitseminen, levykuvien allekirjoitusten ajoittainen uudelleenvarmennus – toimii itsenäisesti kussakin klusterissa.

Mitä tämä maksaa ja miksi se on sen arvoista

Kolmen itsenäisen klusterin ajaminen yhden monivuokralaisen klusterin sijaan on aidosti enemmän työtä: kolme hallintatasoa paikattavana, kolme rekisteriä täytettävänä, kolme identiteetintarjoajaa, kolme GitOps-putkea ja ylennysprosessi niiden välillä. Insinöörit tuntevat kitkan joka kerta, kun matalalla puolella toimiva levykuva on ylennettävä ennen kuin se voi toimia korkeammalla. Mutta tuo kitka on turvallisuusominaisuus, ei sen vika. Ylennysportti on paikka, jossa alkuperä varmennetaan, kielletyt komponentit napataan ja luodaan täydellinen, muuttumaton tietue siitä, mitä rajan ylitti. Enklaavien romahduttaminen yhdeksi klusteriksi vaivan säästämiseksi vaihtaisi akkreditoitavan, puolustettavan arkkitehtuurin yhteen jaettuun ytimeen ja API-palvelimeen, jotka seisovat Unclassified- ja Secret-tasojen välissä – vaihtokauppa, jota mikään akkreditoija ei hyväksy eikä mikään ohjelma saisi haluta.

Tiimeille, joiden on myös pidettävä korkeammat enklaavit irti yhteyksistä, operatiiviset mallit pariutuvat luonnollisesti ilmavälisen Kubernetes-käytännön kanssa: offline-rekisterit, peilatut riippuvuudet ja päivityskuri, joka ei oleta elävää polkua ulkomaailmaan.