Erweiterte Aspekte der Container-Sicherheit: Unterschied zwischen den Versionen

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen
(Die Seite wurde neu angelegt: „= Erweiterte Aspekte der Container-Sicherheit = == Container vs. VM – Sicherheitsunterschied == * Erklärung: Container teilen sich den Host-Kernel → ein…“)
 
 
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 1: Zeile 1:
 
= Erweiterte Aspekte der Container-Sicherheit =
 
= Erweiterte Aspekte der Container-Sicherheit =
  
−
== Container vs. VM – Sicherheitsunterschied ==
+
== Container vs. VM – Sicherheitsmodell verstehen ==
−
* Erklärung: Container teilen sich den Host-Kernel → ein Exploit im Kernel wirkt auf alle Container und den Host.
+
*Container teilen sich den Host-Kernel.
−
* Unterschied: Virtuelle Maschinen sind durch den Hypervisor stärker isoliert, Angriffe bleiben oft innerhalb der VM.
+
*Ein Kernel-Exploit betrifft alle Container und den Host.
−
* Risiko: Container sind „leichter“ und effizienter, aber die Sicherheitsgrenze ist dünner. 
+
*Virtuelle Maschinen sind durch den Hypervisor stärker isoliert.
−
* Lehre: Container ersetzen keine VM-Isolation, sondern ergänzen sie – besonders kritisch in Multi-Tenant-Umgebungen.
+
*Container bieten Prozessisolation – keine vollständige Systemisolation.
  
−
== Runtime Security & Monitoring ==
+
;Risiko
−
* Erklärung: Image-Scanning deckt nur bekannte Schwachstellen ab, nicht Angriffe zur Laufzeit.
+
*Container Escape → Zugriff auf Host-System.
−
* Tools: Falco, Sysdig Secure, Aqua Security → erkennen verdächtige Aktionen (z. B. Shell-Spawn, Zugriff auf /etc/passwd).
+
*Privilegierte Container können Host kompromittieren.
−
* Vergleich: IDS/IPS – nur speziell für Container und Kubernetes.
+
*Multi-Tenant-Umgebungen besonders kritisch.
−
* Best Practice: Runtime Security mit SIEM (z. B. Wazuh, ELK, Splunk) koppeln, um Events zu korrelieren.
+
 
 +
;Lehre
 +
*Container sind kein Ersatz für Isolation durch VMs.
 +
*In Cloud-Umgebungen häufig Kombination aus VM + Container.
 +
 
 +
 
 +
== Angriffsszenario – Container Escape ==
 +
;Ausgangslage
 +
*Container läuft mit erweiterten Rechten.
 +
*--privileged oder CAP_SYS_ADMIN gesetzt.
 +
*Host-Dateisystem gemountet.
 +
 
 +
;Angriff
 +
*Exploit im Kernel oder Missbrauch von Capabilities.
 +
*Zugriff auf /proc oder /var/run/docker.sock.
 +
*Start weiterer Container mit Root-Rechten.
 +
 
 +
;Auswirkung
 +
*Übernahme des Hosts.
 +
*Manipulation anderer Container.
 +
*Persistente Hintertür.
 +
 
 +
;Gegenmaßnahmen
 +
*Keine privilegierten Container.
 +
*Capabilities minimal halten.
 +
*User Namespace aktivieren.
 +
*Rootless Container nutzen.
 +
 
 +
 
 +
== Runtime Security – Angriff zur Laufzeit ==
 +
*Image-Scanning erkennt nur bekannte CVEs.
 +
*Angriffe zur Laufzeit bleiben unentdeckt ohne Monitoring.
 +
 
 +
;Typische Anomalien
 +
*Shell-Spawn innerhalb eines Containers.
 +
*Zugriff auf /etc/shadow oder Host-Mounts.
 +
*Outbound-Verbindungen zu Command-and-Control-Servern.
 +
 
 +
;Maßnahmen
 +
*Runtime-Monitoring (z. B. Falco-Regeln).
 +
*System-Call-Überwachung.
 +
*Events ins SIEM einspeisen.
 +
*Alarmierung bei ungewöhnlichem Verhalten.
 +
 
 +
 
 +
== Supply-Chain-Angriffe ==
 +
;Risikoquelle
 +
*Unsichere Basis-Images.
 +
*Trojanisierte Images aus öffentlichen Registries.
 +
*Manipulierte Abhängigkeiten (npm, pip).
 +
 
 +
;Angriff
 +
*Entwickler zieht manipuliertes Image.
 +
*Backdoor wird mitdeployt.
 +
*Angreifer erhält Zugriff auf Produktionsumgebung.
 +
 
 +
;Gegenmaßnahmen
 +
*Nur vertrauenswürdige Registries.
 +
*Image-Signaturen prüfen.
 +
*SBOM erzeugen und validieren.
 +
*Automatisches Scanning in CI/CD.
  
−
== 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 ==
 
== Registry-Sicherheit ==
−
* Erklärung: Container-Images liegen oft in privaten oder öffentlichen Registries.
+
*Registry ist zentrale Vertrauensquelle.
−
* Risiko: Unsichere Registries können manipulierte oder Backdoored-Images ausliefern.
+
*Manipulierte Registry = manipulierte Infrastruktur.
−
* Best Practice: 
+
 
−
** TLS-gesicherte Kommunikation.
+
;Risiken
−
** Authentifizierung und RBAC für Push/Pull.
+
*Unverschlüsselte Push/Pull-Verbindungen.
−
** Pull-Policies definieren („always“ vs. „ifNotPresent“).
+
*Keine Authentifizierung.
−
* Lehre: Registry-Sicherheit ist genauso wichtig wie Image-Sicherheit.
+
*Übermäßige Schreibrechte.
 +
 
 +
;Maßnahmen
 +
*TLS erzwingen.
 +
*RBAC für Push und Pull.
 +
*Image-Immutable-Tags nutzen.
 +
*Audit-Logs aktivieren.
 +
 
 +
 
 +
== Netzwerksegmentierung ==
 +
*Standard-Bridge erlaubt Ost-West-Traffic.
 +
*Container können sich gegenseitig erreichen.
 +
 
 +
;Risiken
 +
*Laterale Bewegung.
 +
*Pivot zwischen Microservices.
 +
 
 +
;Maßnahmen
 +
*User-Defined Networks.
 +
*Kubernetes NetworkPolicies.
 +
*Service Mesh mit mTLS.
 +
*Zero-Trust-Prinzip auch intern.
  
−
== 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 ==
 
== Secrets Management ==
−
* Erklärung: Zugangsdaten dürfen nicht im Image oder in ENV-Variablen landen.
+
*Secrets dürfen nicht im Image oder ENV-Variablen liegen.
−
* Risiko: Jeder mit Zugriff auf „docker inspect“ oder „kubectl describe pod“ sieht ENV-Variablen.
+
 
−
* Best Practice: 
+
;Risiko
−
** HashiCorp Vault, Kubernetes Secrets, SOPS.
+
*docker inspect zeigt Umgebungsvariablen.
−
** Zugriff nur temporär, Rotation von Secrets automatisieren.
+
*kubectl describe pod offenbart Secrets.
−
* Beispiel: API-Key im Image = kompletter Cloud-Account kompromittiert.
+
*Leaked API-Key → Cloud kompromittiert.
 +
 
 +
;Maßnahmen
 +
*Secrets Manager oder Vault einsetzen.
 +
*Temporäre Tokens.
 +
*Automatische Rotation.
 +
*Minimaler Zugriff pro Service.
 +
 
 +
 
 +
== Kubernetes als Verstärker ==
 +
*Docker ist nur Basis.
 +
*Kubernetes erweitert Angriffsfläche.
 +
 
 +
;Risiken
 +
*Offener API-Server.
 +
*Fehlendes RBAC.
 +
*Überprivilegierte ServiceAccounts.
 +
*Unsichere Helm-Charts.
 +
 
 +
;Angriff
 +
*Kompromittierter Pod liest ServiceAccount-Token.
 +
*Token erlaubt Cluster-weite Aktionen.
 +
*Deployment manipuliert.
 +
 
 +
;Maßnahmen
 +
*RBAC strikt definieren.
 +
*PodSecurityStandards erzwingen.
 +
*Admission Controller einsetzen.
 +
*Audit-Logs überwachen.
  
−
== 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 ==
 
== Isolation durch zusätzliche Schichten ==
−
* Erklärung: Zusätzliche Sandbox-Ansätze reduzieren die Angriffsfläche.
+
*Container-Isolation kann verstärkt werden.
−
* Beispiele: 
+
 
−
** gVisor (Google) – Userspace-Kernel-Sandbox.
+
;Beispiele
−
** Kata Containers – Container laufen in leichten VMs.
+
*gVisor – Userspace-Kernel.
−
** Firecracker – von AWS für MicroVMs entwickelt.
+
*Kata Containers – Container in Micro-VM.
−
* Nutzen: Stärkere Isolation, besonders in Public-Cloud- oder Multi-Tenant-Umgebungen.
+
*Firecracker – Minimal-VM-Ansatz.
 +
 
 +
;Nutzen
 +
*Reduzierte Angriffsfläche.
 +
*Stärkere Mandantentrennung.
 +
*Geeignet für Public-Cloud und Multi-Tenant.
  
−
== 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 ==
+
== Kernaussage ==
−
* Erklärung: In Produktion laufen Container fast immer unter Kubernetes, nicht „nackt“ mit Docker.
+
*Container sind effizient – aber keine Sicherheitsgrenze.
−
* Risiken: 
+
*Identität, Isolation und Supply-Chain sind die zentralen Risiken.
−
** Unsicherer API-Server → Angreifer steuern den Cluster.
+
*Runtime-Monitoring ist Pflicht.
−
** Offene kubelet-Ports → Remote Code Execution.
+
*Kubernetes vergrößert die Angriffsfläche erheblich.
−
** Unsichere Helm-Charts → Deployment von fehlerhaften Services. 
+
*Sicherheit muss Teil der CI/CD-Pipeline sein.
−
* 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.
 

Aktuelle Version vom 20. Februar 2026, 16:02 Uhr

Erweiterte Aspekte der Container-Sicherheit

Container vs. VM – Sicherheitsmodell verstehen

  • Container teilen sich den Host-Kernel.
  • Ein Kernel-Exploit betrifft alle Container und den Host.
  • Virtuelle Maschinen sind durch den Hypervisor stärker isoliert.
  • Container bieten Prozessisolation – keine vollständige Systemisolation.
Risiko
  • Container Escape → Zugriff auf Host-System.
  • Privilegierte Container können Host kompromittieren.
  • Multi-Tenant-Umgebungen besonders kritisch.
Lehre
  • Container sind kein Ersatz für Isolation durch VMs.
  • In Cloud-Umgebungen häufig Kombination aus VM + Container.


Angriffsszenario – Container Escape

Ausgangslage
  • Container läuft mit erweiterten Rechten.
  • --privileged oder CAP_SYS_ADMIN gesetzt.
  • Host-Dateisystem gemountet.
Angriff
  • Exploit im Kernel oder Missbrauch von Capabilities.
  • Zugriff auf /proc oder /var/run/docker.sock.
  • Start weiterer Container mit Root-Rechten.
Auswirkung
  • Übernahme des Hosts.
  • Manipulation anderer Container.
  • Persistente Hintertür.
Gegenmaßnahmen
  • Keine privilegierten Container.
  • Capabilities minimal halten.
  • User Namespace aktivieren.
  • Rootless Container nutzen.


Runtime Security – Angriff zur Laufzeit

  • Image-Scanning erkennt nur bekannte CVEs.
  • Angriffe zur Laufzeit bleiben unentdeckt ohne Monitoring.
Typische Anomalien
  • Shell-Spawn innerhalb eines Containers.
  • Zugriff auf /etc/shadow oder Host-Mounts.
  • Outbound-Verbindungen zu Command-and-Control-Servern.
Maßnahmen
  • Runtime-Monitoring (z. B. Falco-Regeln).
  • System-Call-Überwachung.
  • Events ins SIEM einspeisen.
  • Alarmierung bei ungewöhnlichem Verhalten.


Supply-Chain-Angriffe

Risikoquelle
  • Unsichere Basis-Images.
  • Trojanisierte Images aus öffentlichen Registries.
  • Manipulierte Abhängigkeiten (npm, pip).
Angriff
  • Entwickler zieht manipuliertes Image.
  • Backdoor wird mitdeployt.
  • Angreifer erhält Zugriff auf Produktionsumgebung.
Gegenmaßnahmen
  • Nur vertrauenswürdige Registries.
  • Image-Signaturen prüfen.
  • SBOM erzeugen und validieren.
  • Automatisches Scanning in CI/CD.


Registry-Sicherheit

  • Registry ist zentrale Vertrauensquelle.
  • Manipulierte Registry = manipulierte Infrastruktur.
Risiken
  • Unverschlüsselte Push/Pull-Verbindungen.
  • Keine Authentifizierung.
  • Übermäßige Schreibrechte.
Maßnahmen
  • TLS erzwingen.
  • RBAC für Push und Pull.
  • Image-Immutable-Tags nutzen.
  • Audit-Logs aktivieren.


Netzwerksegmentierung

  • Standard-Bridge erlaubt Ost-West-Traffic.
  • Container können sich gegenseitig erreichen.
Risiken
  • Laterale Bewegung.
  • Pivot zwischen Microservices.
Maßnahmen
  • User-Defined Networks.
  • Kubernetes NetworkPolicies.
  • Service Mesh mit mTLS.
  • Zero-Trust-Prinzip auch intern.


Secrets Management

  • Secrets dürfen nicht im Image oder ENV-Variablen liegen.
Risiko
  • docker inspect zeigt Umgebungsvariablen.
  • kubectl describe pod offenbart Secrets.
  • Leaked API-Key → Cloud kompromittiert.
Maßnahmen
  • Secrets Manager oder Vault einsetzen.
  • Temporäre Tokens.
  • Automatische Rotation.
  • Minimaler Zugriff pro Service.


Kubernetes als Verstärker

  • Docker ist nur Basis.
  • Kubernetes erweitert Angriffsfläche.
Risiken
  • Offener API-Server.
  • Fehlendes RBAC.
  • Überprivilegierte ServiceAccounts.
  • Unsichere Helm-Charts.
Angriff
  • Kompromittierter Pod liest ServiceAccount-Token.
  • Token erlaubt Cluster-weite Aktionen.
  • Deployment manipuliert.
Maßnahmen
  • RBAC strikt definieren.
  • PodSecurityStandards erzwingen.
  • Admission Controller einsetzen.
  • Audit-Logs überwachen.


Isolation durch zusätzliche Schichten

  • Container-Isolation kann verstärkt werden.
Beispiele
  • gVisor – Userspace-Kernel.
  • Kata Containers – Container in Micro-VM.
  • Firecracker – Minimal-VM-Ansatz.
Nutzen
  • Reduzierte Angriffsfläche.
  • Stärkere Mandantentrennung.
  • Geeignet für Public-Cloud und Multi-Tenant.


Kernaussage

  • Container sind effizient – aber keine Sicherheitsgrenze.
  • Identität, Isolation und Supply-Chain sind die zentralen Risiken.
  • Runtime-Monitoring ist Pflicht.
  • Kubernetes vergrößert die Angriffsfläche erheblich.
  • Sicherheit muss Teil der CI/CD-Pipeline sein.
Abgerufen von „http://wiki.ixheim.de/index.php?title=Erweiterte_Aspekte_der_Container-Sicherheit&oldid=67174“