So entwerfen und implementieren Sie eine effektive Container-Mikrosegmentierungsstrategie mit Kubernetes

Mikrosegmentierung wird oft als schwierig angesehen, es in großem Maßstab zu implementieren. Wenn Ihr Ziel darin besteht, ein Segment — eine Vertrauensgrenze — rund um jeden einzelnen Workload in Ihrer gesamten Cloud-Struktur zu erstellen, müssen während der Architekturphase mehrere Faktoren berücksichtigt werden. Hosts, die als Bare-Metal- oder VMs bereitgestellt werden, sind vertraute Einheiten, und ihr Verhalten ist sowohl aus Netzwerk- als auch aus Sicherheitssicht bekannt. Wenn Sie jedoch Container-Umgebungen in die Gesamtarchitektur einbeziehen, werden Sie wahrscheinlich einige Vorbehalte einführen, die bei herkömmlichen Netzwerk- und Sicherheitsarchitekturen normalerweise nicht von Bedeutung sind.

Wenn Sie Container in Ihrer gesamten Hybrid-Cloud bereitstellen, tauchen irgendwann mehrere Fragen zur Sicherheit auf:

• Wie automatisiere ich die Bereitstellung und Verwaltung von Mikrosegmentierung für alle Container-Workloads?
• Wie integriere ich Richtlinien und Automatisierung zur Container-Segmentierung in die vorhandenen Sicherheitstools, die zur Verwaltung von Bare-Metal- und VM-Hosts verwendet werden?
• Muss ich zwei unterschiedliche Mikrosegmentierungslösungen verwalten: eine für Container und eine für alles andere?

Container können sich aus Netzwerk- und Sicherheitssicht seltsam verhalten. Beispielsweise können Pods plötzlich ausfallen und später automatisch wieder hochgefahren werden, allerdings mit einer anderen IP-Adresse. Auf der anderen Seite werden Dienste vor den Pods bereitgestellt und verhalten sich wie ein Load Balancer. Also, für welche dieser Entitäten sollte ich ein Segment definieren? Ein Namespace kann sich über diese Entitäten erstrecken. Wie segmentiere ich ihn also? Und wie viele Workloads werde ich am Ende erstellen, wenn alles vollständig bereitgestellt ist?

Container können für sich genommen ein schwer zu verstehendes Thema sein, und der Versuch, das „Problem“ der Mikrosegmentierung mit Containern zu lösen, kann die Angelegenheit leicht noch komplizierter machen.

Wie können Sie die Herausforderung der Mikrosegmentierung lösen, sodass Sie Container in Ihre bestehende Umgebung integrieren können, ohne die aktuelle Sicherheitsstrategie zu verletzen oder versehentlich auf Hindernisse zu stoßen, während sich die Architektur weiterentwickelt?

Zum Glück ist das ist ein lösbares Problem. Lass es mich erklären.

Überlegungen beim Hinzufügen von Containern zu einer bestehenden Mikrosegmentierungsstrategie

Ein guter Ausgangspunkt, um die Diskussion über Container und Mikrosegmentierung zu beginnen, ist das Thema Skalierung. Bei der Entwicklung einer Segmentierungsstrategie für all Ihre Workloads in Ihrer gesamten Hybrid Cloud ist die Skalierung immer ein wichtiger Vorbehalt. Wie groß wird die gesamte Umgebung wachsen?

Im Allgemeinen lautet die Antwort auf diese Frage, dass Sie alle Ihre Hosts — Bare-Metal und VMs — zusammenzählen und diese Zahl dann vielleicht verdoppeln oder verdreifachen, um dem erwarteten zukünftigen Wachstum Rechnung zu tragen. Diese Zahl wird etwas unscharf sein, da einige Anwendungen auf einem Cluster von Hosts oder VMs ausgeführt werden; ein Host entspricht nicht immer einer Arbeitslast. Die Gleichsetzung einer Arbeitslast mit einem Host ist jedoch ein nützlicher Maßstab, anhand dessen sich die Skalierung abschätzen lässt. Diese endgültige Gesamtzahl wird dann mit den Obergrenzen der verwalteten Workloads verglichen, die ein bestimmter Mikrosegmentierungsanbieter unterstützen kann.

Bare-Metal-Hosts migrieren nicht oft, daher sind sie ziemlich statische Entitäten, um sie herum Segmente zu definieren. VMs können dagegen etwas unberechenbar sein. Sie können beispielsweise dynamisch hoch- und heruntergefahren, über Netzwerksegmente hinweg migriert und ihnen im Laufe ihres Lebenszyklus mehrere IP-Adressen zugewiesen werden. Die Gesamtzahl der Hosts wird also etwas fließend sein. Allerdings können Sie in der Regel abschätzen, wie viele VMs voraussichtlich in Ihrer Cloud aktiv sein werden, um die Gesamtzahl der Workloads zu erreichen, die verwaltet und segmentiert werden müssen. Oft liegt diese endgültige Zahl bei Hunderten oder vielleicht bei niedrigen Tausenden.

Wenn man die oberen Skalengrenzen berücksichtigt, die verschiedene Anbieter von Mikrosegmentierungen unterstützen können, scheinen diese Höchstwerte daher oft „gut genug“ zu sein. Wenn in einer Cloud heute beispielsweise 1.000 Workloads laufen und sich diese Zahl in den nächsten Jahren verdoppeln oder sogar verdreifachen könnte, sollten Sie sich kaum Sorgen machen, dass die Obergrenze eines bestimmten Anbieters von 20.000 verwalteten Workloads in absehbarer Zeit erreicht wird. Große Zahlen werden als geringfügiges Problem angesehen.

Aber was passiert, wenn Sie dem Bild Container hinzufügen? Ein containerisierter Workload ist eine Recheninstanz, die sich anders verhält als VMs und Bare-Metal-Hosts.

Kubernetes nennt beispielsweise den zugrunde liegenden Host, entweder VM oder Bare-Metal, auf dem Container ausgeführt werden, einen „Knoten“. Auf jedem Knoten werden ein oder mehrere „Pods“ erstellt, und in jedem Pod werden die eigentlichen Container-Laufzeitinstanzen ausgeführt. Kubernetes empfiehlt, dass maximal 110 Pods auf einem bestimmten Knoten bereitgestellt werden.

Wenn Sie also 100 Knoten in Ihrer Cloud haben, auf denen Kubernetes läuft, und auf jedem Knoten 110 Pods laufen, können Sie am Ende 11.000 mögliche Recheninstanzen haben, die irgendwie als separate Segmente definiert werden müssen. Wenn Sie 200 Knoten haben, können Sie am Ende 22.000 mögliche Recheninstanzen haben. Das muss wiederholt werden: Nur 200 Knoten in Ihrer Container-Umgebung können zu 22.000 möglichen Workload-Segmenten führen.

Und das ist nur in Ihrer Container-Umgebung. Sie müssen alle nicht containerisierten Workloads in Ihrer gesamten Hybrid-Cloud hinzufügen, um die erwartete Anzahl verwalteter Workloads und möglicher Segmente abschätzen zu können. Die daraus gewonnene Lektion ist, dass die maximale Anzahl an verwalteten Workloads, die verschiedene Anbieter von Mikrosegmentierungen unterstützen können, nicht mehr so unerreichbar scheint.

Eine Lösung sowohl für Container als auch für Nicht-Container

Wenn es darum geht, eine Container-Umgebung zu segmentieren, gibt es mehrere Anbieter, die Mikrosegmentierung innerhalb und zwischen Clustern in Kubernetes oder OpenShift ermöglichen. Die meisten dieser Lösungen konzentrieren sich jedoch speziell auf Container-Umgebungen und nicht auf nicht containerisierte Workloads in Ihrer Hybrid Cloud. Und die Realität ist, dass die meisten Netzwerke mit Container-Workloads auch nicht containerisierte Workloads, Bare-Metal-Workloads und VMs enthalten, die alle in derselben Cloud-Fabric koexistieren.

Wenn Sie sich dafür entscheiden, eine Segmentierungslösung für Container und eine andere Segmentierungslösung für Bare-Metal und VMs bereitzustellen, werden das Ergebnis zwei unterschiedliche Toolsets sein, die Ereignisse zwischen ihnen nicht automatisieren oder korrelieren. Dieser Ansatz mag in kleinem Maßstab funktionieren, aber mit zunehmender Bereitstellung wird es schwieriger, ihn zu operationalisieren und zu verwalten. Sie sollten diesen isolierten Ansatz zur Workload-Segmentierung vermeiden. Containerisierte Workloads müssen in der gesamten Compute-Fabric auf die gleiche Weise verwaltet werden, um eine einheitliche Lösung für die Bereitstellung und Verwaltung aller Segmentierung der Arbeitslast.

Illumio funktioniert beispielsweise für alle Workloads, von Bare-Metal über VMs bis hin zu Containern. Es gibt keinen Funktionsunterschied zwischen containerisierten Workloads und nicht containerisierten Workloads. Sie profitieren also von einer Mikrosegmentierung mit Visualisierung, Automatisierung und Policy-Management für alle Workloads.

Namespaces, Pods oder Dienste?

Kubernetes definiert drei Haupt-Container-Entitäten, in denen der ausgehende und eingehende Netzwerkverkehr gesteuert werden kann: einen Pod, einen Service oder einen Namespace. (Hinweis: Knoten werden nicht als Ziel zwischen diesen Entitäten betrachtet, und ein Cluster ist definiert als die breiteste Grenze rund um eine Sammlung von Knoten). Darüber hinaus wird häufig ein Load Balancer am Cluster-Perimeter bereitgestellt, sodass sich vier mögliche Entitäten ergeben, die segmentiert werden können. Welche dieser Entitäten sollte bei der Definition Ihrer Mikrosegmentierungsarchitektur als Segment klassifiziert werden? Einige von ihnen oder alle?

Ein Pod ist die kleinste Entität, der von Kubernetes eine IP-Adresse zugewiesen werden kann. Container-Laufzeitinstanzen werden in einem oder mehreren Pods ausgeführt, und oft müssen diese Pods miteinander kommunizieren. Jeder Pod kann als Segment definiert werden, aber die Herausforderung besteht darin, dass Kubernetes Pods herunterfahren und später hochfahren kann, was aus Netzwerksicht bedeutet, dass Ziel- oder Quell-IP-Adressen plötzlich verschwinden können. Netzwerk- und Sicherheitsteams mögen es nicht, wenn Entitäten plötzlich im Gesamtgefüge verschwinden, was es schwierig macht, mit Routenkonvergenz und Sicherheitstools umzugehen.

Kubernetes kann einen Service bereitstellen, der vor einer bestimmten Anzahl von Pods bereitgestellt wird und sich fast wie ein Load Balancer für die Pods dahinter verhält. Dienste sind viel stabiler, und obwohl Kubernetes Pods dynamisch hoch- und herunterfahren kann, ist dies bei Diensten selten der Fall. Daher empfiehlt es sich, einen Service als Segment und nicht als einzelne Pods zu definieren.

Es ist wichtig, dass Sie Ihren Anbieter für Mikrosegmentierung fragen, ob er entweder einen Pod oder einen Service als Segment definieren kann, sodass die Wahl Ihrem Sicherheitsadministrator überlassen bleibt.

In Containern bereitgestellte Anwendungen werden im Allgemeinen als Namespace bereitgestellt, wobei Code im Wesentlichen verteilt in einem oder mehreren Pods ausgeführt wird. Ein Container-Namespace ist eine Abstraktion über mehrere Pods und Dienste.

Mit Illumio können Sie beispielsweise ein „Profil“ für einen Namespace definieren und dieses Profil dann als Segment definieren. Das Ergebnis ist, dass Illumio die Definition eines Segments entweder für einen Pod, einen Service oder einen Namespace ermöglicht. Und im Gegensatz zu Mikrosegmentierungstools, die speziell für containerisierte Umgebungen entwickelt wurden, kann Illumio Segmente auch anhand des zugrundeliegenden Hosts, der Eingangs-/Ausgangspunkte an der Cluster-Grenze und der umliegenden Legacy-Workloads definieren, die auf Ressourcen innerhalb von Containern zugreifen müssen. Segmente existieren nicht nur innerhalb von Containern — sie existieren in der gesamten Cloud-Fabric.

Aus diesem Grund sollten Sie sicherstellen, dass Ihr Anbieter für Mikrosegmentierung über 100.000 Workloads verwalten kann. Je mehr Container-Umgebungen in einer Cloud-Fabric bereitgestellt werden, desto schneller rücken diese hohen Zahlen in den Fokus. Und diese Zahlen bestehen aus Workloads, die in Containern oft kurzlebig sind, wobei Workloads dynamisch zum Leben erwachen und wieder verschwinden. Das bedeutet, dass Ihre Mikrosegmentierungslösung in Echtzeit auf Änderungen reagieren muss.

Mithilfe der Kubelink-Instance von Illumio, die in einem Container-Cluster bereitgestellt wird, können Sie Workloads, die bereitgestellt und außer Betrieb genommen werden, dynamisch erkennen. Aktivieren Sie unsere Abbildung der Anwendungsabhängigkeitenund setzen Sie Tools ein, um in Echtzeit auf alle Änderungen der zu verwaltenden Workloads zu reagieren. Automatisierung und Orchestrierung sind zwei wichtige Konzepte bei Containern, und Illumio implementiert beide, um das Mikrosegmentierungsmanagement sowohl innerhalb als auch außerhalb der Container-Umgebung zu operationalisieren.

Die Bereitstellung von Containern in Ihrer Cloud sollte nicht bedeuten, dass Sie auf die Möglichkeit verzichten müssen, Segmente rund um Workloads zu definieren, unabhängig davon, wie sie bereitgestellt werden. Stellen Sie sicher, dass Ihre Segmentierungslösung weiterhin auf die gleichen hohen Zahlen skaliert werden kann, wie es containerisierte Workloads ermöglichen, ohne dass es zu Hindernissen kommt. Mit Illumio Core kann Ihr Unternehmen Folgendes erreichen Null Vertrauen für jeden einzelnen Workload in Ihrer gesamten Cloud-Struktur — unabhängig von der Größe.

Willst du mehr? Schauen Sie sich unser neuestes an datenblatt das behandelt, wie Illumio Core auf Container ausgedehnt wird.