Grundlagen der Container-Sicherheit: Workloads

Wenn Sie gerade erst in diese Reihe einsteigen, sollten 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 Anwendungen verwendet wird, sich aber auch auf Infrastrukturdienste beziehen kann. Das ist wichtig, da in Ihren Container-Clustern eine Vielzahl von „Workloads“ ausgeführt werden kann, die nicht unbedingt von Ihren Entwicklern stammen. Die Nutzung kostenloser und quelloffener Dienste für verschiedene Zwecke innerhalb von Container-Umgebungen nimmt zu. Dies gilt tatsächlich für den gesamten IT-Betrieb, der im vergangenen Jahr die wichtigste Kategorie für Downloads kostenloser und quelloffener Software war.

Wenn wir also von Workload-Sicherheit sprechen, meinen wir damit 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.

Nehmen Sie außerdem alle API-Gateways, Caches und Ingress-Controller in diese Liste auf, die Sie zur Unterstützung Ihrer Kubernetes-Umgebung bereitgestellt haben. Hier ist eine vollständige Stückliste wichtig. Deshalb ist eine regelmäßige Bestandsaufnahme für die Aufrechterhaltung einer sicheren Umgebung unerlässlich.

Sobald Sie Ihre Liste erstellt haben, ist es an der Zeit, sich mit den wichtigsten Sicherheitsproblemen bei Workloads zu befassen.

• 1. Authentifizierung ist nicht optional
  Wenn Sie diese gesamte Reihe verfolgt haben, ist das für Sie nichts Neues. Es ist eines der wiederkehrenden Themen in allen Bereichen der Containersicherheit: Sichern Sie den Zugang.
  
  Alle diese Dienste werden als Workloads in einem Cluster ausgeführt. Das bedeutet häufig, dass für den Zugriff auf APIs und Daten Standardanmeldedaten oder eine „offene“ Erstkonfiguration verwendet werden. Workload-Sicherheit umfasst alle Komponenten, Software- und Anwendungsdienste, die für die Funktionalität und den Betrieb der Anwendung erforderlich sind.
  
  
• 2. Schädliche Inhalte sind schädlich
  Auch nachdem Sie die Tür durch die Anforderung von Anmeldedaten und die Anwendung von Zugriffskontrollen verriegelt haben, müssen Sie sich weiterhin Gedanken über schädliche Inhalte machen. Das gilt für Anwendungen, Microservices und eingesetzte Betriebsdienste. Alle Workloads, die Benutzern (ob Betreibern oder Endanwendern) eine Schnittstelle bieten, sind potenziell gefährdet. Deshalb sind Scans und entsprechende Maßnahmen unerlässlich. Der erste Schritt besteht darin, Schwachstellen auf der Anwendungsebene zu finden – sei es in HTTP oder in der Anwendungslogik. Sobald Sie diese gefunden haben, müssen Sie etwas dagegen unternehmen. Handelt es sich um eine benutzerdefinierte Anwendung, geben Sie sie an die Entwicklung zurück. Handelt es sich um eine Drittanbieterkomponente, prüfen Sie, ob eine gepatchte oder aktualisierte Version verfügbar ist. Drittanbieterkomponenten werden häufig in Container-Images bereitgestellt und wie Snyk in seinem Bericht „State of Open Source Security 2019“ feststellt, weisen 44 % davon 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 die gefundenen Schwachstellen nicht beheben.
  
  Wenn Ihre Mauer ein Loch hätte, durch das potenzielle Einbrecher die verschlossenen Türen leicht umgehen könnten, würden Sie es schließen. Schließen Sie also auch die virtuellen Löcher in Ihren virtuellen Mauern.
  
  Eine Web Application Firewall oder ein API-Sicherheitsgateway kann Abhilfe schaffen, wenn Schwachstellen nicht sofort von Entwicklern behoben werden können oder Drittanbieter noch keine Lösung bereitgestellt haben.
  
  Am besten lässt sich dies mit „Anfragen überprüfen“ zusammenfassen, denn es geht darum, Anfragen an einen Workload zu prüfen und zu bewerten, bevor sie angenommen werden.
  
  
• 3. Gemeinsam genutzte Ressourcen bedeuten ein gemeinsames Risiko
  Wie bei der herkömmlichen Virtualisierung sind Container nicht vollständig isoliert. Letztlich nutzen Container dasselbe physische Betriebssystem. Das bedeutet, dass Schwachstellen im gemeinsam genutzten Betriebssystem auch gemeinsame Schwachstellen darstellen.

Wenn es einem Angreifer gelingt, eine Schwachstelle in Betriebssystemkomponenten auszunutzen, kann er eine oder mehrere Workloads kompromittieren. Solche Schwachstellen können offengelegt werden, wenn versäumt wurde, die „Tür abzuschließen“ oder „Anrufe zu filtern“. Dieses Szenario ist keineswegs weit hergeholt, wie CVE-2019-5736 gezeigt hat: Eine runc-Schwachstelle auf Betriebssystemebene versetzte damals das Internet in Panik.

Das grundlegende Sicherheitsprinzip wurde hier von Dan Walsh treffend formuliert, dem Experten für SELinux und Red-Hat-Containersicherheit: „Container bieten keine vollständige Isolation“.

Es ist wichtig zu beachten, dass der gesamte Netzwerkverkehr mit Diensten und Benutzern außerhalb des Knotens das Host-Betriebssystem durchlaufen muss. Die Netzwerkkommunikation zwischen Pods und Containern auf einem Knoten erfolgt über virtuelle Netzwerke mit virtuellen Bridges und durch den geschickten Einsatz von iptables. Letztendlich muss der Datenverkehr diesen physischen Knoten jedoch verlassen, was eine Verarbeitung durch das Host-Betriebssystem erfordert. Agenten, Plug-ins und andere Daemons können diesen Datenverkehr zu Sicherheits- oder Überwachungszwecken beobachten oder erfassen. Dabei handelt es sich um potenzielle Angriffspunkte, die Sie dem Inventar hinzufügen sollten, mit dessen Erstellung Sie nach der Lektüre des Abschnitts über Pipeline-Sicherheit begonnen haben.

• 4. Protokollierung sensibler Details
  Sie hätten vielleicht nicht erwartet, dass eine Erörterung der Containersicherheit auch eine Warnung vor Protokollen enthält. Doch genau das ist der Fall, denn manchmal gelangen sensible Informationen in Protokolldateien: Autorisierungstoken, Schlüssel von Verschlüsselungsanbietern und Anmeldedaten. All dies kann von Workloads versehentlich protokolliert oder über stderr ausgegeben werden. Häufig geschieht dies bei der Suche nach den Ursachen von Authentifizierungsfehlern. Grundsätzlich sollten Sie davon abraten – und es nach Möglichkeit unterbinden –, Geheimnisse im System zu protokollieren.
  
  Damit sich Entwickler dieses Risikos bewusst sind, sollten Sie einen Leitfaden zur Gestaltung der Protokollierung bereitstellen und darin festlegen, welche Informationen in das Protokoll geschrieben werden dürfen und welche nicht.

Ein Großteil der Workload-Sicherheit im Container-Kontext unterscheidet sich nicht von der Sicherheit anderer Anwendungs-Workloads in Ihrer Produktionsumgebung. Kontrollieren Sie den Zugriff und verlangen Sie eine starke Authentifizierung, achten Sie auf schädliche Inhalte und berücksichtigen Sie Schwachstellen in gemeinsam genutzten Ressourcen sowie auf Plattformebene.