A Kubernetes biztonság ma már nem csak nagyvállalati téma. Egyre több KKV futtat konténerizált alkalmazásokat felhőben, menedzselt Kubernetes szolgáltatáson vagy akár saját infrastruktúrán. A rugalmasság nagy előny, de a klaszter rossz beállításai gyorsan kockázattá válhatnak: túl széles jogosultságok, nyitva hagyott adminfelületek, sérülékeny konténerképek vagy hiányzó naplózás mind okozhatnak komoly problémát. A jó hír: a védekezés alapjai kis lépésekben is bevezethetők.
Miért más a Kubernetes biztonság, mint a hagyományos szervervédelem?
A hagyományos szerverüzemeltetésnél jellemzően néhány gépet, szolgáltatást és hozzáférést kell kontrollálni. Kubernetes esetén viszont sok, gyorsan változó komponens működik együtt: podok, node-ok, konténerképek, service-ek, ingress szabályok, secret-ek, service accountok és különböző API-hozzáférések. Ez a dinamika adja a rendszer erejét, de a támadási felületet is növeli.
KKV-k számára külön kihívás, hogy gyakran nincs külön platform engineering vagy dedikált konténerbiztonsági csapat. Emiatt érdemes a legnagyobb kockázatokat kezelő, jól automatizálható alapokra koncentrálni. A cél nem az, hogy minden az első naptól tökéletes legyen, hanem hogy a klaszter ne „alapértelmezett, mindent engedő” állapotban működjön.
Első lépés: jogosultságok és hozzáférések rendbetétele
A Kubernetes egyik legfontosabb védelmi rétege az RBAC, vagyis a szerepköralapú hozzáférés-kezelés. Gyakori hiba, hogy fejlesztők, CI/CD rendszerek vagy külső szolgáltatások túl széles jogkört kapnak, például cluster-admin szerepkört, miközben csak egy namespace-ben kellene deployolniuk.
Gyakorlati minimumként érdemes az alábbiakat bevezetni:
- Legkisebb jogosultság elve: minden felhasználó, service account és automatizmus csak azt érje el, amire ténylegesen szüksége van.
- Namespace-ek elkülönítése: fejlesztői, teszt és éles környezet ne keveredjen ugyanabban a logikai térben.
- Rendszeres jogosultság-felülvizsgálat: a régi hozzáférések, elhagyott service accountok és ideiglenes adminjogok ne maradjanak bent hónapokig.
- Központi azonosítás: ha lehet, a felhasználói hozzáférés kapcsolódjon vállalati identity providerhez, ne szétszórt kubeconfig fájlokra épüljön.
A kubeconfig fájlokat különösen óvatosan kell kezelni, mert rossz kezekbe kerülve közvetlen hozzáférést adhatnak a klaszterhez. Ezeket ne tároljuk nyílt repositoryban, közös mappákban vagy titkosítás nélküli laptopokon.
Konténerbiztonság: ne csak futtatáskor védekezzünk
A konténerbiztonság már a fejlesztési folyamatban kezdődik. Ha egy alkalmazás sérülékeny alapképre épül, root felhasználóként fut, vagy felesleges eszközöket tartalmaz, akkor a Kubernetes önmagában nem fogja megoldani a problémát.
Érdemes standardizálni, milyen konténerképeket használhat a csapat. A hivatalos, karbantartott base image-ek előnyösebbek, mint az ismeretlen forrásból származó, régen frissített képek. A CI/CD pipeline része lehet az image scanning, amely jelzi az ismert sérülékenységeket. Fontos azonban, hogy ez ne csak „piros-zöld” ellenőrzés legyen: legyen belső szabály arra, milyen súlyosságú hibánál kell megállítani a kiadást, és mikor fogadható el átmeneti kivétel.
Futtatáskor ajánlott kerülni a root jogosultságot a konténeren belül, tiltani a privilege escalation lehetőségét, és csak a szükséges Linux capability-ket engedélyezni. Ezek a beállítások sokszor egyszerűen megadhatók a pod security context részeként, mégis gyakran kimaradnak.
Kubernetes hardening: alapbeállítások, amelyek sokat számítanak
A Kubernetes hardening nem egyetlen termék vagy varázskapcsoló, hanem biztonságos konfigurációk következetes alkalmazása. Menedzselt felhős Kubernetes esetén a vezérlősík védelmének egy részét a szolgáltató kezeli, de az ügyfél felelőssége továbbra is jelentős: workloadok, jogosultságok, hálózati szabályok, secret-kezelés és naplózás.
A legfontosabb gyakorlati lépések közé tartozik a Kubernetes API elérésének korlátozása. Ha nincs rá üzleti ok, ne legyen bárhonnan elérhető adminfelület. Használjunk VPN-t, privát endpointot vagy IP-alapú korlátozást, ahol ez megoldható. A node-okhoz való közvetlen SSH-hozzáférést is érdemes minimalizálni, mert a napi üzemeltetés nagy része Kubernetes-eszközökkel megoldható.
A hálózati szeparáció szintén kulcsfontosságú. Alapértelmezésben sok klaszterben a podok szabadon kommunikálhatnak egymással. Network Policy segítségével megadható, melyik alkalmazás melyik másik szolgáltatáshoz férhet hozzá. Egy webes frontendnek például jellemzően nincs szüksége közvetlen adatbázis-adminisztrációs vagy belső monitoring végpontokra.
Secret-kezelés, naplózás és mentés
A Kubernetes Secret objektum hasznos, de nem szabad túlértékelni. Alapbeállítások mellett nem feltétlenül jelent teljes körű titkosítást minden élethelyzetben. Érdemes ellenőrizni, hogy az etcd titkosítás be van-e kapcsolva, és ahol lehet, külső secret-kezelőt használni, például felhős kulcskezelő szolgáltatással integrálva.
A naplózás és monitorozás a felhő natív védelem alapja. Nem elég tudni, hogy „fut-e” az alkalmazás; látni kell a gyanús eseményeket is: sikertelen belépési kísérleteket, szokatlan API-hívásokat, váratlan podindításokat, jogosultságmódosításokat. Egy kisebb cégnek sem kell feltétlenül bonyolult rendszert építenie, de legyen központi hely, ahol az események visszakereshetők.
Mentésről sem csak adatbázisok esetén kell beszélni. A Kubernetes manifestek, Helm chartok, konfigurációk és secret-kezelési folyamatok dokumentációja ugyanúgy részei a helyreállításnak. Ha egy klasztert újra kell építeni, fontos kérdés: reprodukálható-e a környezet, vagy kézi beállításokra és emlékezetre támaszkodik a csapat?
Mit érdemes KKV-ként először megvalósítani?
Ha nincs külön biztonsági csapat, célszerű priorizálni. Első körben legyen rendben az RBAC, a konténerképek ellenőrzése, a root nélküli futtatás, az API-hozzáférés korlátozása és a naplózás. Ezekkel már jelentősen csökkenthető a leggyakoribb hibákból eredő kockázat.
A Kubernetes biztonság nem egyszeri projekt, hanem folyamatos üzemeltetési gyakorlat. Minden új alkalmazás, pipeline, integráció és felhős szolgáltatás módosíthatja a kockázati képet. A legjobb megközelítés az, ha a biztonsági ellenőrzések beépülnek a fejlesztési és üzemeltetési folyamatokba: automatizált image scan, szabályozott jogosultságkezelés, verziókezelt konfigurációk és rendszeres felülvizsgálat. Így a Kubernetes nem csak rugalmas platform, hanem megbízható üzleti alap is lehet egy KKV számára.
