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.

Runtime Security & Monitoring

• 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.

Image Security & Supply Chain

• 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.

Registry-Sicherheit

• 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.

Network Security

• 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.

Secrets Management

• 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.

CIS Docker Benchmark

• 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.

Isolation durch zusätzliche Schichten

• 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.

Integration in CI/CD

• 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.

Kubernetes-Sicherheitsaspekte

• 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.