Erweiterte Aspekte der Container-Sicherheit

Container vs. VM – Sicherheitsunterschied

Erklärung: Container teilen sich den Host-Kernel → ein Exploit im Kernel wirkt auf alle Container und den Host.
Unterschied: Virtuelle Maschinen sind durch den Hypervisor stärker isoliert, Angriffe bleiben oft innerhalb der VM.
Risiko: Container sind „leichter“ und effizienter, aber die Sicherheitsgrenze ist dünner.
Lehre: Container ersetzen keine VM-Isolation, sondern ergänzen sie – besonders kritisch in Multi-Tenant-Umgebungen.

Erklärung: Image-Scanning deckt nur bekannte Schwachstellen ab, nicht Angriffe zur Laufzeit.
Tools: Falco, Sysdig Secure, Aqua Security → erkennen verdächtige Aktionen (z. B. Shell-Spawn, Zugriff auf /etc/passwd).
Vergleich: IDS/IPS – nur speziell für Container und Kubernetes.
Best Practice: Runtime Security mit SIEM (z. B. Wazuh, ELK, Splunk) koppeln, um Events zu korrelieren.

Erklärung: Viele Angriffe entstehen durch unsichere oder manipulierte Basis-Images.
Risiken: Veraltete Pakete mit CVEs, trojanisierte Images auf Docker Hub, manipulierte Abhängigkeiten (npm, pip).
Best Practice:
- Nur vertrauenswürdige Registries nutzen (Harbor, Artifactory, ECR).
- Signierte Images (Docker Content Trust, cosign).
- SBOM (Software Bill of Materials) generieren und prüfen.
Tools: Trivy, Grype, Anchore.

Erklärung: Container-Images liegen oft in privaten oder öffentlichen Registries.
Risiko: Unsichere Registries können manipulierte oder Backdoored-Images ausliefern.
Best Practice:
- TLS-gesicherte Kommunikation.
- Authentifizierung und RBAC für Push/Pull.
- Pull-Policies definieren („always“ vs. „ifNotPresent“).
Lehre: Registry-Sicherheit ist genauso wichtig wie Image-Sicherheit.

Erklärung: Container-Netzwerke müssen bewusst segmentiert werden.
Risiken:
- „--net=host“ → Container teilt komplettes Host-Netzwerk, keine Isolation.
- Standard-Bridge-Netzwerke ohne Firewalling = unkontrollierter Ost-West-Traffic.
Best Practice:
- Segmentierung über User-Defined Networks.
- Kubernetes: NetworkPolicies, Service Mesh (z. B. Istio, Linkerd).
- Zero-Trust-Ansatz auch intern.

Erklärung: Zugangsdaten dürfen nicht im Image oder in ENV-Variablen landen.
Risiko: Jeder mit Zugriff auf „docker inspect“ oder „kubectl describe pod“ sieht ENV-Variablen.
Best Practice:
- HashiCorp Vault, Kubernetes Secrets, SOPS.
- Zugriff nur temporär, Rotation von Secrets automatisieren.
Beispiel: API-Key im Image = kompletter Cloud-Account kompromittiert.

Erklärung: Center for Internet Security veröffentlicht detaillierte Härtungsempfehlungen.
Tool: docker-bench-security prüft automatisiert gegen diese Standards.
Nutzen: Basis für Audits, Compliance (ISO 27001, PCI DSS, BSI IT-Grundschutz).
Best Practice: Benchmark regelmäßig laufen lassen, Ergebnisse dokumentieren.

Erklärung: Zusätzliche Sandbox-Ansätze reduzieren die Angriffsfläche.
Beispiele:
- gVisor (Google) – Userspace-Kernel-Sandbox.
- Kata Containers – Container laufen in leichten VMs.
- Firecracker – von AWS für MicroVMs entwickelt.
Nutzen: Stärkere Isolation, besonders in Public-Cloud- oder Multi-Tenant-Umgebungen.

Erklärung: Sicherheit muss Teil der Build-Pipeline sein (Shift Left Security).
Maßnahmen:
- Linting von Dockerfiles (hadolint).
- Image-Scanning (Trivy, Grype).
- Signaturprüfung (cosign, Notary).
- Policy-Checks (OPA, Conftest).
Ziel: Unsichere Container werden gar nicht erst gebaut oder deployed.

Erklärung: In Produktion laufen Container fast immer unter Kubernetes, nicht „nackt“ mit Docker.
Risiken:
- Unsicherer API-Server → Angreifer steuern den Cluster.
- Offene kubelet-Ports → Remote Code Execution.
- Unsichere Helm-Charts → Deployment von fehlerhaften Services.
Maßnahmen:
- RBAC für jede Aktion im Cluster.
- PodSecurityStandards (PSS) oder Admission Controller (OPA Gatekeeper).
- NetworkPolicies für Traffic-Kontrolle.
- Monitoring von Audit-Logs.
Lehre: Kubernetes-Security = eigener Themenblock, Docker ist nur die Basis.