1
00:00:00,000 --> 00:00:03,000
Translated by Markus Aurala
(KYBS2001 course assignment at JYU.FI)
2
00:00:03,974 --> 00:00:08,515
Thomas Fricke: Paljon kiitoksia
kutsusta. Toinen puheeni huomenna,
3
00:00:08,515 --> 00:00:13,731
kiitos, eikun, tänään. Tässä on
taustani. Teen enemmän tai vähemmän
4
00:00:13,731 --> 00:00:19,086
Kubernetes-tietoturvaa ja kriiittistä
infraa, olen perustanut useita yrityksiä
5
00:00:19,086 --> 00:00:25,392
ja nyt minun pääfokukseni on Kubernetes-
tietoturva. Tässä Kubernetes-kaninkolo.
6
00:00:25,392 --> 00:00:31,267
Jos tutkit sitä yhtään syvemmin, pitäisi
sinua vähän pelottaa, ja minä kerron
7
00:00:31,267 --> 00:00:36,764
sinulle miksi. Lähestytään ensin
sovellusta. Sitä ajetaan
8
00:00:36,764 --> 00:00:42,976
normaalisti konteissa. Ja konteilla,
toisin kuin yleisesti tiedetään,
9
00:00:42,976 --> 00:00:48,458
on pääsy Kuberneteksen palvelutileihin.
Tämä on yksi suurimmista
10
00:00:48,458 --> 00:00:54,474
Kuberneteksen vioista tällä hetkellä.
Jos saat haltuusi palvelutilin, voit
11
00:00:54,474 --> 00:01:01,088
saada haltuusi koko klusterin. Ja jos
saat haltuusi koko klusterin, voit saada
12
00:01:01,088 --> 00:01:08,156
haltuusi koko noodin ja sitten koko
pilvitilin. Tämä on jonkun muun
13
00:01:08,156 --> 00:01:15,121
tekosia, kerron siitä myöhemmin
esityksessäni. Katsotaanpa mitä tapahtuu:
14
00:01:15,121 --> 00:01:21,952
Kohde on sovellus, joka minulla on
saatavilla Internetissä. Ja haluan
15
00:01:21,952 --> 00:01:28,565
ottaa tuon klusterin haltuuni ulkoa käsin.
Sovellus on ehkä haavoittuva. Esimerkkejä?
16
00:01:28,565 --> 00:01:36,538
Niitä on paljon. Yksi esimerkki on
ImageTragick. Normaalisti ei pitäisi
17
00:01:36,538 --> 00:01:43,876
suorittaa eval- tai exec-komentoja missään
kehikossa – oli se PHP, NodeJS, tai jokin
18
00:01:43,876 --> 00:01:50,644
muu kehikko. Eikä pidä suorittaa komentoja
sovelluksesi kontekstissa, koska
19
00:01:50,644 --> 00:01:56,311
jotain voi mennä pieleen. Kehittäjät
ovat vastuussa tästä. Katsotaan miltä
20
00:01:56,311 --> 00:02:04,604
se näyttää. Tässä on hyökkäysmalli. Se
perustuu hyökkäykseen, jota pidin vanhana
21
00:02:04,604 --> 00:02:13,471
ja joka on korjattu vuonna 2016. Mutta nyt
Emil Lerner on tehnyt uuden katsauksen,
22
00:02:13,471 --> 00:02:22,343
ja näyttänyt ImageMagickin olevan
edelleen käytettävissä hyväksi tällä
23
00:02:22,343 --> 00:02:32,640
hyökkäyksellä. Se toimii. ImageMagickia
käytetään kuvien lataamiseen. Jos muunnat
24
00:02:32,640 --> 00:02:41,163
kuvaa toiseen formaatiin, skaalaat sen
kokoa, ja teet jippoja tälle kuvalle,
25
00:02:41,163 --> 00:02:46,554
voit omistaa koko kontin. Tämä
toimii myös ei-kontitetuille
26
00:02:46,554 --> 00:02:52,520
sovelluksille. Jos sinulla on palvelin,
joka käyttää ImageMagickia johonkin, ole
27
00:02:52,520 --> 00:02:57,566
siis varovainen. Jos olemme onnistuneet
tässä vaiheessa, seuraava vaihe on, että
28
00:02:57,566 --> 00:03:08,167
haluamme pääsyn palvelutiliin. Ja tämä on
oletuksena mahdollista Kuberneteksessa.
29
00:03:08,167 --> 00:03:14,026
Se on siis Kuberneteksen suunnittelu-
virhe, koska palvelutili näkyy konttiin,
30
00:03:14,026 --> 00:03:20,040
jossa sovellusta ajetaan. Hyökkääjän
seuraava askel on asentaa
31
00:03:20,040 --> 00:03:27,229
ylimääräisiä sovelluksia. Jos haluat ottaa
sen haltuusi, tarvitset curl:in, kubectl:n
32
00:03:27,229 --> 00:03:35,386
tai chmod:in. Ja sitten sinä oletkin
palvelutilin omistaja ja voit ajaa komen-
33
00:03:35,386 --> 00:03:42,897
toja lataamalla kuvia ImageTragickiin.
Tästä viasta on vastuussa siis kuvan
34
00:03:42,897 --> 00:03:50,920
luoja. Katsotaan mitä muuta voi
tapahtua. Saadaksesi täyden kontrollin,
35
00:03:50,920 --> 00:03:57,514
tarvitset klusteriylläpitäjän roolin.
Tämä ei ole käytössä oletusarvoisesti,
36
00:03:57,514 --> 00:04:04,067
mutta Internet on täynnä huonoja neuvoja.
Joten jos kopioit asennusvaatimukset tai
37
00:04:04,067 --> 00:04:11,224
-suositukset Internetistä, joku saattaa
kohta ottaa haltuunsa koko klusterin.
38
00:04:11,224 --> 00:04:23,406
Katsotaan tarkemmin asiaa: huonoimman
menetelmän jonka voit löytää, löydät
39
00:04:23,406 --> 00:04:34,320
Elasticin asennussuosituksista: he sanovat
käyttävänsä uudempaa versiota,
40
00:04:34,320 --> 00:04:43,200
mutta he käyttävät klusteriylläpitäjän
oikeuksia asentaakseen Elasticsearchin
41
00:04:43,200 --> 00:04:53,680
Kubernetes-klusteriisi. He siis neuvovat
näin ja niin tekee moni muukin sovellus
42
00:04:53,680 --> 00:04:59,760
asennusvaatimuksissaan. Vaikka se
onkin vanhentunutta tietoa, se on aika
43
00:05:00,480 --> 00:05:08,000
yleistä. Älä koskaan tee tätä, kiitos!
Sen mukana saattaa tulla Helm Charts,
44
00:05:08,000 --> 00:05:16,560
jonka mukana tulee se klusteri-
ylläpitäjän rooli. Näet sen tässä, se oli
45
00:05:16,560 --> 00:05:23,200
Apache Heronissa, joka on Apache-
projekti. Se käyttää klusteriylläpitäjän
46
00:05:23,200 --> 00:05:40,000
roolia, joten Helm-asennuksen kautta
tämä kosketttaa ehkä sinuakin. Näillä
47
00:05:40,000 --> 00:05:46,800
neljällä askeleella, käytännössä kolmella,
sinulla on koko klusteriapplikaatio
48
00:05:46,800 --> 00:05:53,680
paljastettuna, ja sen polun kautta koko
klusteri voidaan ottaa haltuun
49
00:05:53,680 --> 00:06:01,600
etäältä, ja tehdä mitä klusteriylläpitäjä
voi tehdä. Käytännössä tämä
50
00:06:02,400 --> 00:06:09,680
klusteriylläpitäjän rooli on kuin
ovimattohyökkäys - sinulla on paras
51
00:06:09,680 --> 00:06:17,760
salakirjoitus, kalleimmat lukot ja
sitten laitat avaimen ovimaton alle
52
00:06:17,760 --> 00:06:24,480
tai kukkaruukun alle tai
jotain sellaista. Tämä on
53
00:06:24,480 --> 00:06:34,240
jotain sellaista, mitä todellakaan et
halua. Voin näyttää esimerkinomaisesti
54
00:06:34,240 --> 00:06:40,270
miten se menisi. Olen julkaisuut
kaikki koulutusmuistikirjani
55
00:06:40,270 --> 00:06:50,415
GitHubissa. Tässä on miten voit kääntää
tämän vanhentuneen ImageTragickin
56
00:06:50,415 --> 00:06:57,834
OpenShiftissä. Minä käytän CRC:tä, joka on
CodeReady Container -versio. Se perustuu
57
00:06:57,834 --> 00:07:05,134
Mike Williamsin ImageTragick-
esimerkkikoodiin. Tässä ajat ja luot
58
00:07:05,134 --> 00:07:13,582
haavoittuvan levykuvan. Aika pitkä.
Se on käännetty sisään jne. Joten älä
59
00:07:13,582 --> 00:07:19,890
ota koko versiota. Tästä syystä en
näytä sitä tässä, mutta loppujen
60
00:07:19,890 --> 00:07:29,800
lopuksi sinulla on haavoittuva
sovellus kontitettuna ja
61
00:07:29,800 --> 00:07:37,990
OpenShiftissä. Ja sen me juuri tarvitsemme
ajaaksemme sovelluksen. Hyväksi-
62
00:07:37,990 --> 00:07:48,560
käyttö alkaa tästä sillä,
että se kontti otetaan käyttöön
63
00:07:48,560 --> 00:07:54,000
standardi-Kuberneteksessä.
Työkalu oc vastaa kubesctl:iä.
64
00:07:54,720 --> 00:07:59,680
Lisäksi OpenShiftissä on hyvin
yksinkertainen tapa luoda reitti,
65
00:08:00,320 --> 00:08:07,200
joka on kytketty isäntänimeen. Ja sitten
voit ladata sen isäntänimeä käyttäen.
66
00:08:09,040 --> 00:08:16,230
Paljasta asennus, paljasta
luotu palvelu, lopulta paljasta
67
00:08:16,230 --> 00:08:22,920
reitti, ja sitten sinulla on pääsy.
Seuraava askel on, että saat
68
00:08:22,920 --> 00:08:30,814
reitin ja sitten sinulla on URL, jota
voit käyttää. Demossa minä vain
69
00:08:30,814 --> 00:08:38,063
kutsuisin tätä URL:ia ja lähettäisin
kuvia palvelimelle. Olen luonut nämä
70
00:08:38,063 --> 00:08:45,000
ehdat PostScript-tiedostot. Näette,
että niiden perässä on komentoja.
71
00:08:45,000 --> 00:08:50,957
Ja tässä... Koska kontissa on curl,
voin ladata sinne version
72
00:08:50,957 --> 00:08:58,374
kubectl:stä. Käytännössä kontit -
erityisesti Red Hatin - eivät ole niin
73
00:08:58,374 --> 00:09:07,578
haavoittuvia kuin muut. Mutta niissäkin on
aina kirjoitettava tilapäishakemisto, joka
74
00:09:07,578 --> 00:09:16,724
riittää joillekin ohjelmille. Lataamme
curl:illa kubectl:n tilapäishakemistoon,
75
00:09:16,724 --> 00:09:26,042
sitten käytämme chmod-komentoa
aktivoidaksemme kubectl:n. Nyt voimme
76
00:09:26,042 --> 00:09:39,680
suorittaa kubectl-komentoja kontista
käsin. Tuomiopäivän kellot. Juuri oikeassa
77
00:09:39,680 --> 00:09:46,400
paikassa. Meillä on nyt toimiva hyökkäys.
Varoitus: tämä toimii ehkä aiemmissa
78
00:09:46,400 --> 00:09:52,640
Kuberneteksen versioissa.
Uudemmissa tarvitaan lisäksi
79
00:09:54,320 --> 00:10:01,600
nk. myrkkypilleri. Ja tämä
on juurikin tämä kytkös
80
00:10:01,600 --> 00:10:06,880
klusteriylläpitäjän rooliin joka on
oltava, jotta saamme täyden pääsyn ulkoa.
81
00:10:06,880 --> 00:10:15,840
Ja jos me teemme sen, ja paljastamme
roolin sille tunnukselle, joka
82
00:10:15,840 --> 00:10:21,760
on jo paljastettuna kontissa, voimme
suorittaa komentoja kubectl:llä.
83
00:10:21,760 --> 00:10:29,200
Voimme asentaa ohjelmia lataamalla
palvelimelle kuvia. Ja tätä sinä et ikinä
84
00:10:29,200 --> 00:10:34,800
halua, mutta nyt hyökkääjällä on vapaa
pääsy klusteriisi vain lataamalla sinne
85
00:10:35,910 --> 00:10:46,238
käpisteltyjä kuvia. Näin voi tehdä.
Ja tämä on esimerkki vain.
86
00:10:46,238 --> 00:10:56,992
Luo ja tuhoa kontteja ja asennuksia
tällä tavoin. Voit tehdä vaikka mitä.
87
00:11:03,981 --> 00:11:10,560
Ja yhä edelleen, tämä on ongelma
sovelluksen puolella. Jos sinulla
88
00:11:10,560 --> 00:11:20,560
on haavoittuva versio ImageMagickista,
voit lisätä komentoja, ja voit taatusti
89
00:11:20,560 --> 00:11:27,440
asentaa ohjelmia Kubernetes-
palvelimelle. On monia tapoja
90
00:11:27,440 --> 00:11:34,800
korjata tätä. Esimerkiksi, voit käyttää
parempia levykuvia kuten Red Hat tekee.
91
00:11:34,800 --> 00:11:39,760
On Red Hatin terveysindeksi, joka on aika
hyvä. Mutta loppupeleissä nämä levykuvissa
92
00:11:40,320 --> 00:11:48,480
vain se etu, että et aja niissä mitään
pääkäyttäjänä. Mutta ajat näitä kuitenkin
93
00:11:49,440 --> 00:11:54,960
toisella tunnuksella ja sillä tunnuksella
on oikeus kirjoittaa tilapäishakemistoon.
94
00:11:54,960 --> 00:12:04,080
Joten käytännössä et tarvitse pääkäyttäjän
tunnusta asentaaksesi ohjelmia. Kontissa
95
00:12:04,080 --> 00:12:12,000
on hyvät käytännöt: ei pääkäyttäjää, muut-
tumaton juuritiedostojärjestelmä. Mutta
96
00:12:12,000 --> 00:12:16,960
curl, joka on täysin tarpeeton, on
myös asennettuna. Meillä on kirjoitettava
97
00:12:16,960 --> 00:12:23,200
tilapäishakemisto. Meillä on chmod. Ja se
ensimmäinen asia joka tulisi estää kaikki
98
00:12:23,200 --> 00:12:28,800
mitä esittelen tässä nyt. Jos opit edes jotain
tästä esityksestäni, ole hyvä ja mene
99
00:12:30,320 --> 00:12:36,000
katsomaan palvelutilejäsi ja yritä poistaa
käytöstä automountServiceAccountToken-
100
00:12:36,720 --> 00:12:41,520
toiminnallisuudet. Ne palvelutilit, jotka,
eivät tarvitse operaattoreita, eivät
101
00:12:42,160 --> 00:12:49,200
tarvitse myöskään tätä käytössään. Jos
käytät operaattoria, se voi olla nyt rikki,
102
00:12:49,200 --> 00:12:58,480
kapselin määritysten ylikirjoittama.
Mutta käytännössä tämä koko
103
00:12:58,480 --> 00:13:04,560
esimerkki ei toimisi ilman tätä
palvelutilivaltuutusta. Me olemme nyt
104
00:13:04,560 --> 00:13:10,240
korjanneet sen. Me emme voi korjata
sovellusta, koska se on jotain, minkä joku
105
00:13:10,240 --> 00:13:14,960
muu on meille luonut. Ja ei meillä ehkä
ole tietoakaan haavoittuvuudesta. Se voi
106
00:13:14,960 --> 00:13:19,840
olla nollapäivähaavoittuvaisuus. Seuraava
toimenpide on estää ohjelmien asentaminen.
107
00:13:19,840 --> 00:13:29,760
Korjaa levykuvat. Käytä muuttumattomia.
Väliaikaislevytilaa vain jos sitä oikeasti
108
00:13:29,760 --> 00:13:39,760
tarvitaan. PID on 1 joka tapauksessa. OK,
sinulla on ehkä muuttuvaa dataa, mutta
109
00:13:39,760 --> 00:13:47,920
käytä tyhjästä luotuja kontteja, ei curlia
tai wgetiä. Koskee myös Red Hat -UBI:eja
110
00:13:47,920 --> 00:13:52,880
Useimmissa peruslevykuvissa on tämä vika -
niissä on sisällä koko käyttöjärjestelmä
111
00:13:52,880 --> 00:14:02,320
työkaluineen. Mutta tämä
ei ole sinun juttu. Se on
112
00:14:02,320 --> 00:14:08,240
työkalu hyökkääjälle. Joten aja vain
luotettuja levykuvia, rakenna omat
113
00:14:08,240 --> 00:14:16,560
levykuvasi ja rakenna ne alusta pitäen.
Tämä on GitHubiin lataamani esimerkki
114
00:14:16,560 --> 00:14:22,800
konttien tiukentamisesta. Se
perustuu Ngnix:ään Alpinessa. Se on
115
00:14:22,800 --> 00:14:27,520
normaalisti hyvin pieni kontti, mutta voit
tehdä enemmäkin. Voit käyttää skriptiä,
116
00:14:28,400 --> 00:14:33,920
joka on GitHubissa, jotta saat sinne vain
tarvitsemasi työkalut. Tämä ei ole
117
00:14:33,920 --> 00:14:39,557
staattisesti linkitetty, koska Nginx ei
ole alkujaan staattisesti linkitetty,
118
00:14:39,557 --> 00:14:55,905
mutta se on lähellä. Tämä tarkoittaa, että
asennat vain tarvitsemasi ohjelmat. Tämä
119
00:14:55,905 --> 00:15:02,048
on dynaamisesti linkitetty. "-d" jotta
käytetään LVD:tä purkamaan kaikki
120
00:15:02,048 --> 00:15:09,735
dynaamisesti linkitetyt kirjastot ja
tarpeelliset konfiguraatiotiedostot.
121
00:15:09,765 --> 00:15:17,743
/etc/passwd, /etc/group. OK. Jotain
lisenssejä ja jako. Tarvitaan hakemistoja
122
00:15:17,743 --> 00:15:23,154
logitukseen ja sitten voit asentaa sen
tyhjästä, koska tämä skripti asentaa sen
123
00:15:23,154 --> 00:15:32,397
hakemistoon /tmp/harden. Voit tällä
monivaiheisella prosessilla asentaa
124
00:15:32,397 --> 00:15:41,578
mitä haluat /tmp/harden -hakemistosta.
Ja sitten seuraava kontti rakentuu alusta
125
00:15:41,578 --> 00:15:48,908
ja voit käyttää Nginx:ää niin kuin
olet tottunut sitä käyttämään -
126
00:15:48,908 --> 00:15:57,423
staattisesti linkitettynä sovelluksena.
Nyt meillä on tiukennettu levykuva
127
00:15:57,423 --> 00:16:04,328
ilman kubectl:ää, curl:ia. Olemme siis
paljon lähempänä turvallista sovellusta.
128
00:16:04,328 --> 00:16:10,699
Seuraava juttu on tämä linkitys klusteri-
ylläpitäjän rooliin. Älä tee sitä. Jos
129
00:16:10,699 --> 00:16:17,954
jotain menee pieleen sovelluksessasi,
sinulla on lisätoimenpiteitä, joita voit
130
00:16:17,954 --> 00:16:24,675
ottaa käyttöön estääksesi sovellusta
murtautumasta ulos kontista. Voit
131
00:16:24,675 --> 00:16:30,432
erottaa palveluiden ja sisääntulo-
osoitteiden näkyvyyden Internetiin
132
00:16:30,432 --> 00:16:36,640
etuoikeutetuista operaatiosta. On noodi-
asetukset. ElasticSearch tekee paljon
133
00:16:36,640 --> 00:16:44,200
näitä, joten paljon ei ole oikeasti totta.
Tehdään sysctl. Joillakin sovelluksilla
134
00:16:44,200 --> 00:16:51,851
on hostPath päällä tai niillä on yhteys
prosessien väliseen kommunikaatioon, mikä
135
00:16:51,851 --> 00:16:58,477
ei ole tarpeellista jos olet sallinut sen
ja erottelet sitä tarvitsevat sovellukset
136
00:16:58,477 --> 00:17:04,135
niistä, jotka eivät tarvitse sitä.
Klusteriylläpitäjän rooli pitäisi olla
137
00:17:04,135 --> 00:17:09,463
rajoitettu erittäin etuoikeutetuille
operaattoreille. Sitä paitsi, Argo on myös
138
00:17:09,463 --> 00:17:14,852
hyvin etuoikeutettu operaattori. Älä aja
sitä Kuberneteksessa ympäristössä, jossa
139
00:17:14,852 --> 00:17:21,193
tietoturva on kriittistä. Olen nähnyt sen
käyttävän klusteriylläpitäjän roolia.
140
00:17:21,193 --> 00:17:26,798
En tarkoita Argon olevan oletusarvoisesti
turvaton, mutta se on hyvin monimutkainen
141
00:17:26,798 --> 00:17:33,800
sovellus ja minä ajaisin sitä ihan
erillisessä klusterissa, en kriittisessä
142
00:17:33,800 --> 00:17:40,958
klusterissa. Ja miltä arkkitehtuurikorjaus
näyttää? Tässä näet kapselin elinkaaren.
143
00:17:40,958 --> 00:17:47,536
Aika kulkee vasemmalta oikealle.
Tässä näet onko kontti
144
00:17:47,536 --> 00:17:55,931
valmis ja saako siihen yhteyden
Internetistä. Jos teet jotain käynnistys-
145
00:17:55,931 --> 00:18:04,064
järjestelmästä käsin, kuten ajat sysctl:n,
tee se kontista, joka ei ole yhteydessä
146
00:18:04,064 --> 00:18:09,722
Internetiin. Voit vain paussata
kontin, koska paussaus rajoittaa
147
00:18:09,722 --> 00:18:15,721
konttia eikä se ole sitten enää
yhteydessä verkkoon. Ja se on
148
00:18:15,721 --> 00:18:22,786
jotain mikä kattaa arkkitehtuurin.
Lisäksi mainitsin täällä jo
149
00:18:22,786 --> 00:18:28,357
verkkokäytännöt, jotka tulevat myöhemmin.
Tämä on meidän uhkamatriisimme. Olemme
150
00:18:28,357 --> 00:18:32,908
paljastaneet ja piilottaneet palveluita.
On etuoikeutettuja ei ei-etuoikeutettuja
151
00:18:32,908 --> 00:18:39,385
juttuja. Julkiset etuoikeutetut palvelut
ovat vaarallisia. Normaalisti sinulla
152
00:18:39,385 --> 00:18:46,295
on näitä olemassa vain jos ajat
IDE:ä Kuberneteksessä. Sellaista en
153
00:18:46,295 --> 00:18:50,502
haluaisi nähdä kriittisessä
infrastruktuurissa. Sellaista kuin
154
00:18:50,502 --> 00:18:57,680
RStudio tai web-käyttöliittymä GitOps-
kehikkoon. Normaalisti sinulla on vain
155
00:18:57,680 --> 00:19:03,682
web-sovellus. Ja se mitä ei pitäisi olla
paljastettuna normiolosuhteissa on
156
00:19:03,682 --> 00:19:11,657
operaattorin sysctl, käännösjärjestelmät,
isäntäoperaattorit jne. Nämä tehtyäsi on
157
00:19:11,657 --> 00:19:20,702
lähes mahdotonta kaapata klusteriasi.
Sinun pitäisi tehdä kaikki kolme, koska
158
00:19:20,702 --> 00:19:26,480
jos sinulla on useita turvakerroksia, voit
tehdä virheen yhdellä tasolla ja ne
159
00:19:26,480 --> 00:19:32,149
muut tasot pitävät sinut turvassa
hyökkäyksiltä. Voit tehdä vielä
160
00:19:32,149 --> 00:19:38,640
enemmän eristämistä verkkopuolella,
verkkokäytännöt sisääntuloreiteille.
161
00:19:38,640 --> 00:19:44,482
Noodeissa voit aktivoida seccompin,
gVisorin ja yleiset kehikot, SELinuxin ja
162
00:19:44,482 --> 00:19:49,646
AppArmorin. Voit käyttää PodSecurity-
käytäntöjä, jatkossa Open Policy Agentia,
163
00:19:49,646 --> 00:19:56,070
estääksesi noodiasi tulemaan häkätyksi.
Identiteetin ja pääsyn hallinnan puolesta,
164
00:19:56,070 --> 00:20:02,801
sinun pitäisi käyttää omia
palvelutilejä kaikille tehtävillesi.
165
00:20:02,801 --> 00:20:08,557
Joten sinulla on paljon rooleja. Sinun pitäisi
käyttää roolipohjaista pääsynhallintaa
166
00:20:08,557 --> 00:20:18,300
tarkistaaksesi tämän. OK. Minä lupaan,
että voimme mennä syvemmällekin ja
167
00:20:18,300 --> 00:20:27,559
tähän tarvitaan apua pilviylläpitäjältäsi.
Tässä esimerkki Nico Meisenzahlilta,
168
00:20:27,559 --> 00:20:34,867
joka tekee hyvin samanlaista esimerkkiä
Kuberneteksen kaappaamisesta, ja hän
169
00:20:34,867 --> 00:20:42,982
tekee sen yhdessä näistä pilvistä. Ja
mitä hän on saanut selville on, että
170
00:20:42,982 --> 00:20:49,258
voit saada haltuusi azure.json-tiedoston,
jossa on käyttäjäidentiteetit. Nämä eivät
171
00:20:49,258 --> 00:20:55,186
ole Kubernetes-identiteettejä. Nämä ovat
Azure-identiteettejä. Voit saada valtuutuksen,
172
00:20:55,186 --> 00:21:01,670
voit saada tilauksen, voit saada resurssi-
ryhmän ja sitten voit saada curl-komennon
173
00:21:01,670 --> 00:21:06,928
tällä valtuutuksella, muuttaaksesi
asioita resurssiryhmän API-versiolla
174
00:21:06,928 --> 00:21:11,820
tilausta käyttäen. Joten sinun voit ehkä
hakkeroida noodisi etuoikeutetulla
175
00:21:11,820 --> 00:21:17,403
kontilla ja sitten ottaa haltuun koko
tilin. Ja hän kertoi minulle, että tämä
176
00:21:17,403 --> 00:21:25,415
on totuus myös muiden pilvien kanssa. Se
voi toimia myös esimerkiksi AWS:ssä ja
177
00:21:25,415 --> 00:21:33,045
GCP:ssä. Joten ole hyvä ja suojaa myös
pilvitilisi. Ymmärrä identeetin ja pääsyn-
178
00:21:33,045 --> 00:21:38,200
hallintasi pilvessä. Ainakin
jonkun tiimissä pitäisi
179
00:21:38,200 --> 00:21:43,837
ymmärtää se. Ja rajoittaa myös alla
oleva tili minimiinsä. Se voi olla
180
00:21:43,837 --> 00:21:50,515
jopa hyvä idea estää pääsy siihen
osoitteista 169.254.*. Ja tämä voi -
181
00:21:50,515 --> 00:21:57,200
kuten jo mainitsin - koskea myös
niitä muita pilviä. Oma pyyntöni
182
00:21:57,200 --> 00:22:03,451
pilvipalveluntarjoajille on, että älkää
jakako tilitietoja konteissa tai noodeissa.
183
00:22:03,451 --> 00:22:07,571
Tämä ei ole tarpeellista. Se on hyvin
mukavaa, kuten palvelutilin
184
00:22:07,571 --> 00:22:13,499
yhteys ajettavien operaattorien kanssa
on mukavaa. Mutta se on iso tietoturva-
185
00:22:13,499 --> 00:22:22,640
vika ja voit menettää kaikki tilisi ja
datasi. Loppupäätelmä: meillä on
186
00:22:22,640 --> 00:22:29,310
täysi hyökkäysketju sovelluksesta
pilvitilille. Ja se on sinun tehtäväsi
187
00:22:29,310 --> 00:22:36,005
estää se ja korjata se, Tätä kutsutaan
jaetuksi vastuuksi. Pilvipalvelun
188
00:22:36,005 --> 00:22:40,631
tarjoajat huolehtivat käytännössä vain
infrastruktuurista, mutta eivät oikeastaan
189
00:22:40,631 --> 00:22:46,037
tietoturvasta pilvessä. Tämä on teidän
tehtävänne. OK? Kitos huomiostanne,
190
00:22:46,037 --> 00:22:52,109
toivottavasti se oli mielenkiintoista.
Olkaa hyvät ja kysykää nyt.
191
00:22:52,109 --> 00:22:58,369
Aplodeja
192
00:22:58,369 --> 00:23:04,720
Herald: Kiitos esityksestä. Toimiiko tämä?
Jep. Onko meillä yhtään kysymyksiä
193
00:23:04,720 --> 00:23:12,480
Internetistä? En näe mitään tulossa
vielä, mutta luulen meidän olevan
194
00:23:12,480 --> 00:23:17,200
hieman etuajassa, joten kysyn yhden:
Mitä ajattelet siitä, kuka on lähinnä
195
00:23:17,200 --> 00:23:21,280
vastuussa näiden turvattomuuksien
korjaamisesta? Luuletko, että tämän
196
00:23:21,280 --> 00:23:26,880
voi korjata paremmilla oletusarvoilla
infrastruktuurissa ja konfiguraatioissa?
197
00:23:26,880 --> 00:23:31,840
Korjaantuuko tämä paremmilla ohjeilla
ja DevOps-insinöörien paremmalla
198
00:23:31,840 --> 00:23:35,200
koulutuksella? Mikä oli pääpointti
liittyen vastuisiin?
199
00:23:35,200 --> 00:23:44,800
Thomas: Minä pitäisin parhaana turvallisia
oletusasennuksia. Mutta sitten sinulla
200
00:23:44,800 --> 00:23:51,360
on tämä jaettu vastuu sopimuksissa.
Tietystä kulmasta katsottuna sinä itse
201
00:23:51,360 --> 00:23:57,440
olet vastuussa tilisi turvallisuudesta.
Me näemme sen monimutkaisuuden,
202
00:23:58,400 --> 00:24:08,732
koska voi olla 20 vaihetta. Jokainen vaihe
on yksinkertainen ja näyttää varsin
203
00:24:08,732 --> 00:24:15,999
harmittomalta, mutta kaikki vaiheet
yhdessä voivat mahdollistaa hyökkäyksen.
204
00:24:15,999 --> 00:24:23,979
Joten tätä pitää valvoa. Se on erittäin
vaikeaa pilvinatiiveille kehittäjille. He
205
00:24:23,979 --> 00:24:30,417
keskittyvät yleisesti sovelluksensa
tietoturvaan. Kehittäjillä on nykyään
206
00:24:30,417 --> 00:24:36,727
10-100 kertaa enemmän koodia
kovalevyillään kuin 10 vuotta sitten.
207
00:24:36,727 --> 00:24:43,360
Se tarkoittaa, että kehittäjillä
ei voi olla täyttä ymmärrystä
208
00:24:43,360 --> 00:24:49,319
tietoturvasta. Tämä on jotain mistä
kehittäjät puhuvat kun puhuvat tietoturvasta,
209
00:24:49,319 --> 00:24:55,694
olivat he erikoistuneet siihen tai eivät ole
nähneet tälläisiä juttuja. Mitä huomaan
210
00:24:55,694 --> 00:24:59,960
normaalisti on se, että kehittäjät
eivät tunne tälläisiä ongelmia.
211
00:24:59,960 --> 00:25:06,685
H: OK. Ja mitä ajattelet siitä mitä voimme
tehdä monimutkaisuudelle? Tarvitsemmeko
212
00:25:06,685 --> 00:25:10,374
parempaa koulutusta ihmisille, jotta
he ymmärtävät paremmin järjestelmiä?
213
00:25:10,374 --> 00:25:14,274
Vain onko joku tapa, jolla pilvi-infra
voisi vähentää monimutkaisuutta?
214
00:25:14,274 --> 00:25:24,160
T: Parempaa koulutusta ja pitää tehdä
yksinkertaisia korjauksia. Tässä on viisi
215
00:25:24,160 --> 00:25:29,840
vaihetta. Korjaukset ovat yksinkertaisia.
ja ne pitää tarkistaa. Siihen pitää
216
00:25:29,840 --> 00:25:35,520
olla työkalu, koska sinulla voi olla 20
klusteria ja jokaisessa 20 sovellusta.
217
00:25:35,520 --> 00:25:40,800
Tämä voi olla aika monimutkaista. Joten
tarvitset työkaluja saadaksesi kuvan.
218
00:25:40,800 --> 00:25:46,720
Koulutusmateriaaleista löydät esimerkkejä
siitä, miten voit tarkastaa Kubernetes-
219
00:25:46,720 --> 00:25:51,920
klusterin tälläisten hyökkäysten varalta.
H: OK, kiitos todella paljon. Kiitos
220
00:25:51,920 --> 00:25:57,840
kun olit täällä. Jatkamme noin puolen
päästä seuraavalla esityksellä. Sitten
221
00:25:57,840 --> 00:26:04,123
taas saksaksi. Kiitos.
Thomas: Kiitos todella paljon. aplodeja
222
00:26:04,123 --> 00:26:12,552
Outro: Kaikki on CC BY 4.0 -lisenssoitu.
Kaikki on yhteisölle,
223
00:26:12,552 --> 00:26:13,791
tuntemattomille ja ihan kaikille.
224
00:26:13,791 --> 00:26:14,500
Subtitles created by c3subtitles.de
in the year 2022. Join, and help us!
225
00:26:14,500 --> 00:26:15,000
Translated by Markus Aurala
(KYBS2004 course assignment at JYU.FI)