Konténer-biztonság.

01A lényeg 30 másodpercben

A konténer-biztonság nem egy termék, hanem rétegek — a 4C modell szerint: Cloud, Cluster, Container, Code. A védelem annyira erős, mint a leggyengébb réteg. A legnagyobb hatású alapok: minimal/distroless image, nem-root futtatás, image-szkennelés + SBOM, aláírás (cosign) + admission control, és runtime-védelem (Falco) + hálózati policy.

A jó hír: néhány alapelv a kihasználható támadási felület döntő részét megszünteti — és ezek nagyrészt a build-folyamatba (CI) és a klaszter-policy-kba építhetők, vagyis utána automatikusan érvényesülnek. Nem kell külön „biztonsági projekt", a pipeline-ba kell tenni.

A konténer kényelmes — de a védelem csak annyira erős, mint a leggyengébb réteg. Ezért mind a négy C-t kezelni kell, nem csak az image-szkennelést.

02A 4C modell

A konténeres biztonság négy egymásra épülő rétege — kívülről befelé, mindegyik az előzőre támaszkodik:

03Mit jelent rétegenként?

• Cloud — a felhő/infra biztonsága: IAM, hálózat, titkok, naplózás (ez a többi alapja).
• Cluster — a Kubernetes megerősítése: RBAC, namespace-izoláció, admission control, hálózati policy, etcd-titkosítás.
• Container — az image és a futtatás: minimal alap, nem-root, read-only FS, szkennelt és aláírt image.
• Code — az alkalmazás: függőség-kezelés, titkok kódból kivéve, biztonságos fejlesztés (SAST/dependency scan).

04Az image megerősítése

A legtöbb konténeres kockázat az image-ből és a futtatási módból ered. A néhány legfontosabb alapelv:

• Minimal / distroless alap-image — kevesebb csomag = kevesebb sebezhetőség és kisebb felület (nincs shell, csomagkezelő).
• Nem-root felhasználó + read-only fájlrendszer + a felesleges Linux-capabilities eldobása.
• Csak a szükséges portok, semmi felesleges szolgáltatás az image-ben.
• Titkok kívülről injektálva (secret manager / Kubernetes Secret), sosem az image-be vagy a kódba égetve.
• Pinned, megbízható alap-image (konkrét digest, nem `latest`), rendszeres újraépítéssel.

05Ellátási lánc: szkennelés, SBOM, aláírás

A konténeres támadások egyre inkább az ellátási láncot célozzák. Három eszköz adja az átláthatóságot és a bizalmat:

• Image-szkennelés (Trivy, Grype) — ismert CVE-k keresése build közben (CI) és a registry-ben.
• SBOM (Software Bill of Materials) — az image összetevőinek tételes jegyzéke; új CVE-nél azonnal látszik, érintett vagy-e.
• Aláírás (Sigstore cosign) — kriptográfiai igazolás, hogy az image a megbízható build-ből származik és nem módosították.

A klaszter belépési pontján az admission control (Kyverno, OPA Gatekeeper) kikényszeríti: csak aláírt, szkennelt, nem-root image futhat, kötelező limits, tiltott privileged mód. Így a szabályt sértő konténer el sem indul.

06A támadási felület csökkentése lépésenként

A lépések halmozottan csökkentik a kihasználható felületet. Indikatív, relatív hatás:

07Runtime-védelem és hálózat

A build- és deploy-idejű védelem után a futó konténert is figyelni kell. A runtime-biztonság (Falco) valós időben észleli a gyanús viselkedést: váratlan shell-indítás, jogosultság-emelés, érzékeny fájl-hozzáférés, szokatlan hálózati kapcsolat. A hálózati policy-k (Kubernetes NetworkPolicy) korlátozzák, mely pod melyikkel kommunikálhat — alapértelmezett tiltással, hogy egy kompromittált konténer ne tudjon szabadon terjedni (lateral movement).

Ehhez tartozik a megfigyelhetőség: a biztonsági események gyűjtése és riasztása — itt kapcsolódik a monitoring/observability és a 24/7 NOC.

08Hogyan vezesd be?

Nem egyszerre. A reális sorrend a legnagyobb hatású, legolcsóbb lépésektől:

1. Minimal/distroless image + nem-root futtatás (azonnali, nagy hatású).
2. Image-szkennelés a CI-ben (build megbukik kritikus CVE-nél) + SBOM.
3. Admission control policy-k (nem-root, limits, no-privileged kikényszerítése).
4. Image-aláírás (cosign) + csak aláírt image engedélyezése.
5. Hálózati policy-k (default deny) + runtime-védelem (Falco) + riasztás.

Kapcsolódó: a klaszter költség- és üzemeltetési oldala a Kubernetes költségoptimalizálás cikkben; a megfelelőségi keret a NIS2 és az ISO 27001 oldalakon.

09Gyakran ismételt kérdések

Mi a 4C modell?

A konténer-biztonság négy rétege: Cloud, Cluster, Container, Code — egymásra épülve. A védelem a leggyengébb réteggel egyenlő.

Mi a leghatékonyabb első lépés?

Minimal/distroless alap-image + nem-root futtatás — ez szünteti meg a kihasználható felület legnagyobb részét, és olcsó.

Mi az SBOM és miért kell?

Az image összetevőinek tételes jegyzéke — egy új CVE megjelenésekor azonnal látszik, érintett vagy-e.

Hogyan akadályozom meg a nem megbízható image futását?

Image-aláírás (cosign) + admission control (Kyverno/OPA): csak aláírt, szkennelt, policy-konform image indulhat el.

Hogyan csökkenthető egy konténer támadási felülete?

A legnagyobb hatású lépések: minimal vagy distroless alap-image (kevesebb csomag = kevesebb sebezhetőség), nem-root felhasználóként futtatás és read-only fájlrendszer, a felesleges képességek (capabilities) eldobása, csak a szükséges portok, és a titkok (secret) kívülről injektálása (sosem az image-be égetve). Ez a néhány alapelv a sebezhetőségek és a kihasználható felület döntő részét megszünteti.

Mi a runtime-biztonság konténereknél?

A build- és deploy-idejű védelem után a futó konténert is figyelni kell: a runtime-biztonság (pl. Falco) valós időben észleli a gyanús viselkedést — váratlan shell-indítás, jogosultság-emelés, érzékeny fájl-hozzáférés, szokatlan hálózati kapcsolat. A hálózati policy-k (Kubernetes NetworkPolicy) pedig korlátozzák, mely pod melyikkel kommunikálhat — alapértelmezett tiltással, hogy egy kompromittált konténer ne tudjon szabadon terjedni (lateral movement).

10Erősítsük meg a konténeres rendszered

Felmérjük a jelenlegi konténeres és Kubernetes-felállásod biztonságát (image-ek, klaszter-konfig, hálózat, runtime), és felépítjük a hiányzó rétegeket — a CI-be és a klaszter-policy-kba építve, hogy fenntartható legyen — a te csapatod napi munkájába illesztve.