Containersicherheit – eine neue Grenze (Teil 2)

Eine zweiteilige Blogserie über Überlegungen zur sicheren Containernutzung.

Containersicherheit in einer neuen Dimension

Die Sicherheitsherausforderungen, die Container mit sich bringen können, haben wir in unserem ersten Blogbeitrag skizziert. Dies lässt uns mit der Frage zurück, wie wir über die Containersicherheit nachdenken sollten. 

Wir sind der Meinung, dass wir mit dem Rat von Kubernetes beginnen (und darauf aufbauen) sollten, einen mehrschichtigen Defense-in-Depth-Ansatz zu verwenden, der vier Cs berücksichtigt: Cloud, Cluster, Container und Code. Wir sind auch der Meinung, dass wir überlegen sollten, wie Bedrohungen, die Container kompromittieren, durch Segmentierung eingedämmt werden können.

Da dies der Fall ist, schlagen wir die Eindämmung als fünftes C vor. 

Wir haben bereits darüber gesprochen, dass die Container nicht nur gesichert werden müssen, sondern auch sichergestellt werden müssen, dass sie nicht ausgenutzt und als Brückenkopf verwendet werden können, um sich seitlich innerhalb eines Rechenzentrums zu bewegen. Hier kommt die Notwendigkeit der Eindämmung ins Spiel. 

Sehen wir uns die anfänglichen Kubernetes-Anleitungen zu den 4 Cs an und besprechen wir dann die Eindämmung.

Container

Um Software in Kubernetes ausführen zu können, muss sie sich in einem Container befinden. Aus diesem Grund gibt es bestimmte allgemeine Sicherheitsüberlegungen, die Kubernetes skizziert:

• Scannen: Scannen Sie Ihre Container auf bekannte Schwachstellen. Tools wie bei Clair von CoreOS können hilfreich sein.
• Signieren von Containerimages: Bewahren Sie die Vertrauenswürdigkeit für den Containerinhalt mithilfe der Docker Content Trust, die in die Docker-Engine integriert ist. Das Portieris-Projekt von IBM kann als Zugangscontroller verwendet werden, um die Vertrauenswürdigkeit von Inhalten für ordnungsgemäß signierte Bilder zu erzwingen.
• Benutzerrechte steuern: Versuchen Sie, Benutzer innerhalb der Container zu erstellen, die über die geringste Stufe an Betriebssystemberechtigungen verfügen, die zum Ausführen des Ziels des Containers erforderlich ist. 

Code

Bei der Untersuchung der Anwendungscodeebene trifft der Leitfaden von Kubernetes auf einige Punkte:

• Zugriff nur über TLS zulassen: Standardmäßig wird alles während der Übertragung verschlüsselt, auch zwischen Netzwerkdiensten hinter der Firewall.
• Begrenzen Sie die Portbereiche der Kommunikation: Geben Sie nur die Ports für Ihren Dienst frei, die absolut notwendig sind.
• Statischen Code analysieren: Analysieren Sie den Code auf potenziell unsichere Codierungspraktiken.
• Test auf dynamische Testangriffe: Verwenden Sie OWASP-Tools , um gängige Angriffe wie SQL-Injection, CSRF usw. zu automatisieren.

Wolke

Jeder Cloud-Anbieter gibt umfassende Empfehlungen zum Ausführen von Container-Workloads in seiner Cloud-Infrastruktur. Die Sicherheitsangebote können je nach Cloud-Anbieter unterschiedlich sein, und die Benutzer müssen diese Empfehlungen genau befolgen. Links zu beliebten Cloud-Anbietern und Sicherheitsempfehlungen finden Sie in https://kubernetes.io/docs/concepts/security/#the-4c-s-of-cloud-native-security.

Zu den allgemeinen Leitlinien gehören:

• Einschränken des Netzwerkzugriffs: Die meisten Cloud-Sicherheitsanbieter bieten Netzwerksicherheit mithilfe von Zugriffskontrolllisten – AWS bietet beispielsweise Sicherheitsgruppen an, mit denen Workloads in Gruppen segmentiert werden können, und mit denen ACLs pro Gruppe konfiguriert werden können.
• API-Zugriff einschränken: Im Idealfall sollten nur die Server, die für die Verwaltung eines Clusters erforderlich sind, Zugriff auf API-Server haben.
• Beschränken Sie den Zugriff auf Kubernetes-Cluster-APIs: Es empfiehlt sich, dem Cluster Zugriff auf Cloud-Anbieter zu gewähren, der dem Prinzip der geringsten Rechte für die Ressourcen folgt, die er verwalten muss. Ein Beispiel für Kops in AWS finden Sie hier: https://github.com/kubernetes/kops/blob/master/docs/iam_roles.md#iam-roles.
• Zugriff auf 'etcd' einschränken: In diesem Verzeichnis befinden sich die Cloud-Konfigurationsdateien für Kubernetes. Verwenden Sie immer TLS, um auf diese Dateien zuzugreifen und Änderungen daran vorzunehmen.
• Verschlüsseln Sie alle Laufwerke, insbesondere etcd-Laufwerke: Verhindern Sie, dass nicht autorisierte Benutzer kritische Konfigurationsdateien und Datenspeicher anzeigen, die zu Ihrem Kubernetes-Cluster gehören.

Cluster

• Beschränken Sie den Zugriff auf die Kubernetes-API auf den Cluster mithilfe von RBAC.
• Authentifizieren Sie den gesamten Zugriff auf die API, die den Cluster steuert.
• Verschlüsseln Sie alle geheimen Schlüssel, die vom Cluster verwendet werden, einschließlich aller Daten in etcd.
• Kontrolle von Sicherheitsaspekten von Pods: Pod-Sicherheitsobjekte definieren eine Reihe von Bedingungen, unter denen ein Pod ausgeführt werden muss, um in das System aufgenommen zu werden.
• Kontrollieren Sie die Ressourcenauslastung: Die Kubernetes-Knoten, auf denen Ihre Anwendung ausgeführt wird, sind in Bezug auf Zuverlässigkeit und Ressourcenausgleich voneinander abhängig. Daher sollte es Richtlinien geben, die die Menge der von diesen Knoten verwendeten Ressourcen einschränken.
• Steuern Sie alle Netzwerkrichtlinien für Pods mithilfe von Zugriffskontrolllisten. Das ist eine Nord-Süd-Sicherheitspolitik. Informationen zu Richtlinien innerhalb eines Datencenters finden Sie unten unter Containment.
• Beschränken Sie den gesamten eingehenden Zugriff auf TLS.

Eindämmung

Dies bringt uns zum fünften C der Eindämmung, das die Ausbreitung von Sicherheitsverletzungen verhindert, die von einem Container aus initiiert werden. Die Eindämmung sollte einige Dinge berücksichtigen, damit sie am effektivsten ist:

• Entdecken Sie Container, die in Echtzeit neu erstellt werden.
• Ermöglichen Sie eine automatisierte Segmentierung für neue Container-Workloads, sodass die Sicherheit automatisch "bei der Geburt" vorhanden ist.
• Zentralisieren Sie die Sichtbarkeit von Containern zusammen mit anderen Computing-Umgebungen, um eine zentrale Ansicht über containerisierte Workloads und Bare-Metal-, virtuelle Maschinen, private und öffentliche Clouds zu erhalten – denn Sie können nicht schützen, was Sie nicht sehen können.
• Setzen Sie einheitliche Richtlinien für Container – und alles andere – durch, damit Sie unabhängig von der Umgebung mit einheitlichen Richtlinien segmentieren können. Dadurch werden mehrere Punkttools für die Segmentierung für VMs, Bare-Metal-Server, Clouds und Container vermieden.

Mit einem umfassenden Defense-in-Depth-Ansatz für Container können sich Unternehmen auf die Sicherheitsfähigkeit von Containern verlassen, um sie mit noch größerem Vertrauen einzusetzen.