Was ist Container-Security?

Was ist Container-Security?

Container-Security ist die Disziplin des Schutzes containerisierter Anwendungen und der Infrastruktur, auf der sie laufen, über den gesamten Lebenszyklus: Image-Build, Registry-Storage, Deployment, Runtime-Ausführung und Orchestrierung. Da Container (Docker, OCI, containerd) und Kubernetes das dominante Deployment-Substrat für Cloud-native Anwendungen geworden sind, ist Container-Security zu einer distinkten Sub-Spezialität innerhalb der Cloud-Security geworden — distinkt, weil Container Angriffsflächen einführen, die VMs und Bare-Metal nicht haben (geteilter Kernel, Image-Supply-Chain, ephemere Workloads, schnelle Änderungsraten).

Container zu kompromittieren wird für Angreifer zunehmend attraktiv. Crypto-Miner, injiziert über verwundbare Container-Images, Supply-Chain-Angriffe via vergiftete Base-Images auf Docker Hub, Escape-Exploits gegen den Kernel aus einem Container heraus, laterale Bewegung durch einen Kubernetes-Cluster — alles sind echte, dokumentierte Bedrohungen 2026. Das Defense-in-Depth-Modell für Container umfasst Image-Scanning, Registry-Policies, Runtime-Detection, Netzwerk-Segmentierung und Host-Hardening.

Die fünf Schichten der Container-Security

1. Image-Security (Build-Time)

Das Fundament. Schwachstellen in Container-Images werden von jedem Workload geerbt, der sie nutzt.

• Nutze minimale Base-Images (Distroless, Alpine, Scratch) — weniger Pakete = weniger CVEs.
• Pinne spezifische Versionen, nicht latest. Pinne nach Digest (sha256), nicht Tag.
• Scan während Build mit Trivy, Grype, Snyk, Anchore, Docker Scout. Lasse Builds bei kritischen CVEs fehlschlagen.
• Nicht als Root laufen. Füge USER nonroot im Dockerfile hinzu.
• Schließe keine Secrets in Images ein. Nutze Mount-Time-Injection.
• Signiere Images mit cosign oder Notary. Verifiziere Signaturen beim Deploy.

2. Registry-Security

Wo gebaute Images leben. Kompromiss hier = Supply-Chain-Angriff.

• Nutze eine private Registry (ECR, GCR, ACR, Harbor) mit IAM-kontrolliertem Zugriff.
• Kontinuierliches Scanning gespeicherter Images (CVEs werden nach Push entdeckt).
• Beschränke Pulls nach IP / VPC / Service-Account.
• Audit-Logs für wer was pushte und pullte.

3. Runtime-Security

Was der Container tut, sobald er läuft. Der aktivste Forschungsbereich 2026.

• Droppe Linux-Capabilities; Default ist exzessiv. Nutze capabilities: { drop: ["ALL"] } und füge nur hinzu, was nötig ist.
• Read-Only-Root-Filesystem (readOnlyRootFilesystem: true) — die meisten Apps können damit laufen.
• Seccomp + AppArmor / SELinux-Profile, um Syscalls zu begrenzen.
• Runtime-Detection: Falco, Sysdig, Aqua, Sysdig Secure erkennen anomales Verhalten (Shell-Ausführung in Production-Containern, ungewöhnliche Netzwerkverbindungen).
• Keine privilegierten Container in Production. privileged: true ist im Wesentlichen äquivalent zu Root auf dem Host.

4. Orchestrierungs- / Kubernetes-Security

Kubernetes ist der dominante Orchestrator und an sich eine tiefe Angriffsfläche.

• RBAC: Least-Privilege-Service-Accounts. Die meisten Pods brauchen kein Cluster-Admin.
• NetworkPolicies: Default-Deny-Ingress und Egress, dann nur erlauben, was nötig ist.
• Pod Security Standards (ersetzen PodSecurityPolicies): Restricted-Profil als Default.
• Admission-Controller (OPA, Kyverno), um Policies zur Deploy-Zeit zu erzwingen.
• Audit-Logging auf dem API-Server.
• Anonymen Zugriff deaktivieren, Kubelet-API-Hardening.

5. Host-Security

Das OS unter den Containern.

• Halte Kernel gepatcht (Kernel-CVEs ermöglichen Container-Escapes).
• Nutze gehärtete OSes (Bottlerocket, Talos, CoreOS) — minimal, immutable.
• SSH in Production deaktiviert (nutze Just-in-Time-Zugriff via Tools wie Teleport oder AWS SSM).
• Host-Level-Intrusion-Detection (auditd, eBPF-basiertes Monitoring).

Das Container-Threat-Model: was Angreifer tatsächlich tun

• Verwundbare Image-Ausnutzung. Angreifer scannt deine Registry, findet eine CVE in deiner nginx-Version, nutzt sie aus.
• Supply-Chain. Ein populäres Base-Image auf Docker Hub wird kompromittiert; jedes Downstream-Image erbt die Backdoor.
• Container-Escape. Kernel-Exploit (Dirty Pipe, Dirty COW historisch) gibt Root auf Host von innerhalb des Containers.
• Fehlkonfiguriertes Kubernetes. Exponierte Kubelet-API, Default-Service-Account mit zu vielen Permissions oder anonymer Cluster-Admin aktiviert.
• Crypto-Mining-Injection. Kompromittiertes Image / Runtime verwandelt deinen Cluster in eine Mining-Farm. Häufig wegen wirtschaftlicher Anreize.
• Laterale Bewegung. Initiale Kompromittierung eines Pods → Zugang zu geteilten Service-Accounts → Zugang zu anderen Pods → Zugang zur Cluster-Control-Plane.
• Secrets-Leakage. Secrets als Environment-Variables gespeichert, sichtbar in kubectl describe pod für jeden mit Read-Zugriff.

Häufige Container-Security-Fehler

• Default als Root laufen. Die meisten Container-Images laufen als Root, es sei denn, explizit anders gesagt. Nutze Non-Root-User in Dockerfiles.
• :latest in Production pullen. Ein neues "latest" kann jederzeit gepusht werden. Nutze spezifische Tags oder Digests.
• Privilegierte Container "weil es einfacher ist". privileged: true negiert die meiste Container-Isolation. Nutze stattdessen spezifische Capabilities.
• Kein Image-Scanning in CI. Schwachstellen shippen unentdeckt zu Prod. Füge Trivy / Grype zu deiner Pipeline hinzu.
• Offener Egress. Default-Kubernetes-Networking lässt kompromittierte Pods nach Hause telefonieren, Daten exfiltrieren, interne Services scannen. Nutze NetworkPolicies.
• Service-Accounts über Pods teilen. Ein kompromittierter Pod erhält Zugang zu allem, was dieser Account tun kann. Pro-Workload-Service-Accounts.
• Secrets in Env-Vars ohne Rotation speichern. Sichtbar in Describe-Output, im Container-Env, in Logs. Nutze Kubernetes-Secrets mit Verschlüsselung at Rest oder externe Secret-Manager (Vault, AWS Secrets Manager).
• Der Registry ohne Verifikation vertrauen. Signiere Images und verifiziere Signaturen. Sonst kann ein Angreifer, der deine Registry kompromittiert, alles injizieren.

FAQ: Container-Security

Was ist die häufigste Container-Schwachstelle 2026?

Veraltete Base-Images, die bekannte CVEs tragen. Die meisten Container-Images leiten sich von Base-Images ab, in denen seit der ursprünglichen Veröffentlichung Schwachstellen entdeckt wurden. Kontinuierliches Re-Scanning fängt das; periodische Rebuilds patchen es.

Sind Container mehr oder weniger sicher als VMs?

Container teilen den Host-Kernel, also betreffen Kernel-Exploits alle Container; VMs haben Hardware-assistierte Isolation. Aber Container haben kleinere Angriffsflächen (kein volles OS pro Workload), schnellere Patch-Zyklen und besseres Tooling für Image-Level-Scanning. Net-Bewertung: vergleichbare Sicherheit mit verschiedenen Tradeoffs, wenn beide gut konfiguriert sind.

Brauche ich ein Runtime-Security-Tool wie Falco?

Für Production im Maßstab, ja. Falco / Sysdig / Aqua erkennen anomales Verhalten (Container, der Shell ausführt, Container, der unerwartete Netzwerkverbindungen macht), das Build-Zeit-Scanning nicht kann. Für Staging und kleine Cluster ist Überspringen vernünftig.

Was ist mit Kubernetes-Security speziell?

Behandle deinen Cluster als Multi-Tenant-Sicherheitsgrenze, auch wenn du noch keine Multi-Tenancy hast. RBAC, NetworkPolicies, Pod Security Standards, Admission-Controller, Audit-Logs. CIS Benchmarks für Kubernetes ist die kanonische Hardening-Checklist.

Wie sichere ich die Supply-Chain ab?

Signiere Images beim Build (cosign), verifiziere Signaturen bei Admission (Sigstore-Policy-Controller), nutze SBOMs (CycloneDX, SPDX), um zu tracken, was in jedem Image ist, scanne Registries kontinuierlich. Das SLSA-Framework definiert Reifegrade für Supply-Chain-Security.

Brauche ich ein CSPM-Tool?

Für Multi-Cloud-Kubernetes-Deployments helfen Cloud-Security-Posture-Management-Tools (Wiz, Orca, Prisma Cloud), Fehlkonfigurationen über Cluster zu tracken. Für Single-Cloud-Single-Cluster genügen native Tools (AWS Inspector, GCP Security Command Center).

Was ist mit Serverless-Containern?

AWS Fargate, Google Cloud Run, Azure Container Apps reduzieren Host-Security auf die Verantwortung der Plattform, aber Image-Security und Runtime-Security gelten weiterhin. Die Supply-Chain-Geschichte ist unverändert.

Wie LoadFocus zu Container-Security steht

Containerisierte Anwendungen müssen Security-Validierung unter realistischer Last handhaben — langsame Security-Middleware (Auth-Proxies, mTLS-Terminatoren, WAFs) wird oft zum Bottleneck unter Traffic. LoadFocus-Lasttest validiert, dass gehärtete Security-Stacks (mit allen aktivierten Runtime-Security-Agenten) weiterhin Latenz-Ziele im Production-Maßstab erfüllen. API-Monitoring trackt Pro-Endpoint-Latenz kontinuierlich und fängt, wenn ein Security-Update-Degradation Production trifft.