Erweiterte Aspekte der Container-Sicherheit

Aus Xinux Wiki
Zur Navigation springen Zur Suche springen

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“