Konténer- és Kubernetes-biztonság: az alapok

A konténer nem biztonsági határ. Ezt érdemes az elején tisztázni, mert sok döntés téves feltételezésre épül: a konténer izolációja lényegesen gyengébb, mint egy virtuális gépé, és a kitörés (container escape) valós kockázat.

Ez a lista arra fókuszál, ami a leggyakoribb hibákat lefedi.

1. Image-ek: minél kisebb, annál jobb

Egy teljes disztribúciót tartalmazó alap image több száz csomagot hoz magával, saját sérülékenységekkel, amikből az alkalmazásnak egy sem kell.

• Használjon minimális alap image-et (distroless vagy hasonló)
• Rögzítse a verziót digest szerint, ne latest címkével
• Építsen többlépcsős fordítást: a fordítóeszközök ne kerüljenek az éles image-be
• Vizsgálja az image-eket a build során és rendszeresen utána is, mert az új sérülékenység később jelenik meg

Erről a szoftverfüggőségekről szóló cikkünkben írtunk részletesen.

2. Ne fusson root-ként

Alapértelmezetten a konténerben a folyamat root. Ha van kitörési sérülékenység, akkor a gazdagépen is root lesz.

• runAsNonRoot: true és konkrét felhasználó megadása
• Csak olvasható gyökér-fájlrendszer, ahol az alkalmazás megengedi
• Minden Linux capability elvétele, és csak a szükségesek visszaadása
• allowPrivilegeEscalation: false

Ez négy sor a konfigurációban, és a kitörési kockázat nagy részét lefedi.

3. Hálózati szabályok

Alapértelmezetten Kubernetesben minden pod elér minden pod-ot. Ez ugyanaz a lapos hálózat probléma, mint a hagyományos infrastruktúrában, csak kisebb léptékben.

Alapértelmezett tiltó házirend, majd névtér és alkalmazás szintjén engedélyezés. A kimenő forgalom korlátozása is fontos, mert a vezérlőcsatorna kiépítését akadályozza.

4. Titkok kezelése

A konténerbe épített vagy környezeti változóban átadott titok több helyen látszik: az image rétegeiben, a folyamatlistában, a naplókban.

A megoldás külső titok-kezelő, ahonnan a konténer futásidőben olvassa ki. A Kubernetes beépített titok-objektuma alapértelmezetten csak base64-kódolt, nem titkosított, ezért a nyugalmi állapotú titkosítást külön be kell kapcsolni.

5. A vezérlősík védelme

A Kubernetes API a legértékesebb célpont: onnan minden erőforrás elérhető.

• Az API szerver soha ne legyen publikusan elérhető
• Szerep-alapú hozzáférés-vezérlés, ténylegesen szűkítve, ne cluster-admin mindenkinek
• Az audit napló bekapcsolva és külső gyűjtőbe küldve
• A kubeconfig fájlok kezelése ugyanolyan szigorú, mint bármely admin hitelesítő adaté

6. Befogadási szabályok

Az admission controller a build és a futtatás közötti utolsó kapu: itt lehet megakadályozni, hogy privilegizált konténer, aláíratlan image vagy erőforrás-korlát nélküli pod induljon.

Először naplózó módban, hogy kiderüljön, mi bukna el, és csak utána blokkolva.

Amit gyakran elfelejtenek

A gazdagép hardeningje. A konténer a gazdagép kernelét használja. Ha az nincs rendben, a konténer sem lesz. A Linux hardeningről szóló cikkünk itt is érvényes.

Az erőforrás-korlátok. Korlát nélkül egy elszabadult konténer az egész node-ot leviszi. Ez rendelkezésre állási és biztonsági kérdés is.

A naplózás. A konténerek rövid életűek, a naplónak túl kell élnie őket. Központi gyűjtés nélkül egy incidens után nincs mit vizsgálni.

Az IT biztonsági szolgáltatásaink között a konténeres környezetek biztonsági felülvizsgálata is szerepel.