Translated by Markus Aurala (KYBS2001 course assignment at JYU.FI)
Thomas Fricke: Paljon kiitoksia kutsusta. Toinen puheeni huomenna,
kiitos, eikun, tänään. Tässä on taustani. Teen enemmän tai vähemmän
Kubernetes-tietoturvaa ja kriiittistä infraa, olen perustanut useita yrityksiä
ja nyt minun pääfokukseni on Kubernetes- tietoturva. Tässä Kubernetes-kaninkolo.
Jos tutkit sitä yhtään syvemmin, pitäisi sinua vähän pelottaa, ja minä kerron
sinulle miksi. Lähestytään ensin sovellusta. Sitä ajetaan
normaalisti konteissa. Ja konteilla, toisin kuin yleisesti tiedetään,
on pääsy Kuberneteksen palvelutileihin. Tämä on yksi suurimmista
Kuberneteksen vioista tällä hetkellä. Jos saat haltuusi palvelutilin, voit
saada haltuusi koko klusterin. Ja jos saat haltuusi koko klusterin, voit saada
haltuusi koko noodin ja sitten koko pilvitilin. Tämä on jonkun muun
tekosia, kerron siitä myöhemmin esityksessäni. Katsotaanpa mitä tapahtuu:
Kohde on sovellus, joka minulla on saatavilla Internetissä. Ja haluan
ottaa tuon klusterin haltuuni ulkoa käsin. Sovellus on ehkä haavoittuva. Esimerkkejä?
Niitä on paljon. Yksi esimerkki on ImageTragick. Normaalisti ei pitäisi
suorittaa eval- tai exec-komentoja missään kehikossa – oli se PHP, NodeJS, tai jokin
muu kehikko. Eikä pidä suorittaa komentoja sovelluksesi kontekstissa, koska
jotain voi mennä pieleen. Kehittäjät ovat vastuussa tästä. Katsotaan miltä
se näyttää. Tässä on hyökkäysmalli. Se perustuu hyökkäykseen, jota pidin vanhana
ja joka on korjattu vuonna 2016. Mutta nyt Emil Lerner on tehnyt uuden katsauksen,
ja näyttänyt ImageMagickin olevan edelleen käytettävissä hyväksi tällä
hyökkäyksellä. Se toimii. ImageMagickia käytetään kuvien lataamiseen. Jos muunnat
kuvaa toiseen formaatiin, skaalaat sen kokoa, ja teet jippoja tälle kuvalle,
voit omistaa koko kontin. Tämä toimii myös ei-kontitetuille
sovelluksille. Jos sinulla on palvelin, joka käyttää ImageMagickia johonkin, ole
siis varovainen. Jos olemme onnistuneet tässä vaiheessa, seuraava vaihe on, että
haluamme pääsyn palvelutiliin. Ja tämä on oletuksena mahdollista Kuberneteksessa.
Se on siis Kuberneteksen suunnittelu- virhe, koska palvelutili näkyy konttiin,
jossa sovellusta ajetaan. Hyökkääjän seuraava askel on asentaa
ylimääräisiä sovelluksia. Jos haluat ottaa sen haltuusi, tarvitset curl:in, kubectl:n
tai chmod:in. Ja sitten sinä oletkin palvelutilin omistaja ja voit ajaa komen-
toja lataamalla kuvia ImageTragickiin. Tästä viasta on vastuussa siis kuvan
luoja. Katsotaan mitä muuta voi tapahtua. Saadaksesi täyden kontrollin,
tarvitset klusteriylläpitäjän roolin. Tämä ei ole käytössä oletusarvoisesti,
mutta Internet on täynnä huonoja neuvoja. Joten jos kopioit asennusvaatimukset tai
-suositukset Internetistä, joku saattaa kohta ottaa haltuunsa koko klusterin.
Katsotaan tarkemmin asiaa: huonoimman menetelmän jonka voit löytää, löydät
Elasticin asennussuosituksista: he sanovat käyttävänsä uudempaa versiota,
mutta he käyttävät klusteriylläpitäjän oikeuksia asentaakseen Elasticsearchin
Kubernetes-klusteriisi. He siis neuvovat näin ja niin tekee moni muukin sovellus
asennusvaatimuksissaan. Vaikka se onkin vanhentunutta tietoa, se on aika
yleistä. Älä koskaan tee tätä, kiitos! Sen mukana saattaa tulla Helm Charts,
jonka mukana tulee se klusteri- ylläpitäjän rooli. Näet sen tässä, se oli
Apache Heronissa, joka on Apache- projekti. Se käyttää klusteriylläpitäjän
roolia, joten Helm-asennuksen kautta tämä kosketttaa ehkä sinuakin. Näillä
neljällä askeleella, käytännössä kolmella, sinulla on koko klusteriapplikaatio
paljastettuna, ja sen polun kautta koko klusteri voidaan ottaa haltuun
etäältä, ja tehdä mitä klusteriylläpitäjä voi tehdä. Käytännössä tämä
klusteriylläpitäjän rooli on kuin ovimattohyökkäys - sinulla on paras
salakirjoitus, kalleimmat lukot ja sitten laitat avaimen ovimaton alle
tai kukkaruukun alle tai jotain sellaista. Tämä on
jotain sellaista, mitä todellakaan et halua. Voin näyttää esimerkinomaisesti
miten se menisi. Olen julkaisuut kaikki koulutusmuistikirjani
GitHubissa. Tässä on miten voit kääntää tämän vanhentuneen ImageTragickin
OpenShiftissä. Minä käytän CRC:tä, joka on CodeReady Container -versio. Se perustuu
Mike Williamsin ImageTragick- esimerkkikoodiin. Tässä ajat ja luot
haavoittuvan levykuvan. Aika pitkä. Se on käännetty sisään jne. Joten älä
ota koko versiota. Tästä syystä en näytä sitä tässä, mutta loppujen
lopuksi sinulla on haavoittuva sovellus kontitettuna ja
OpenShiftissä. Ja sen me juuri tarvitsemme ajaaksemme sovelluksen. Hyväksi-
käyttö alkaa tästä sillä, että se kontti otetaan käyttöön
standardi-Kuberneteksessä. Työkalu oc vastaa kubesctl:iä.
Lisäksi OpenShiftissä on hyvin yksinkertainen tapa luoda reitti,
joka on kytketty isäntänimeen. Ja sitten voit ladata sen isäntänimeä käyttäen.
Paljasta asennus, paljasta luotu palvelu, lopulta paljasta
reitti, ja sitten sinulla on pääsy. Seuraava askel on, että saat
reitin ja sitten sinulla on URL, jota voit käyttää. Demossa minä vain
kutsuisin tätä URL:ia ja lähettäisin kuvia palvelimelle. Olen luonut nämä
ehdat PostScript-tiedostot. Näette, että niiden perässä on komentoja.
Ja tässä... Koska kontissa on curl, voin ladata sinne version
kubectl:stä. Käytännössä kontit - erityisesti Red Hatin - eivät ole niin
haavoittuvia kuin muut. Mutta niissäkin on aina kirjoitettava tilapäishakemisto, joka
riittää joillekin ohjelmille. Lataamme curl:illa kubectl:n tilapäishakemistoon,
sitten käytämme chmod-komentoa aktivoidaksemme kubectl:n. Nyt voimme
suorittaa kubectl-komentoja kontista käsin. Tuomiopäivän kellot. Juuri oikeassa
paikassa. Meillä on nyt toimiva hyökkäys. Varoitus: tämä toimii ehkä aiemmissa
Kuberneteksen versioissa. Uudemmissa tarvitaan lisäksi
nk. myrkkypilleri. Ja tämä on juurikin tämä kytkös
klusteriylläpitäjän rooliin joka on oltava, jotta saamme täyden pääsyn ulkoa.
Ja jos me teemme sen, ja paljastamme roolin sille tunnukselle, joka
on jo paljastettuna kontissa, voimme suorittaa komentoja kubectl:llä.
Voimme asentaa ohjelmia lataamalla palvelimelle kuvia. Ja tätä sinä et ikinä
halua, mutta nyt hyökkääjällä on vapaa pääsy klusteriisi vain lataamalla sinne
käpisteltyjä kuvia. Näin voi tehdä. Ja tämä on esimerkki vain.
Luo ja tuhoa kontteja ja asennuksia tällä tavoin. Voit tehdä vaikka mitä.
Ja yhä edelleen, tämä on ongelma sovelluksen puolella. Jos sinulla
on haavoittuva versio ImageMagickista, voit lisätä komentoja, ja voit taatusti
asentaa ohjelmia Kubernetes- palvelimelle. On monia tapoja
korjata tätä. Esimerkiksi, voit käyttää parempia levykuvia kuten Red Hat tekee.
On Red Hatin terveysindeksi, joka on aika hyvä. Mutta loppupeleissä nämä levykuvissa
vain se etu, että et aja niissä mitään pääkäyttäjänä. Mutta ajat näitä kuitenkin
toisella tunnuksella ja sillä tunnuksella on oikeus kirjoittaa tilapäishakemistoon.
Joten käytännössä et tarvitse pääkäyttäjän tunnusta asentaaksesi ohjelmia. Kontissa
on hyvät käytännöt: ei pääkäyttäjää, muut- tumaton juuritiedostojärjestelmä. Mutta
curl, joka on täysin tarpeeton, on myös asennettuna. Meillä on kirjoitettava
tilapäishakemisto. Meillä on chmod. Ja se ensimmäinen asia joka tulisi estää kaikki
mitä esittelen tässä nyt. Jos opit edes jotain tästä esityksestäni, ole hyvä ja mene
katsomaan palvelutilejäsi ja yritä poistaa käytöstä automountServiceAccountToken-
toiminnallisuudet. Ne palvelutilit, jotka, eivät tarvitse operaattoreita, eivät
tarvitse myöskään tätä käytössään. Jos käytät operaattoria, se voi olla nyt rikki,
kapselin määritysten ylikirjoittama. Mutta käytännössä tämä koko
esimerkki ei toimisi ilman tätä palvelutilivaltuutusta. Me olemme nyt
korjanneet sen. Me emme voi korjata sovellusta, koska se on jotain, minkä joku
muu on meille luonut. Ja ei meillä ehkä ole tietoakaan haavoittuvuudesta. Se voi
olla nollapäivähaavoittuvaisuus. Seuraava toimenpide on estää ohjelmien asentaminen.
Korjaa levykuvat. Käytä muuttumattomia. Väliaikaislevytilaa vain jos sitä oikeasti
tarvitaan. PID on 1 joka tapauksessa. OK, sinulla on ehkä muuttuvaa dataa, mutta
käytä tyhjästä luotuja kontteja, ei curlia tai wgetiä. Koskee myös Red Hat -UBI:eja
Useimmissa peruslevykuvissa on tämä vika - niissä on sisällä koko käyttöjärjestelmä
työkaluineen. Mutta tämä ei ole sinun juttu. Se on
työkalu hyökkääjälle. Joten aja vain luotettuja levykuvia, rakenna omat
levykuvasi ja rakenna ne alusta pitäen. Tämä on GitHubiin lataamani esimerkki
konttien tiukentamisesta. Se perustuu Ngnix:ään Alpinessa. Se on
normaalisti hyvin pieni kontti, mutta voit tehdä enemmäkin. Voit käyttää skriptiä,
joka on GitHubissa, jotta saat sinne vain tarvitsemasi työkalut. Tämä ei ole
staattisesti linkitetty, koska Nginx ei ole alkujaan staattisesti linkitetty,
mutta se on lähellä. Tämä tarkoittaa, että asennat vain tarvitsemasi ohjelmat. Tämä
on dynaamisesti linkitetty. "-d" jotta käytetään LVD:tä purkamaan kaikki
dynaamisesti linkitetyt kirjastot ja tarpeelliset konfiguraatiotiedostot.
/etc/passwd, /etc/group. OK. Jotain lisenssejä ja jako. Tarvitaan hakemistoja
logitukseen ja sitten voit asentaa sen tyhjästä, koska tämä skripti asentaa sen
hakemistoon /tmp/harden. Voit tällä monivaiheisella prosessilla asentaa
mitä haluat /tmp/harden -hakemistosta. Ja sitten seuraava kontti rakentuu alusta
ja voit käyttää Nginx:ää niin kuin olet tottunut sitä käyttämään -
staattisesti linkitettynä sovelluksena. Nyt meillä on tiukennettu levykuva
ilman kubectl:ää, curl:ia. Olemme siis paljon lähempänä turvallista sovellusta.
Seuraava juttu on tämä linkitys klusteri- ylläpitäjän rooliin. Älä tee sitä. Jos
jotain menee pieleen sovelluksessasi, sinulla on lisätoimenpiteitä, joita voit
ottaa käyttöön estääksesi sovellusta murtautumasta ulos kontista. Voit
erottaa palveluiden ja sisääntulo- osoitteiden näkyvyyden Internetiin
etuoikeutetuista operaatiosta. On noodi- asetukset. ElasticSearch tekee paljon
näitä, joten paljon ei ole oikeasti totta. Tehdään sysctl. Joillakin sovelluksilla
on hostPath päällä tai niillä on yhteys prosessien väliseen kommunikaatioon, mikä
ei ole tarpeellista jos olet sallinut sen ja erottelet sitä tarvitsevat sovellukset
niistä, jotka eivät tarvitse sitä. Klusteriylläpitäjän rooli pitäisi olla
rajoitettu erittäin etuoikeutetuille operaattoreille. Sitä paitsi, Argo on myös
hyvin etuoikeutettu operaattori. Älä aja sitä Kuberneteksessa ympäristössä, jossa
tietoturva on kriittistä. Olen nähnyt sen käyttävän klusteriylläpitäjän roolia.
En tarkoita Argon olevan oletusarvoisesti turvaton, mutta se on hyvin monimutkainen
sovellus ja minä ajaisin sitä ihan erillisessä klusterissa, en kriittisessä
klusterissa. Ja miltä arkkitehtuurikorjaus näyttää? Tässä näet kapselin elinkaaren.
Aika kulkee vasemmalta oikealle. Tässä näet onko kontti
valmis ja saako siihen yhteyden Internetistä. Jos teet jotain käynnistys-
järjestelmästä käsin, kuten ajat sysctl:n, tee se kontista, joka ei ole yhteydessä
Internetiin. Voit vain paussata kontin, koska paussaus rajoittaa
konttia eikä se ole sitten enää yhteydessä verkkoon. Ja se on
jotain mikä kattaa arkkitehtuurin. Lisäksi mainitsin täällä jo
verkkokäytännöt, jotka tulevat myöhemmin. Tämä on meidän uhkamatriisimme. Olemme
paljastaneet ja piilottaneet palveluita. On etuoikeutettuja ei ei-etuoikeutettuja
juttuja. Julkiset etuoikeutetut palvelut ovat vaarallisia. Normaalisti sinulla
on näitä olemassa vain jos ajat IDE:ä Kuberneteksessä. Sellaista en
haluaisi nähdä kriittisessä infrastruktuurissa. Sellaista kuin
RStudio tai web-käyttöliittymä GitOps- kehikkoon. Normaalisti sinulla on vain
web-sovellus. Ja se mitä ei pitäisi olla paljastettuna normiolosuhteissa on
operaattorin sysctl, käännösjärjestelmät, isäntäoperaattorit jne. Nämä tehtyäsi on
lähes mahdotonta kaapata klusteriasi. Sinun pitäisi tehdä kaikki kolme, koska
jos sinulla on useita turvakerroksia, voit tehdä virheen yhdellä tasolla ja ne
muut tasot pitävät sinut turvassa hyökkäyksiltä. Voit tehdä vielä
enemmän eristämistä verkkopuolella, verkkokäytännöt sisääntuloreiteille.
Noodeissa voit aktivoida seccompin, gVisorin ja yleiset kehikot, SELinuxin ja
AppArmorin. Voit käyttää PodSecurity- käytäntöjä, jatkossa Open Policy Agentia,
estääksesi noodiasi tulemaan häkätyksi. Identiteetin ja pääsyn hallinnan puolesta,
sinun pitäisi käyttää omia palvelutilejä kaikille tehtävillesi.
Joten sinulla on paljon rooleja. Sinun pitäisi käyttää roolipohjaista pääsynhallintaa
tarkistaaksesi tämän. OK. Minä lupaan, että voimme mennä syvemmällekin ja
tähän tarvitaan apua pilviylläpitäjältäsi. Tässä esimerkki Nico Meisenzahlilta,
joka tekee hyvin samanlaista esimerkkiä Kuberneteksen kaappaamisesta, ja hän
tekee sen yhdessä näistä pilvistä. Ja mitä hän on saanut selville on, että
voit saada haltuusi azure.json-tiedoston, jossa on käyttäjäidentiteetit. Nämä eivät
ole Kubernetes-identiteettejä. Nämä ovat Azure-identiteettejä. Voit saada valtuutuksen,
voit saada tilauksen, voit saada resurssi- ryhmän ja sitten voit saada curl-komennon
tällä valtuutuksella, muuttaaksesi asioita resurssiryhmän API-versiolla
tilausta käyttäen. Joten sinun voit ehkä hakkeroida noodisi etuoikeutetulla
kontilla ja sitten ottaa haltuun koko tilin. Ja hän kertoi minulle, että tämä
on totuus myös muiden pilvien kanssa. Se voi toimia myös esimerkiksi AWS:ssä ja
GCP:ssä. Joten ole hyvä ja suojaa myös pilvitilisi. Ymmärrä identeetin ja pääsyn-
hallintasi pilvessä. Ainakin jonkun tiimissä pitäisi
ymmärtää se. Ja rajoittaa myös alla oleva tili minimiinsä. Se voi olla
jopa hyvä idea estää pääsy siihen osoitteista 169.254.*. Ja tämä voi -
kuten jo mainitsin - koskea myös niitä muita pilviä. Oma pyyntöni
pilvipalveluntarjoajille on, että älkää jakako tilitietoja konteissa tai noodeissa.
Tämä ei ole tarpeellista. Se on hyvin mukavaa, kuten palvelutilin
yhteys ajettavien operaattorien kanssa on mukavaa. Mutta se on iso tietoturva-
vika ja voit menettää kaikki tilisi ja datasi. Loppupäätelmä: meillä on
täysi hyökkäysketju sovelluksesta pilvitilille. Ja se on sinun tehtäväsi
estää se ja korjata se, Tätä kutsutaan jaetuksi vastuuksi. Pilvipalvelun
tarjoajat huolehtivat käytännössä vain infrastruktuurista, mutta eivät oikeastaan
tietoturvasta pilvessä. Tämä on teidän tehtävänne. OK? Kitos huomiostanne,
toivottavasti se oli mielenkiintoista. Olkaa hyvät ja kysykää nyt.
*Aplodeja*
Herald: Kiitos esityksestä. Toimiiko tämä? Jep. Onko meillä yhtään kysymyksiä
Internetistä? En näe mitään tulossa vielä, mutta luulen meidän olevan
hieman etuajassa, joten kysyn yhden: Mitä ajattelet siitä, kuka on lähinnä
vastuussa näiden turvattomuuksien korjaamisesta? Luuletko, että tämän
voi korjata paremmilla oletusarvoilla infrastruktuurissa ja konfiguraatioissa?
Korjaantuuko tämä paremmilla ohjeilla ja DevOps-insinöörien paremmalla
koulutuksella? Mikä oli pääpointti liittyen vastuisiin?
Thomas: Minä pitäisin parhaana turvallisia oletusasennuksia. Mutta sitten sinulla
on tämä jaettu vastuu sopimuksissa. Tietystä kulmasta katsottuna sinä itse
olet vastuussa tilisi turvallisuudesta. Me näemme sen monimutkaisuuden,
koska voi olla 20 vaihetta. Jokainen vaihe on yksinkertainen ja näyttää varsin
harmittomalta, mutta kaikki vaiheet yhdessä voivat mahdollistaa hyökkäyksen.
Joten tätä pitää valvoa. Se on erittäin vaikeaa pilvinatiiveille kehittäjille. He
keskittyvät yleisesti sovelluksensa tietoturvaan. Kehittäjillä on nykyään
10-100 kertaa enemmän koodia kovalevyillään kuin 10 vuotta sitten.
Se tarkoittaa, että kehittäjillä ei voi olla täyttä ymmärrystä
tietoturvasta. Tämä on jotain mistä kehittäjät puhuvat kun puhuvat tietoturvasta,
olivat he erikoistuneet siihen tai eivät ole nähneet tälläisiä juttuja. Mitä huomaan
normaalisti on se, että kehittäjät eivät tunne tälläisiä ongelmia.
H: OK. Ja mitä ajattelet siitä mitä voimme tehdä monimutkaisuudelle? Tarvitsemmeko
parempaa koulutusta ihmisille, jotta he ymmärtävät paremmin järjestelmiä?
Vain onko joku tapa, jolla pilvi-infra voisi vähentää monimutkaisuutta?
T: Parempaa koulutusta ja pitää tehdä yksinkertaisia korjauksia. Tässä on viisi
vaihetta. Korjaukset ovat yksinkertaisia. ja ne pitää tarkistaa. Siihen pitää
olla työkalu, koska sinulla voi olla 20 klusteria ja jokaisessa 20 sovellusta.
Tämä voi olla aika monimutkaista. Joten tarvitset työkaluja saadaksesi kuvan.
Koulutusmateriaaleista löydät esimerkkejä siitä, miten voit tarkastaa Kubernetes-
klusterin tälläisten hyökkäysten varalta. H: OK, kiitos todella paljon. Kiitos
kun olit täällä. Jatkamme noin puolen päästä seuraavalla esityksellä. Sitten
taas saksaksi. Kiitos. Thomas: Kiitos todella paljon. *aplodeja*
Outro: Kaikki on CC BY 4.0 -lisenssoitu. Kaikki on yhteisölle,
tuntemattomille ja ihan kaikille.
Subtitles created by c3subtitles.de in the year 2022. Join, and help us!
Translated by Markus Aurala (KYBS2004 course assignment at JYU.FI)