Bezpečnostní zásady v prostředí kontejnerů: Izolace

Proč bezpečnost kontejnerů není jen o Dockeru

Kontejnerizace (Docker, containerd, CRI-O) a orchestrátory (Kubernetes) přinášejí rychlost a škálování, zároveň však zavádějí nové bezpečnostní vektory: sdílený kernel, dynamickou síťovou topologii, komplexní dodavatelský řetězec softwaru a vysokou míru automatizace. Cílem tohoto článku je formulovat ucelené zásady pro bezpečný návrh, build, nasazení a provoz kontejnerů i celých klastrů. Přístup je „defense-in-depth“: od kódu a image přes runtime a síť až po governance a audit.

Model hrozeb v prostředí kontejnerů

• Únik z kontejneru: zneužití capability, jaderných zranitelností nebo mountů k úniku na hostitele.
• Malware v image: podvržené či kompromitované základní image, knihovny, nástroje v buildu.
• Laterální pohyb: prolomení jednoho podu/služby vede k pivotu napříč sítí klastru.
• Exfiltrace tajemství: únik secrets z proměnných prostředí, svazků nebo kubelet metadat.
• Supply-chain útoky: zneužití CI/CD pipeline, slabá verifikace artefaktů, typosquatting v registru.
• Konfigurační chyby: privilegované pody, otevřené dashboardy, špatné RBAC, nešifrované etcd.

Bezpečný dodavatelský řetězec: od kódu po image

• Minimální základní image: distroless, ubi-minimal nebo alpine (pozor na musl kompatibilitu); odstranění kompilátorů, shelů a paketových manažerů v runtime.
• Reproducibilní buildy a SBOM: generujte a ukládejte Software Bill of Materials (CycloneDX/SPDX) pro každý image; mapujte závislosti na CVE.
• Podpisy a atestace: podepisujte image a manifesty (Sigstore/cosign), ukládejte provenance (SLSA), vynucujte verifikaci při pullu (Policy Controller).
• Skener zranitelností: Trivy/Grype/Clair v CI i v registru; fail-the-build při kritických nálezech, ale s risk acceptance workflow.
• Deterministická verze: používejte digesty (@sha256:…) namísto :latest; zapněte tag immutability v registru.
• Izolace buildů: BuildKit/Kaniko bez privilegií, oddělené sítě, „build secrets“ přes --secret (nikdy ne COPY do image).

Zásady Dockerfile a runtime hardening

• USER ne-root: definujte neprivilegovaného uživatele; vyhněte se root v runtime.
• Read-only filesystem: používejte readOnlyRootFilesystem, zapisovat jen do explicitních svazků.
• Drop capabilities: ponechte minimální set (typicky vše dropnout a přidat jen nutné); zejména zakázat NET_RAW, SYS_ADMIN.
• Seccomp a LSM: RuntimeDefault seccomp profil, AppArmor/SELinux profily; vyhnout se privileged: true.
• Umístění tajemství: nikdy ne v image; načítejte z tajemných svazků/CSI, ne z env proměnných.
• Healthcheck: definujte HEALTHCHECK pro detekci degradace a rychlejší náhradu podů.

Správa tajemství a klíčů

• Kubernetes Secrets: šifrování v etcd (envelope) s KMS; secret mounty preferujte před env.
• Rotace a nejmenší přístup: krátké TTL, automatická rotace, scoping na namespace a službu.
• Externí trezory: HashiCorp Vault/Cloud KMS; první přístup přes short-lived workload identity (OIDC/JWT audiencing).

Síťová bezpečnost a izolace

• NetworkPolicy: omezte ingress/egress per-pod/namespace; default-deny a výslovné povolení.
• CNI a eBPF: nástroje typu Cilium podporují L3/L7 politiky, audit a viditelnost s nízkou režií.
• mTLS a identity: service mesh (Istio/Linkerd) pro šifrování provozu, peer authentication, autorizaci na úrovni služby.
• Ingress/Egress řízení: WAF, rate-limit, validace headerů; egress gateway s allowlistem cílů.

Kubernetes: politika, standardy a „secure by default“

• Pod Security Standards: používejte úroveň restricted (runAsNonRoot, readOnlyFS, no privilege escalation, limitované capabilities).
• Admission kontrola: OPA Gatekeeper/Kyverno pro vynucení politik (zákaz hostPath, hostNetwork, vyžadovat seccompProfile = RuntimeDefault, resources limity).
• RBAC minimální nutná práva: jemnozrnná Role/RoleBinding; oddělené service accounts na workload.
• Namespace a tenancy: oddělte prostředí (dev/test/prod); LimitRange a ResourceQuota proti „noisy neighbor“ a DoS.
• Šifrování at-rest: etcd pouze přes mTLS, firewalling přístupu, pravidelná rotace certifikátů.
• Kubelet a API server: audit logy, vynucená autentizace/autorizace, vypnutí nepoužívaných admission plugins.

Node a OS hardening

• Minimal host OS: imutabilní buildy (OSTree/Golden Image), pravidelné kernel záplaty, LSM (SELinux enforcing/AppArmor).
• Oddělené runtime: preferujte containerd/CRI-O s aktuální verzí; rootless režim kde dává smysl.
• Sysctl a mounty: zakázat nebezpečné sysctl, nepovolovat hostPID/hostIPC; mounty noexec, nodev, nosuid.
• Přístup na nody: bez SSH (nebo jen přes bastion/SSM), přístup řízen IAM; oddělit control plane a worker nody.

Observabilita, detekce a runtime ochrana

• Runtime senzory: Falco/Tetragon pro detekci podezřelých syscalls (např. exec shelů, změny /proc).
• Audit a tracing: Kubernetes audit logy, mTLS cert rotační logy, OpenTelemetry pro korelaci požadavků.
• Metriky a SLO: event-loop lag (u Node.js), latence p95/p99, chybovost, restart count, OOMKills; alerting na odchylky.

Řízení zranitelností a patch management

• Automatizované skeny: každá nová image i běžící workloady; kontinuální re-skan při nových CVE.
• Rychlá obměna: rolling update s krátkou dobou „mean time to patch“; staré pody prunujte.
• Politika pro základní image: pravidelná obnova z čerstvých base, rušit snowflake image.

Governance, compliance a dokumentace

• Standardy a benchmarky: CIS Benchmark pro Docker a Kubernetes, vnitřní bezpečnostní standardy.
• Politika přístupu: break-glass účty s časově omezeným přístupem a plným auditem.
• Evidence a schvalování: změny politik přes GitOps, pull-request schvalování, podpisy commitů.

GitOps a supply-chain vynucení

• Git jako jediný zdroj pravdy: Argo CD/Flux; klastry se synchronizují z podepsaných manifestů.
• Policy as Code: Gatekeeper/Kyverno pravidla v repu, review, testy; CI validuje proti politikám.
• ImagePolicyWebhook/Verification: nasazovat pouze podepsané image s požadovanými atestacemi (SBOM, SLSA).

Data a úložiště: bezpečné svazky a CSI

• CSI ovladače: vyžadujte mTLS a autorizaci; izolace svazků po PVC a namespace.
• Šifrování: šifrujte per-volume (cloud KMS), správa klíčů mimo klastr; off-site zálohy a testy obnovy.
• FS oprávnění: fsGroup, readOnly mounty, zákaz hostPath s výjimkou řízených případů.

Škálování, dostupnost a odolnost

• Resource limity: nastavte requests a limits; předejdete OOM a DoS uvnitř klastru.
• Disrupční rozpočty: PodDisruptionBudget a topology spread constraints pro HA.
• Rate limiting a backpressure: chrání backendy; circuit breaker v service mesh.

Testování a validace bezpečnosti

• Konfigurační testy: kube-bench, kubescape, polaris pro statickou analýzu manifestů.
• Penetrační testy: simulace útoku uvnitř podu (podmínky útěku), laterální pohyb, exfiltrace.
• Chaos a DR cvičení: simulace výpadků nodů, ztráty etcd snapshotu, test obnovy z etcd/registry záloh.

Incident response a forenzní připravenost

• Forenzní postupy: okamžitý snapshot podu (ephemeral kontajnery), uložení /proc, síťových spojení, image digestů.
• Izolace: network policy do izolace, škrcení replik, pozastavení CI rolloutů.
• Post-mortem: bez obviňování; kořenová příčina, aktualizace politik, přidání testů a alertů.

Metriky a KPI bezpečnosti kontejnerů

• MTTP/MTTR pro CVE: doba detekce a opravy kritických zranitelností v image.
• Policy compliance rate: podíl workloadů v režimu restricted, % podepsaných image, % podů s readOnlyFS.
• Secret hygiene: výskyt tajemství v env vs. volume, průměrné TTL, míra rotace.
• Network exposure: % namespace s default-deny, počet povolených egress destinací.

Kontrolní seznam pro bezpečné nasazení

• Image je z minimálního base, podepsaný a se SBOM; používá digest, ne :latest.
• Manifest odpovídá restricted PSS: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false, seccompProfile: RuntimeDefault.
• RBAC a ServiceAccount mají pouze potřebná oprávnění; automountServiceAccountToken: false kde není třeba.
• NetworkPolicy s default-deny a explicitními povoleními; mTLS mezi službami.
• Secrets jsou v KMS-šifrovaných Secrets nebo externím trezoru; žádná tajemství v image ani v logách.
• Resource requests/limits definované; PDB a readiness/liveness pro self-healing.
• Audit logy, metriky a alerty aktivní; runtime detekce anomálií (Falco) nasazena.
• Etcd a API server zabezpečené mTLS, audit zapnutý; nody hardenované a oddělené.

Závěr: bezpečnost jako průběžná schopnost

Bezpečnost kontejnerů není jednorázový checklist, ale soubor návyků: kurátorovaný supply chain, minimální oprávnění, politiky vynucené automatizací, průběžné skenování a pozorovatelnost. Kombinací hardeningu image i runtime, síťových a datových kontrol, robustní správy tajemství a řízení zranitelností dosáhnete prostředí, které je odolné vůči moderním útokům a současně zachovává rychlost a pružnost, kvůli nimž jste kontejnerizaci zvolili.