Grundlagen der Containersicherheit: Arbeitsbelastung

Wenn Sie gerade erst in diese Serie einsteigen, möchten Sie vielleicht am Anfang beginnen: 
Grundlagen der Containersicherheit: Einführung
Grundlagen der Containersicherheit: Pipeline
Grundlagen der Containersicherheit: Orchestrierung

„Workload“ ist ein relativ neuer Begriff, der häufig zur Beschreibung von Applications verwendet wird, sich aber auch auf Infrastrukturdienste beziehen kann. Das ist wichtig, da in Ihren Container-Clustern eine Vielzahl von „Workloads“ ausgeführt werden können, die nicht unbedingt von Ihren Entwicklern stammen. Die Nutzung kostenloser und Open-Source-Dienste für verschiedene Zwecke in Containerumgebungen nimmt zu. Dies trifft eigentlich auf den gesamten IT-Betrieb zu, der im vergangenen Jahr die Kategorie Nummer eins für Downloads von kostenloser und Open-Source-Software war.

Wenn wir also von Workload-Sicherheit sprechen, meinen wir jede Software, die Sie heruntergeladen, entwickelt oder in Ihrer Container-Umgebung bereitgestellt haben. Denken Sie an Consul . Denken Sie an Kubernetes selbst. Denken Sie an Prometheus und Elasticsearch . Denken Sie an NGINX und istio .

Und fügen Sie dieser Liste dann auch alle API-Gateways, Caches und Ingress-Controller hinzu, die Sie zur Unterstützung Ihrer Kubernetes-Umgebung bereitgestellt haben. Aus diesem Grund ist eine gründliche Stückliste wichtig und eine regelmäßige Bestandsaufnahme ist für die Aufrechterhaltung einer sicheren Umgebung von entscheidender Bedeutung.

Sobald Sie Ihre Liste haben, ist es an der Zeit, die wichtigsten Sicherheitsprobleme der Arbeitslast anzugehen.

• 1. Authentifizierung ist nicht optional
  Wenn Sie diese ganze Serie verfolgt haben, ist das für Sie ein alter Hut. Dies ist eines der gemeinsamen Themen in allen Aspekten der Containersicherheit: Schließen Sie die Vordertür ab.
  
  Alle diese Dienste werden als Workloads in einem Cluster ausgeführt. Das bedeutet oft Standardanmeldeinformationen oder eine „offene“ Anfangskonfiguration für den Zugriff auf APIs und Daten. Die Workload-Sicherheit umfasst alle Komponenten, Software und Application , die für die Funktionalität und den Betrieb der Application erforderlich sind. 
  
  

• 2. Schädlicher Inhalt ist bösartig
  Auch wenn Sie die Tür durch die Anforderung von Anmeldeinformationen und die Anwendung einer Zugriffskontrolle verschlossen haben, müssen Sie sich weiterhin um schädliche Inhalte sorgen. Dies gilt für genutzte Applications, Microservices und Betriebsdienste. Alle Workloads, die eine Schnittstelle zu einem Benutzer (Betreiber oder Verbraucher) darstellen, sind potenziell gefährdet.

  Hier ist Scannen und Handeln ein Muss. Der erste Schritt besteht darin, Schwachstellen in der Application zu finden – sei es von HTTP oder der Application . Sobald Sie sie gefunden haben, ist es Zeit, etwas dagegen zu unternehmen. Wenn es sich um eine benutzerdefinierte App handelt, senden Sie sie zur Entwicklung zurück. Wenn es sich um eine Komponente eines Drittanbieters handelt, stellen Sie fest, ob eine gepatchte/aktualisierte Version vorhanden ist. Komponenten von Drittanbietern werden häufig in Container-Images bereitgestellt und wie Snyk in seinem Bericht „State of Open Source Security“ von 2019 feststellte, weisen 44 % von ihnen bekannte Schwachstellen auf , für die neuere und sicherere Basis-Images verfügbar sind .
  
  Noch einmal: Das Ausführen eines Scans trägt nicht zur Verbesserung der Sicherheit bei, wenn Sie keine Abhilfe schaffen.
  
  Wenn Sie ein Loch in Ihrer Wand haben, durch das potenzielle Einbrecher die verschlossenen Türen leicht umgehen könnten, sollten Sie dieses flicken. Flicken Sie also die virtuellen Löcher in Ihren virtuellen Wänden.
  
  Der Einsatz einer Web Application Firewall oder eines API-Sicherheitsgateways kann eine Abhilfe schaffen, wenn Schwachstellen nicht sofort von Entwicklern behoben werden können oder noch von Drittanbietern behoben werden müssen.
  
  Dies lässt sich am besten mit „Überprüfen Sie Ihre Anrufe“ zusammenfassen, da es darum geht, Anfragen zu jeder Arbeitslast zu prüfen und zu bewerten, bevor diese angenommen werden.
  
  
• 3. Gemeinsame Ressourcen bedeuten gemeinsames Risiko
  Wie bei der herkömmlichen Virtualisierung sind Container nicht vollständig isoliert. Container teilen sich letztendlich dasselbe physische Betriebssystem. Das bedeutet, dass Schwachstellen im gemeinsam genutzten Betriebssystem auch gemeinsam genutzte Schwachstellen bedeuten.

Wenn es einem Angreifer gelingt, eine Schwachstelle in Betriebssystemkomponenten auszunutzen, kann er eine oder mehrere Workloads kompromittieren. Diese Schwachstellen können auftreten, wenn die Tür nicht abgeschlossen oder die Anrufe nicht überwacht werden. Dies ist kein weit hergeholtes Szenario, wie wir bei CVE-2019-5736 gesehen haben, bei dem eine Runc-Sicherheitslücke auf Betriebssystemebene das Internet in Panik versetzte. 

Das zentrale Sicherheitsprinzip wurde hier von Dan Walsh, Guru der Containersicherheit von SELinux und RedHat, folgendermaßen formuliert : „Container enthalten nicht“ . 

Es ist wichtig zu beachten, dass der gesamte Netzwerkverkehr mit Diensten und Benutzern außerhalb des Knotens das Host-Betriebssystem durchlaufen muss. Die Vernetzung zwischen Pods und Containern auf einem Knoten erfolgt über virtuelle Vernetzung mit virtuellen Brücken und geschickter Nutzung von iptables. Aber letztendlich muss der Datenverkehr diesen physischen Knoten verlassen, und das bedeutet, dass er auf dem Host-Betriebssystem verarbeitet wird. Agenten, Plug-Ins und andere Daemons beobachten oder erfassen diesen Datenverkehr möglicherweise aus Sicherheits- oder Sichtbarkeitsgründen. Dabei handelt es sich um potenzielle Schwachstellen, die Sie der Bestandsaufnahme hinzufügen sollten, die Sie nach der Lektüre über Pipeline Security begonnen haben zu erstellen.

• 4. Protokollierung vertraulicher Daten
  Sie haben bei einer Diskussion zur Containersicherheit vielleicht nicht damit gerechnet, dass auch eine Warnung zu Protokollen dabei ist. Aber das ist so, und zwar deshalb, weil in Protokolldateien manchmal vertrauliche Informationen landen. Autorisierungstoken, Schlüssel des Verschlüsselungsanbieters, Anmeldeinformationen. Alles kann versehentlich von Workloads auf stderr protokolliert oder angezeigt werden. Der Grund hierfür liegt häufig darin, dass Probleme aufgrund von Authentifizierungsfehlern aufgespürt werden müssen. Sie sollten die Protokollierung geheimer Daten im System grundsätzlich verhindern – oder, wenn möglich, ganz untersagen.
  
  Um sicherzustellen, dass sich die Entwickler dieses Risikos bewusst sind, sollten Sie einen Leitfaden zur Protokollierungsgestaltung bereitstellen und angeben, was ins Protokoll geschrieben werden darf und was nicht.

Die Workload-Sicherheit in einem Containerkontext ist größtenteils identisch mit der Sicherheit aller anderen Application Workloads, die in Ihrer Produktionsumgebung ausgeführt werden. Kontrollieren Sie den Zugriff und verlangen Sie eine starke Authentifizierung, achten Sie auf schädliche Inhalte und seien Sie sich der Schwachstellen auf gemeinsam genutzter und Plattformebene bewusst.