12.5.3 Kubernetes

Kubernetes-klusteri on altis moniin vikoihin, jotka johtuvat turvattomista määrittelyistä.  Mikäli tuotetiimi päättää hallita itse Kubernetes-klusteria, heidän tulee huolehtia myös klusterin turvallisuudesta tunnistamalla nämä määrittelyihin liittyvät heikkoudet. Koska Kuberneteksen kovennus on laaja aihealue, niin erillisen kovennusohjeen ylläpito on työlästä ja se voi vanhentua. Tämän vuoksi Kubernetesin kovennuksessa on suositeltavaa hyödytää CIS:n kovennusohjetta.

Kubernetes-klusterin asetusten turvallisuutta voidaan arvioida CIS-kovennusohjeen lisäksi myös erilaisten työkalujen avulla. Esimerkkeinä mainittakoon  CIS-kovennusohjeen vaatimustenmukaisuuden tarkistamiseen tarkoitettu kube-bench -työkalu sekä kube-hunter -työkalu, jolla klusterista voidaan etsiä avoimia resursseja. Näiden työkalujen käyttö itse hallitun klusterin yhteydessä on suositeltavaa, mutta huomioitavaa on, että ne eivät täydellisesti korvaa manuaalista CIS-kovennusohjeen läpikäyntiä. Kube-hunter -työkalua voi ajaa myös klusterin sisältä, jolloin saadaan käsitys siitä, mitä hyökkääjä näkisi, jos se saisi Kubernetes-podin haltuunsa.

Kubernetesia suositellaan käytettäväksi valmiina palveluna (Platform-as-a-Service, PaaS). Esimerkki tällaisesta valmiista palvelusta on AWS:n Elastic Kubernetes Service (EKS). Valmiin palvelun käyttäminen edellyttää, että jaetun vastuun periaatteen tuntemista hyvin. Esimerkiksi jotkin Kubernetes-alustat vaativat, että alustan käyttäjän on huolehdittava klusteria pyörittävien koneiden päivityksestä itse. Vastuu ei ole välttämättä jakaantunut teknologiapinon selkeää rajaa noudattaen. Mikäli pilvipalvelulla on oma kovennusopas Kubernetesiä varten, pitää sitä noudattaa.

Oli käytössä tuotetiimin itse hallinnoima Kubernetes-klusteri tai valmiina palveluna käytetty klusteri, pitää klusterin käyttöönoton (tai sen käyttöönottotyökalujen) olla kummassakin tapauksessa  CNCF-varmennettu (CNCF Certified Kubernetes).

Kubernetesiin periytyy moni edellä mainittujen Docker-konttien turvallisuusasetuksista. Näitä ovat esimerkiksi Kubernetes-podien ajaminen read-only-tiedostojärjestelmästä sekä konttien isäntökoneiden tiedostojärjestelmien käytön välttäminen.

Kubernetesissä ajettavissa sovelluksissa tulisi käyttää arkkitehtuuria, joka pakottaa hyökkääjän useampikerroksisen puolustuksen läpi. Esimerkki ajattelusta alla olevassa kuvassa:

Perusajatuksena on se, että Kubernetes-podit luokitellaan erillisiin luottamusalueisiin sen mukaan, kuinka paljon hyökkäyspintaa ne avaavat mahdollisten hyökkääjien suuntaan. Yllä olevassa kuvassa edustapodit oletettavasti jäsentävät ja prosessoivat ulkopuolisen hyökkääjän sovelluskerroksen tietovirrat, joten niiden avaama hyökkäyspinta on taustapodeja isompi.

Tietokannat ja taustapalvelut tarvitsevat todennäköisesti salaisuuksia pääsynhallintaa varten, jolloin tässä esimerkissä salaisuudet annetaan vain taustapodeille.

Liikenne taustapodeille pakotetaan kulkemaan edustapodien kautta ja vastaavasti liikenne tietokantoihin ja taustapalveluihin on sallittu vain taustapodien kautta. Tähän voi käyttää esimerkiksi NetworkPolicyä tai service meshiä.

Toisin kuin virtuaalikoneilla, podien välillä ei ole hypervisor-erottelua. Mikäli taustapalveluilla on erityisiä turvatarpeita, niitä voidaan määritellä käyttämällä Kubernetesin inter-pod anti-affinity -asetuksia. Näiden asetusten perusteella Kubernetes laittaa eri luottamusalueiden podit ajoon eri virtuaalikoneille. Tietoturvakriittisten palveluiden osalta on suositeltavaa jakaa sovellus ajoon eri pilvipalvelutilien kesken, jolloin sovellus luonnollisesti jakautuu ajoon eri klustereille.

Edellä esitetyssä esimerkissä luottamusalueita on esitetty kaksi, mutta sovelluksilla loogisia luottamustasoja voi olla useampiakin.

Tämänkaltaisen kohdearkkitehtuurin tarkoituksena on hankaloittaa hyökkääjän toimintaa vaikeuttamalla muiden verkossa olevien kohteiden käyttöä edustapodin kautta. Jos hyökkääjä murtautuisi edustapodille ja saisi sen täysin hallintaansa, se ei kuitenkaan aiheuta taustapalvelimien salaisuuksien vuotamista, vaikka hyökkääjä voikin tehdä pyyntöjä taustapalvelimille taustapodien kautta. Verkkoliikenteen rajoittaminen vain sallittuihin kohteisiin estää myös sen, ettei hyökkääjä pysty kutsumaan esimerkiksi pilvipalvelun metadatan tai Kubernetes-klusterin hallintatason rajapintoihin.

Huomionarvoista on myös se, että kuormantasauskerros tai sisääntulokerros (ingress) eivät välttämättä prosessoi sovellustason dataa lainkaan, jolloin niiden vaikutus edustan kovennuksessa on vähäinen.

Jos sovelluksen arkkitehtuuri on alun perin monoliittinen, sitä ei välttämättä heti kannata lähteä muuttamaan yllä kuvatun kaltaiseksi vaan toteuttaa se samalla, kun sovelluksen arkkitehtuuria muutenkin muutetaan.

Lisätietoja Kubernetes-sovelluskonfiguraatioiden koventamiseen: NSA, CISA Cybersecurity Technical Report: Kubernetes Hardening Guidance (versio 1.2, elokuu 2022).