Kubernetes puolustuksen työkuormille: luokiteltujen kontitettujen sovellusten orkestrointi

Konttiorkestroinista on tullut hallitseva käyttöönottomalli modernille puolustusohjelmistolle, mutta luokiteltujen ympäristöjen operatiiviset turvallisuusvaatimukset asettavat rajoituksia, joita tavanomaiset Kubernetes-konfiguraatiot eivät oletuksena täytä. Tavallinen kubeadm-bootstrapattu klusteri altistaa todentamattomia kubelet-API:ita, tallentaa salaisuudet selkotekstiä etcd:hen, ei sovella verkkokäytäntöjä podien välillä ja tuottaa tarkistuslokit, joita ei välitetä eikä suojata väärinkäytöltä. Jokainen näistä oletuksista on havainto missä tahansa vakavassa turvallisuustarkastuksessa. Tässä artikkelissa käsitellään, mitä Kuberneteksen oikea käyttö edellyttää luokitellussa ympäristössä: solmujen koventamisesta CIS- ja STIG-perustasojen mukaisesti HSM-taustaisen salaisuuksien hallinnan kautta verkon mikrosegmentointiin, tarkistuslokin arkkitehtuuriin, kuvan toimitusketjun hallintaan ja toimintavaltuutuksen dokumentaatiopolkuun.

Miksi konttiorkestriointi on tärkeää modernin puolustusohjelmiston käyttöönotossa

Puolustusohjelmisto on historiallisesti otettu käyttöön monoliittisina sovelluksina omistetuilla fyysisillä palvelimilla, ja jokainen järjestelmäpäivitys on edellyttänyt manuaalista koordinointia useiden turvallisuusalueiden välillä ja laajaa uudelleentestausta ennen kuin muutos saavutti operatiivisen ympäristön. Konttiorkestriointi kääntää tämän mallin: sovellukset pakataan muuttumattomiksi kuviksi, infrastruktuuri ilmoitetaan koodina ja orkestroija hallitsee ajoitusta, terveystarkistuksia ja rullaavia päivityksiä solmulaivaston yli. Ohjelmille, joiden on toimitettava kykyjen päivityksiä operaattoreille viikoissa eikä vuosissa, tämä muutos ei ole valinnainen.

Kubernetes tuo lisäetuja, jotka ovat erityisen merkityksellisiä luokitelluille työkuormille. Nimiavaruustason resurssieristys mahdollistaa useiden sovellusten jakaa solmuinfrastruktuuria samalla luokittelutasolla häiritsemättä toistensa suoritin-, muisti- tai verkkoresursseja. Resurssikiintiöt estävät viallista työkuormaa kuluttamasta koko klusterin kapasiteettia. Podin häiriöbudjetti valvoo saatavuusrajoitteita huoltoikkunoiden aikana. Nämä ohjaimet vastaavat suoraan luotettavuus- ja eristysvaatimuksiin, jotka valtuuttavat viranomaiset odottavat näkevänsä dokumentoituina järjestelmäturvasuunnitelmassa.

Haasteena on, että Kubernetes-projekti on suunniteltu internetiin suunnatuille kaupallisille pilviympäristöille, ja sen oletuskonfiguraatio heijastaa tätä taustaa. Kubernetesta käyttöön ottavien puolustusohjelmien on kohdeltava oletuskonfiguraatiota koventamisen lähtökohtana, ei hyväksyttävänä perustasona. Kuilu oletuslusterin ja akkreditointivalmiin klusterin välillä on huomattava, mutta se on hyvin dokumentoitu DISA:n ja Center for Internet Securityn toimesta, ja se on kurottavissa tahallisella konfigurointityöllä.

Solmujen koventaminen: CIS-viitetarkistuslista ja STIG-vaatimustenmukaisuus Kubernetes-työsolmuille

Solmujen koventaminen alkaa käyttöjärjestelmätasolta ennen kuin yhtäkään Kubernetes-komponenttia asennetaan. Työsolmut tulisi rakentaa STIG-kovennetusta tai CIS-taso-2-peruskuvasta -- Red Hat Enterprise Linux CoreOS (RHCOS) OpenShift-pohjaisille klustereille tai kovennettu Ubuntu tai Rocky Linux -rakenne upstream Kubernetekselle. Peruskäyttöjärjestelmäkonfiguraatio kattaa tiedostojärjestelmän osioimisen (erilliset /tmp-, /var- ja /var/log-liityntäpisteet), ytimen parametrien koventamisen (IP-välityksen poistaminen käytöstä paitsi CNI:n edellyttäessä, synckeksien käyttöönotto, IP-lähdereitityksen poistaminen), pakollisen pääsynhallinnan (SELinux-valvontatila tai AppArmor-profiilit) sekä tarpeettomien pakettien ja palvelujen poistamisen.

Kubernetes-tasolla DISA STIG Kubernetekselle ja CIS Kubernetes Benchmark Level 2 supistuvat ydinjoukkoon kubelet-konfigurointivaatimuksia. Kubletin vain luku -portti on poistettava käytöstä (--read-only-port=0). Anonyymi todennus on poistettava käytöstä (--anonymous-auth=false). Valtuutustilaksi on asetettava Webhook, jolloin kaikki valtuutuspäätökset delegoidaan API-palvelimen RBAC-moottorille paikallisten solmupäätösten sijaan. Sertifikaattikierto on otettava käyttöön, jotta kubelet-asiakassertifikaatit uusitaan automaattisesti ennen vanhentumista. Konttisuoritusympäristö -- containerd tai CRI-O -- on konfiguroitava oletuseccomp-profiililla (RuntimeDefault), jota sovelletaan kaikkiin podeihin, ellei niiltä nimenomaisesti vaadita sallivampaa tai mukautettua profiilia.

Kube-bench-suorittaminen, avoimen lähdekoodin CIS-viitetarkistuslistan auditoija, konfiguroitua klusteria vasten tuottaa jäsennellyn vaatimustenmukaisuusraportin XCCDF-muodossa. Tämä raportti on pakollinen liite useimmissa akkreditointipaketeissa. Kategoria I (korkean vakavuuden) havainnot on korjattava ennen toimittamista; Kategoria II:n havainnot tulisi korjata tai dokumentoida kompensoivilla ohjaimin. Automaattiset korjausohjekirjat -- Ansible tai vastaava -- jotka soveltavat viitetarkistuslistan ohjaimet toistettavasti kaikilla solmuilla, ovat vahvasti suositeltavia manuaalisen konfiguroinnin sijaan sekä konfigurointidrift-vähennyksen että auditoitavien muutostietueiden tuottamisen vuoksi.

Verkkokäytäntöjen valvonta: mikrosegmentointi luokiteltujen työkuormien välillä

Oletuksena kaikki Kubernetes-klusterin podit voivat kommunikoida kaikkien muiden podien kanssa riippumatta nimiavaruudesta. Tämä tasainen verkkomalli sopii kehitysympäristöihin, mutta on soveltumaton luokitelluille työkuormille, joissa vähimmäisoikeuden periaatteen on sovelluttava verkkoliikenteeseen aivan kuten RBAC-oikeuksiin. Verkon segmentoinnin valvonta edellyttää kahta asiaa: CNI-pluginia, joka toteuttaa Kubernetes NetworkPolicy -spesifikaation, ja joukko NetworkPolicy-objekteja, jotka määrittelevät sallitut viestintäpolut.

Peruskovennuskäytäntö on oletuksena-kiellä-kaikki-käytäntö, jota sovelletaan jokaiseen nimiavaruuteen klusterin käynnistyksen yhteydessä. Tämä käytäntö kieltää kaiken tulo- ja lähtöliikenteen, ellei eksplisiittinen sallimissääntö sitä salli. Eksplisiittiset sallimissäännöt lisätään sitten kullekin tarvittavalle liikenteenreitille: DNS-selvitys (TCP ja UDP portti 53 CoreDNS:ään kube-systemissä), kubeletin terveystarkistusliikenne sovelluskonteille ja sovelluksen palvelusta-palveluun-viestintä. Jokaisen sallimissäännön on oltava mahdollisimman kapea -- podin etikettivaliditsimen, nimiavaruuden etikettivaliditsimen ja portin mukaan -- sen sijaan, että käytetään laajoja CIDR-alueita, jotka läpäisevät auditoijan tarkistuksen mutta eivät tosiasiassa rajoita sivuttaisliikettä.

Eri luokittelutasoilla toimiville työkuormille, joiden on jaettava jaettu infrastruktuuri, etikettipohjainen NetworkPolicy yksin ei riitä. CNI-plugin valvoo käytäntöjä Linux-ytimen netfilter-tasolla, ja riittävän oikeuksin varustettu vaarantunut kontti voi ohittaa netfilterin. Puolustusohjelmat, jotka isännöivät työkuormia useilla herkkyystasolla yhdessä klusterissa, tulisi sijoittaa kukin herkkyystaso omaan solmujoukkoon omilla verkkoliitännöillä tai VLANeilla ja valvoa tasojen välisiä liikenteen ohjaimia laitteisto- tai hypervisooritasolla. Puolustusverkon pilvi-interconnect-arkkitehtuuri tarjoaa fyysisen ja loogisen erottelun, jota pelkät käytäntöohjaimet eivät voi taata jaetulla ydininfrastruktuurilla.

Salaisuuksien hallinta: Kuberneteksen integrointi HSM-taustaisten avainvarastojen kanssa

Kuberneteksen salaisuudet tallennetaan oletuksena etcd:hen base64-koodattuina arvoina ilman salausta. Kaikki käyttäjät tai prosessit, joilla on lukuoikeus etcd:hen -- tai riittävät RBAC-oikeudet kutsua kubectl get secret -- voivat noutaa selkotekstiarvon. Luokitelluille ympäristöille tämä ei ole konfigurointiaukko; se on perustavanlaatuinen arkkitehtuuriongelma, joka on ratkaistava ennen kuin arkaluonteinen data tallennetaan klusteriin. Ratkaisu on etcd:n salaus levossa käyttämällä KMS-palveluntarjoajaa, joka delegoi avaintenhallinnan HSM-taustaisen avainvaraston käyttöön.

Kube-apiserver EncryptionConfiguration -resurssi määrittää salaustarjoajien luettelon kullekin resurssityypille. KMS-palveluntarjoajaa varten konfiguraatio osoittaa Unix-socketille, jossa KMS-plugin-prosessi kuuntelee. Plugin kääntää Kubernetes KMS gRPC -protokollan kutsuiksi HSM:ään tai avainhallintopalveluun -- tyypillisesti PKCS#11:n kautta verkkoon liitetylle HSM:lle tai puolustusluokan pilvipohjaisen KMS:n avainhallinnan API:n kautta. Kun API-palvelin kirjoittaa salaisuuden etcd:hen, se kutsuu KMS-pluginia salaamaan datan salausavaimen (DEK) HSM:ssä pidettävän avaimen salausavaimen (KEK) alle. Vain kääritty DEK tallennetaan etcd:hen salatekstin rinnalle. Salauksen purkaminen edellyttää edestakaista yhteydenottoa HSM:ään. HSM:n on oltava FIPS 140-2 taso 3 -validoitu SALAINEN-tason työkuormille; taso 2 on yleensä hyväksyttävä vain ARKALUONTEISELLE mutta LUOKITTELEMATTOMALLE materiaalille.

Tarkistuslokit: API-palvelintapahtumien keruu vaatimustenmukaisuuteen ja rikostekniseen analyysiin

Kubernetes API -palvelin tuottaa tarkistuslokin jokaisesta käsittelemästään pyynnöstä: kuka teki pyynnön, mikä verbi ja resurssi oli mukana, mikä nimiavaruus, onnistuiko pyyntö, ja -- konfiguroituna olevan tarkistustason mukaan -- koko pyyntö- ja vastausteksti. Tämä loki on auktoritatiivinen tietue vastaamiseen kysymykseen "kuka teki mitä tässä klusterissa ja milloin." Luokitelluille ympäristöille kattava tarkistuslokit ei ole valinnainen; se on erityinen ohjaimen vaatimus RMF:ssä, JSIG:ssä ja vastaavissa viitekehyksissä, ja riittämättömien tarkistuslokin puuttuminen on tyypillisesti estävä havainto akkreditointikatsauksen aikana.

Tarkistuskäytäntö on YAML-tiedosto, joka välitetään kube-apiserverille käynnistyksessä ja joka kartoittaa resurssityypit ja verbit tarkistustasoihin. Neljä tasoa ovat None (ei lokitusta), Metadata (käyttäjä, verbi, resurssi, tila -- ei tekstiä), Request (lisää pyyntötekstin) ja RequestResponse (lisää sekä pyyntö- että vastaustekstin). Vaatimustenmukaisuustason käytäntö kerää RequestResponse-tason salaisuuksille, ConfigMapeille, Rooleille, RoleBindingsille, ClusterRooleille, ClusterRoleBindingsille ja ServiceAccounteille -- resursseille, joiden muokkaaminen voi viitata oikeuksien laajentamiseen tai tunnistetietojen varkauteen. Pod exec- ja attach-kutsut on myös kerättävä RequestResponse-tasolla, sillä nämä ovat ensisijaisia vektoreita interaktiiviselle sivuttaisliikkeelle vaarantuneessa klusterissa. Kaikki muut resurssit voidaan lokittaa Metadata-tasolla, mikä tuottaa täydellisen käyttötietueen ilman tallennustilan ylikuormitusta jokaisen sovelluslastauksen keruusta.

Vain ohjaustason solmulle tallennetut tarkistuslokit ovat alttiita vaarantuneen klusterin ylläpitäjän tekemälle väärinkäytölle. Puolustusluokan tarkistuslokin arkkitehtuuri toimittaa lokit ulkoiseen kohteeseen, johon klusteria itsessään ei voida kirjoittaa tai jota ei voida poistaa: SIEM (tietoturvatieto- ja tapahtumahallintajärjestelmä), vain-lisää-S3-yhteensopiva objektivarasto objekti-lukko-säilytyksellä tai erillinen syslog-välittäjä ilmarakotettuun lokien aggregointiinfrastruktuuriin. Lokiuudelleenlähetin -- Fluentd tai Fluent Bit DaemonSet ohjaustason solmuilla -- on suoritettava Kubernetes-palvelutilillä, jolla ei ole oikeuksia klusterin lokitettaviin objekteihin, jotta vaarantunut lähetin ei voi peittää omia jälkiään muuttamalla tarkistuskäytäntöä tai poistamalla lokitiedostoja.

Kuvan skannaus ja toimitusketjun turvallisuus luokitelluissa konttitallentimissa

Jokainen luokiteltuun klusteriin käyttöön otettu konttikuva on mahdollinen toimitusketjun hyökkäyspinta. Julkisesta tallentimesta ilman tarkistusta vedetty kuva voi sisältää tunnettuja haavoittuvia kirjastoversioita, upotettuja tunnistetietoja tai rakennusputkilinjaan tuotettua haitallista koodia. Puolustusohjelmat on operoitava yksityistä konttitallenninta, joka on eristetty julkisesta internetistä, vaatii todennetun pääsyn ja valvoo haavoittuvuusskannausta ja kuvan allekirjoitusta ennen kuin mikään kuva otetaan klusteriin.

Kuvan haavoittuvuusskannaustyökalut kuten Trivy tai Grype analysoivat jokaisen kuvakerroksen OSV-neuvontatietokantaa ja toimittajien turvallisuustiedotteita vasten tuottaen luettelon CVE:istä vakavuuspisteineen ja vaikuttuneista pakettiversioista. Luokitellussa CI-putkistossa skannaus suoritetaan osana kuvan rakennusprosessia; kriittisiä tai korkean vakavuuden CVE:itä sisältävät kuvat estetään siirtymästä tuotantotallentimeen, kunnes haavoittuvuudet on korjattu tai hyväksytty muodollisesti riskeiksi. Skannaustulokset tallennetaan kuvan rinnalle tallentimen metatietoihin ja viitataan akkreditointitodistepaketissa todisteina siitä, että ohjelmistoluettelo on tunnettu ja tarkistettu.

Kuvan allekirjoittaminen lisää kryptografisen vakuuden, että tietty kuvan tiiviste on tuotettu tietyssä rakennusputkilinjassa eikä sitä ole muutettu allekirjoittamisen jälkeen. Sigstore-projektin cosign-työkalu tukee allekirjoittamista HSM:ssä tai KMS:ssä tallennetulla avaimella tuottaen allekirjoitusvakuutuksen, joka tallennetaan tallentimeen kuvan rinnalle. Kubernetes-hyväksyntäweb-hook -- käyttämällä käytäntömoottoria kuten Kyverno tai OPA Gatekeeper -- tarkistaa allekirjoituksen ennen kuin yhtäkään podia aikataulutetaan. Tämä säilytysketju rakennuksesta käyttöönottoon on tarkalleen se, mitä toimitusketjun turvallisuuskehykset edellyttävät: jokainen klusterissa ajettava työkuorma voidaan jäljittää tiettyyn allekirjoitettuun rakennusartefaktiin, ja allekirjoittamattomat tai väärennellyt kuvat hylätään hyväksyntäkerroksessa eikä löydetä tapauksen jälkeisessä rikosteknisessä tarkistuksessa.

Akkreditointipolku: Kubernetes-klusterin läpäisy ATO:n tai vastaavan kautta

Toimintavaltuutus Kubernetes-klusterille ei ole yksittäinen asiakirja vaan todistekokoelma, joka kootaan osoittamaan, että järjestelmä täyttää sovellettavassa viitekehyksessä määritellyt turvallisuusohjaimet -- Risk Management Framework (RMF) Yhdysvaltojen liittovaltion ohjelmille, JSIG yhteistiedustelupalvelujärjestelmille tai ohjelman erityisvastaavat liittoutuneiden kansakuntien puolustushankintaan. Valtuuttava viranomainen tarkistaa tämän paketin ja tekee riskinpäätöksen. Paketin sisällön ymmärtäminen on olennaista akkreditointiaikataulun suunnittelussa, koska tarkistusprosessin myöhäisessä vaiheessa havaitut puutteet voivat viivästyttää toimialalle tuloa kuukausilla.

Järjestelmäturvasuunnitelma on keskeinen asiakirja. Kubernetes-klusteria varten SSP:n on kuvattava klusteriarkkitehtuuri (ohjaustason solmujen lukumäärä ja sijoittelu, etcd-topologia, työsolmujoukot, verkkopoologia), solmujen koventamiskonfiguraatio viittauksineen kube-bench-vaatimustenmukaisuusraporttiin, etcd:n salaisuuskonfiguraatio, RBAC-malli (millä palvelutileillä on mitkä oikeudet ja miksi), verkkokäytäntöarkkitehtuuri, kuvan alkuperä ja allekirjoitusketju sekä tarkistuslokin välittämisarkkitehtuuri. Jokainen sovellettavan perustan ohjain on joko täytetty (viittauksella todisteisiin), ei-sovellettava (perustelu) tai avoin (kompensoivalla ohjaimella tai POA&M-merkinnällä).

Jatkuva seuranta on useimpien ATO:jen ehto eikä kertaluonteinen portti. Klusteriin on liityttävä konfigurointihallintajärjestelmä, joka havaitsee ajautumisen kovennetusta perustasosta, haavoittuvuudenhallintaprosessi, joka seuraa CVE:itä käyttöönotetuissa kuvissa ja solmujen käyttöjärjestelmäpaketeissa korjaus-SLA:ta vasten, sekä lokitarkistusprosessi, joka valvoo tarkistustapahtumia poikkeamien varalta. Automaattiset työkalut -- kube-bench aikataulutettuna Kubernetes CronJob -tehtävänä, kuvan uudelleenskannaus yöllisellä aikataululla, SIEM-hälytysohjaussäännöt epäilyttäville API-palvelimen malleille -- tuottavat jatkuvan seurannan todisteita ilman manuaalista työtä jokaisessa tarkistussyklissä. Ohjelmat, jotka rakentavat tämän automaation ennen alustavan ATO:n toimittamista, ovat paljon vahvemmassa asemassa uudelleenvaltuutuksessa kuin ne, jotka käsittelevät jatkuvaa seurantaa valtuutuksen jälkeisenä jälkiajatuksena.