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)