Thomas.will am 20. Februar 2026 um 16:02 Uhr

2026-02-20T16:02:51Z

Thomas.will am 14. September 2025 um 08:37 Uhr

2025-09-14T08:37:17Z

Thomas.will: Die Seite wurde neu angelegt: „= Erweiterte Aspekte der Container-Sicherheit = == Container vs. VM – Sicherheitsunterschied == * Erklärung: Container teilen sich den Host-Kernel → ein…“

2025-09-14T08:37:07Z

Die Seite wurde neu angelegt: „= Erweiterte Aspekte der Container-Sicherheit = == Container vs. VM – Sicherheitsunterschied == * Erklärung: Container teilen sich den Host-Kernel → ein…“

Neue Seite

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

← Nächstältere Version		Version vom 14. September 2025, 08:37 Uhr
Zeile 1:		Zeile 1:
−	~~= Erweiterte Aspekte der Container-Sicherheit =~~
−
	== Container vs. VM – Sicherheitsunterschied ==		== Container vs. VM – Sicherheitsunterschied ==
	* Erklärung: Container teilen sich den Host-Kernel → ein Exploit im Kernel wirkt auf alle Container und den Host.		* Erklärung: Container teilen sich den Host-Kernel → ein Exploit im Kernel wirkt auf alle Container und den Host.

Erweiterte Aspekte der Container-Sicherheit - Versionsgeschichte

Thomas.will am 20. Februar 2026 um 16:02 Uhr

Thomas.will am 14. September 2025 um 08:37 Uhr

Thomas.will: Die Seite wurde neu angelegt: „= Erweiterte Aspekte der Container-Sicherheit = == Container vs. VM – Sicherheitsunterschied == * Erklärung: Container teilen sich den Host-Kernel → ein…“