Kubernetesistä on tullut vakiokäyttöönottoalusta kontittamiselle puolustuksessa, DoD Platform One:sta NATO:n jäsenvaltioiden kansallisiin puolustuspilviolhjelmiin. Sen hyväksyntää puolustusympäristöissä ohjaavat samat operatiiviset edut, jotka ohjasivat kaupallista hyväksyntää: yhdenmukainen käyttöönotto ympäristöissä, automaattinen skaalaus, itseparantuvat työkuormat ja deklaratiivinen infrastruktuurin hallinta. Mutta Kubernetes-oletusasennus on suunniteltu helppokäyttöisyydelle, ei turvallisuudelle — ja turvallisuuserotta oletusasennuksen ja kovennetun, puolustustason käyttöönoton välillä on merkittävä.

NSA ja CISA julkaisivat Kubernetes Hardening Guide:n (v1.2, elokuu 2022) erityisesti tämän aukon korjaamiseksi. Opas kattaa ohjaustason koventamisen, verkon turvallisuuden, podin turvallisuuden, kirjausketjun lokituksen sekä todentamisen ja valtuutuksen — tarjoten käytännöllisen lähtöpisteen puolustuksen Kubernetes-käyttöönotoille. CIS Kubernetes Benchmark tarjoaa täydentävän, tarkemman joukon pisteytettyjä konfiguraatiotarkastuksia.

NSA/CISA Kubernetes Hardening Guide: tärkeimmät suositukset

NSA/CISA-opas järjestää suositukset kuuteen kategoriaan. Puolustuksen kannalta operatiivisesti merkittävimmät ovat:

Kubernetes-podin turvallisuus. Podien tulisi käyttää ei-root-kontteja, vain luku -juuritiedostojärjestelmiä, ja niillä tulisi olla minimiin pudotetut ominaisuudet. Etuoikeutettuja kontteja — joilla on täysi pääsy isäntäjärjestelmään — ei saa sallia tuotantotypökuormille.

Verkon erottelu ja koventaminen. Kaiken palveluiden välisen liikenteen tulisi olla salattua TLS:llä (palveluverkko mTLS:llä). Verkkokäytäntöjen tulisi rajoittaa pod-to-pod-viestintä eksplisiittisesti sallittuihin polkuihin. Kubernetes API -palvelimeen ei tulisi olla suoraa pääsyä internetistä tai epäluotetuista verkkosegmenteistä.

Todentaminen ja valtuutus. API-palvelin ei saa mahdollistaa anonyymiä todentamista tai turvattomia portteja. Role-Based Access Control (RBAC) on oltava käytössä ja konfiguroitu vähimmäisoikeusperiaatteiden mukaisesti. Palvelutilitunnuksia ei tulisi automaattisesti kiinnittää podeihin, jotka eivät tarvitse API-palvelimeen pääsyä.

Kirjausketjun lokitus. API-palvelimen kirjausketjun lokitus on otettava käyttöön politiikalla, joka tallentaa vähintään luonti-, päivitys-, poisto- ja get-operaatiot arkaluonteisille resurssityypeille. Kirjausketjun lokeja on välitettävä keskitetylle SIEM- tai lokienhallintajärjestelmälle, jossa klusterin ylläpitäjät eivät pysty muokkaamaan niitä.

Päivitystiheys. Kubernetes-versiot saavat tietoturvapäivityksiä noin 14 kuukauden ajan julkaisun jälkeen. Tukemattomien Kubernetes-versioiden ajaminen on merkittävä turvallisuusriski, joka on hyväksymätöntä puolustuksen käyttöönotoissa.

Pod Security Standards: Restricted-profiili

Kubernetes Pod Security Standards (PSS) määrittelee kolme käytäntöprofiilia — Privileged, Baseline ja Restricted — jotka edustavat lisääntyviä podin konfiguraatiorajoituksia. Restricted-profiili on sopiva peruslinja puolustuksen työkuormille: se pakottaa turvallisuuden kannalta merkityksellisimmät podin konfiguraatiorajoitukset.

Restricted-profiili kieltää: etuoikeutetut kontit (kontit, joilla privileged-lippu on true), root-käyttäjänä ajavat kontit (pakotettu runAsNonRoot: true:lla), isäntäverkkoon pääsevät kontit (hostNetwork: false), isäntä-PID:eihin tai IPC:eihin pääsevät kontit (hostPID: false, hostIPC: false), isäntäpolkuja volyymikiinnittymissä käyttävät kontit ja kontit, jotka lisäävät Linux-ominaisuuksia yli määritellyn sallittujen listan.

Restricted-profiilin toteuttaminen olemassa olevassa Kubernetes-ympäristössä vaatii usein sovelluksen muutoksia: sovelluksia, jotka on kirjoitettu olettaen root-pääsyn, kirjoitusoikeuden tiedostojärjestelmään tai isäntäverkkopääsyn, on refaktoroitava toimimaan Restricted-profiilin sisällä. Uudessa puolustussovelluskehityksessä Restricted-profiilin vaatimustenmukaisuuden tulisi olla suunnitteluvaatimus alusta alkaen — sen lisääminen jälkikäteen käyttöönoton jälkeen on huomattavasti kalliimpaa.

Pod Security Standards pakotetaan sisäänrakennetun PodSecurity-pääsynhallintaohjaimen kautta (saatavilla Kubernetes 1.25:stä alkaen). Täytäntöönpanomoodit ovat Enforce (käytäntöä rikkovat podit hylätään), Audit (rikkomukset kirjataan mutta podit sallitaan) ja Warn (rikkomukset aiheuttavat API-varoituksia mutta podit sallitaan). Puolustuksen käyttöönotoissa tulisi käyttää Enforce-tilaa Restricted-profiilille kaikissa tuotantonimiavaruuksissa.

Verkkokäytännöt: mikrosegmentointi Calicolla tai Ciliumilla

Kubernetes-verkkokäytännöt määrittelevät, mitkä podit voivat kommunikoida muiden podien kanssa IP/port-tasolla. Ilman verkkokäytäntöjä kaikki klusterin podit voivat kommunikoida kaikkien muiden podien kanssa — tasainen verkkorakenne, joka on arkkitehtuurisesti yhteensopimaton zero-trust-periaatteiden kanssa. Verkkokäytännöt toteuttavat mikrosegmentointikerroksen konttien verkostotasolla.

Calico on eniten käytetty Kubernetes-verkkokäytäntötoteutus, tukien sekä vakio Kubernetes NetworkPolicy -resursseja että Calico-kohtaisia GlobalNetworkPolicy- ja NetworkPolicy-resursseja lisäominaisuuksilla. Calico voidaan ottaa käyttöön useissa moodeissa (BGP-reititys, VXLAN-overlay tai eBPF-datataso) ja integroituu ulkoisiin palomuureihin BGP-reitin ilmoituksen kautta. Air-gap-puolustusympäristöille Calicon on-premises-käyttöönottomalli ja pilviohjaustason riippuvuuksien puuttuminen tekevät siitä operatiivisesti sopivan.

Cilium käyttää eBPF:ää (Extended Berkeley Packet Filter) verkkokäytäntöjen täytäntöönpanoon Linux-ytimessä, tarjoten korkeamman suorituskyvyn kuin iptables-pohjaiset ratkaisut ja tukien Layer 7 (sovellustaso) -verkkokäytäntöjä — esimerkiksi sallia HTTP GET -pyynnöt mutta estää POST-pyynnöt tietyllä API-polulla. Ciliumin Hubble-havaittavuuskomponentti tarjoaa yksityiskohtaisen näkyvyyden verkkovirtauksiin.

Keskeinen periaate puolustuksen verkkokäytäntösuunnittelulle on oletusarvoisesti estäminen: uusilla nimiavaruuksilla tulisi olla oletus-deny-NetworkPolicy, joka estää kaiken sisään- ja ulostulevaan liikenteen, kunnes eksplisiittiset sallimissäännöt luodaan.

Pääsynhallintaohjaimet: politiikka koodina OPA/Gatekeeperillä ja Kyvernolla

Pääsynhallintaohjaimet ovat liitännäisiä, jotka sieppaavat API-palvelimelle tulevat pyynnöt ennen niiden säilymistä etcd:hen, mahdollistaen politiikkojen täytäntöönpanon klusterin API-tasolla. OPA/Gatekeeper ja Kyverno ovat kaksi hallitsevaa politiikka-koodina-kehystä Kubernetes-pääsynhallintaan.

OPA/Gatekeeper käyttää OPA (Open Policy Agent) -politiikkamoottorita Rego-politiikkakielellä. Gatekeeper rekisteröityy ValidatingAdmissionWebhook:ina, joka kutsuu OPA-politiikkamoottoria jokaiselle asiaankuuluvalle API-pyynnolle. Constraint Templates määrittelevät politiikkarakenteen; Constraints instantioivat mallin tietyille resursseille.

Kyverno käyttää Kubernetes-natiivi-YAML:ia politiikkojen ilmaisemiseen, tehden siitä helpommin lähestyttävän tiimeille, jotka tuntevat Kubernetes-resurssimäärittelyt mutta eivät ole mukavia Reon kanssa. Kyverno tukee sekä validointia (vaatimustenvastaisten resurssien estäminen) että mutointia (automaattisesti vaadittujen merkintöjen tai turvallisuuskontekstikenttien lisääminen puuttuviin resursseihin).

Puolustuksen käyttöönotoissa pääsynhallintakäytäntöjen tulisi pakottaa vähintään: kuvan alkuperä (kuvien on tultava hyväksytyistä rekistereistä), kuvan allekirjoitus (kuvilla on oltava kelvolliset cosign-allekirjoitukset), turvallisuuskontekstivaatimukset (ei-root, ei etuoikeutettu, ei isäntänimiavaruudet), vaaditut etiketit ja resurssirajat (kaikilla konteilla on oltava CPU- ja muistirajat määriteltynä).

Ajonaikainen turvallisuus: Falco, seccomp ja AppArmor

Falco (CNCF-hyväksytty) on Kubernetes:in vakioajonaikainen turvallisuustyökalu: se valvoo ytimen järjestelmäkutsuja reaaliajassa ja luo hälytyksiä, kun käyttäytyminen vastaa epäilyttäviä malleja. Falco-säännöt kattavat prosessin suorituksen (odottamattomat suoritettavat konttien sisällä), tiedostojen käytön (kirjoitukset järjestelmähakemistoihin, arkaluonteisten tiedostojen lukeminen), verkkotoiminnan (odottamattomat lähtevät yhteydet konteista) ja Kubernetes API -toiminnan (luvattomat API-kutsut, tunnistetietojen varastamisyritykset).

seccomp (secure computing mode) -profiilit rajoittavat konttiprosessien saatavilla olevia järjestelmäkutsuja. Konttiprosessi, joka ajaa seccomp-profiililla, voi tehdä vain ne järjestelmäkutsut, jotka kyseinen profiili eksplisiittisesti sallii — kaikki muut estetään. Kubernetes tarjoaa oletusjärjestelmäkutsuprofiilin (RuntimeDefault), joka estää vaarallisimmat järjestelmäkutsut samalla kun sallii normaalin sovelluksen toiminnan.

AppArmor (Linux-jakeluissa, jotka tukevat sitä) tarjoaa pakollisen käyttöoikeusvalvontakerroksen, joka rajoittaa mitä tiedostoja, ominaisuuksia ja verkkotoimintoja kukin prosessi voi käyttää. AppArmor-profiilit Kubernetes-konteille määrittelevät, mitä konttiprosessilla on sallittua tehdä, lisäämällä kerrostetun puolustuskerroksen.

Keskeinen oivallus: Kubernetes-koventaminen ei ole kertaluonteinen konfiguraatiotoimenpide — se on jatkuva asennonhallinnan kurinalaisuus. Kluusterikonfiguraatiot ajautuvat ajan myötä (manuaaliset muutokset, helm-kaaviopäivitykset, uudet sovellukset). Jatkuva vaatimustenmukaisuuden skannaus (kube-benchiä CIS-vertailukohtatarkastuksiin, Polarista parhaiden käytäntöjen tarkistuksiin tai Trivyn vääräkonfiguraatioskannauksia käyttäen) on integroitava operatiiviseen työnkulkuun konfiguraatioajautumisen havaitsemiseksi ja korjaamiseksi ennen kuin se muuttuu turvallisuushäiriöksi.