Wie man eine effektive Container-Mikrosegmentierungsstrategie mit Kubernetes entwirft und implementiert

Mikrosegmentierung wird oft als schwierig angesehen, wenn sie in großem Maßstab implementiert werden kann. Wenn es Ihr Ziel ist, ein Segment – eine Vertrauensgrenze – um jede einzelne Workload in Ihrer gesamten Cloud-Fabric zu erstellen, müssen während der Architekturphase mehrere Faktoren berücksichtigt werden. Hosts, die als Bare-Metal- oder VM-Server bereitgestellt werden, sind vertraute Entitäten, und ihr Verhalten ist sowohl aus Netzwerk- als auch aus Sicherheitsperspektive bekannt. Wenn Sie jedoch Containerumgebungen in die Gesamtarchitektur einbeziehen, werden Sie wahrscheinlich einige Einschränkungen einführen, die in herkömmlichen Netzwerk- und Sicherheitsarchitekturen normalerweise nicht von Bedeutung sind.

Wenn Sie Container in Ihrer gesamten Hybrid Cloud bereitstellen, stellen sich schließlich mehrere Fragen zur Sicherheit:

• Wie automatisiere ich die Bereitstellung und Verwaltung der Mikrosegmentierung für alle Container-Workloads?
• Wie integriere ich Container-Segmentierungsrichtlinien und -Automatisierung 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. Zum Beispiel können Pods plötzlich sterben und später automatisch wieder hochgefahren werden, jedoch mit einer anderen IP-Adresse. Auf der anderen Seite werden Dienste vor Pods bereitgestellt und verhalten sich wie ein Load Balancer. Für welche dieser Entitäten sollte ich also ein Segment definieren? Ein Namespace kann sich über diese Entitäten erstrecken, also wie segmentiere ich ihn? Und wie viele Workloads werde ich am Ende erstellen, wenn alles vollständig bereitgestellt ist?

Container können ein schwer zu verstehendes Thema sein, und der Versuch, das Mikrosegmentierungs-"Problem" mit Containern zu lösen, kann die Angelegenheit leicht noch komplizierter machen.

Wie können Sie die Herausforderung der Mikrosegmentierung lösen, damit Sie Container in Ihre bestehende Umgebung einführen können, ohne die aktuelle Sicherheitsstrategie zu verletzen oder versehentlich auf ein Hindernis zu stoßen, wenn sich die Architektur weiterentwickelt?

Glücklicherweise ist dies ein lösbares Problem. Lassen Sie mich das erklären.

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

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

Im Allgemeinen lautet die Antwort auf diese Frage, alle Ihre Hosts – Bare-Metal-Hosts und VMs – zu addieren und dann vielleicht die doppelte oder dreifache Anzahl zu zahlen, um dem erwarteten zukünftigen Wachstum gerecht zu werden. Diese Zahl ist etwas unscharf, da einige Anwendungen auf einem Cluster von Hosts oder VMs ausgeführt werden. Ein Host ist nicht immer gleich einer Workload. Die Gleichsetzung einer Workload mit einem Host ist jedoch ein nützlicher Benchmark, um die Skalierungszahlen zu schätzen. Diese endgültige Gesamtzahl wird dann mit den Obergrenzen der verwalteten Workloads verglichen, die ein bestimmter Mikrosegmentierungsanbieter unterstützen kann.

Bare-Metal-Hosts werden nicht oft migriert, daher sind sie ziemlich statische Entitäten, um die herum Segmente definiert werden können. VMs hingegen können etwas unvorhersehbar sein. Sie können beispielsweise dynamisch hoch- und heruntergefahren, über Netzwerksegmente hinweg migriert und über ihren Lebenszyklus hinweg mit mehreren IP-Adressen versehen werden. Die Gesamtzahl der Hosts wird also etwas fließend sein. In der Regel können Sie jedoch abschätzen, wie viele VMs in Ihrer Cloud voraussichtlich aktiv sein werden, um die Gesamtzahl der Workloads zu erreichen, die verwaltet und segmentiert werden müssen. Oft geht diese endgültige Zahl in die Hunderte oder vielleicht in die Tausende.  

Wenn man daher die oberen Skalengrenzen berücksichtigt, die verschiedene Mikrosegmentierungsanbieter unterstützen können, erscheinen diese maximalen Zahlen oft "gut genug". Wenn beispielsweise in einer Cloud heute 1.000 Workloads ausgeführt werden und sich diese Zahl in den nächsten Jahren verdoppeln oder sogar verdreifachen könnte, sollte es kaum Bedenken geben, die Obergrenze eines bestimmten Anbieters von 20.000 verwalteten Workloads in absehbarer Zeit zu erreichen. Große Zahlen werden als entfernte Sorge angesehen.

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

Kubernetes bezeichnet beispielsweise den zugrunde liegenden Host, entweder VM oder Bare-Metal, auf dem Container ausführen, als "Knoten". Auf jedem Knoten werden ein oder mehrere "Pods" erstellt, und in jedem Pod werden die eigentlichen Container Runtime-Instanzen ausgeführt. Kubernetes empfiehlt, maximal 110 Pods auf einem bestimmten Knoten bereitzustellen.

Wenn Sie also 100 Knoten in Ihrer Cloud haben, auf denen Kubernetes ausgeführt wird, und auf jedem Knoten 110 Pods ausgeführt werden, können Sie am Ende 11.000 mögliche Compute-Instanzen haben, die irgendwie als unterschiedliche Segmente definiert werden müssen. Wenn Sie über 200 Knoten verfügen, können Sie am Ende 22.000 mögliche Compute-Instanzen haben. Das muss man wiederholen: Nur 200 Knoten in Ihrer Container-Umgebung können zu 22.000 möglichen Workload-Segmenten führen.

Und das nur in Ihrer Container-Umgebung. Sie müssen alle nicht containerisierten Workloads in Ihrer gesamten Hybrid Cloud hinzufügen, um die erwartete Anzahl der verwalteten Workloads und möglichen Segmente zu schätzen. Die Lektion ist, dass die maximale Anzahl verwalteter Workloads, die verschiedene Mikrosegmentierungsanbieter unterstützen können, nicht mehr so unerreichbar erscheint.

Eine Lösung für Container und Nicht-Container

Wenn es darum geht, wie eine Container-Umgebung segmentiert werden soll, gibt es mehrere Anbieter, die 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, die über Container-Workloads verfügen, auch nicht containerisierte Workloads, Bare-Metal-Workloads und VMs haben, die alle in derselben Cloud-Fabric koexistieren.

Wenn Sie sich für die Bereitstellung einer Segmentierungslösung für Container und einer anderen Segmentierungslösung für Bare-Metal und VMs entscheiden, sind das Ergebnis zwei unterschiedliche Toolsets, die Ereignisse zwischen ihnen nicht automatisieren oder korrelieren. Dieser Ansatz kann in kleinem Maßstab funktionieren, wird aber mit zunehmender Bereitstellung schwierig zu operationalisieren und zu verwalten sein. Sie sollten diesen isolierten Ansatz für die Workload-Segmentierung vermeiden. Containerisierte Workloads müssen über die gesamte Compute Fabric hinweg auf die gleiche Weise verwaltet werden, um eine einheitliche Lösung für die Bereitstellung und Verwaltung der gesamten Workload-Segmentierung zu schaffen.

Illumio zum Beispiel funktioniert über alle Workloads hinweg, von Bare-Metal über VMs bis hin zu Containern. Es gibt keine Funktionsunterschiede zwischen containerisierten und nicht containerisierten Workloads, sodass Sie eine Mikrosegmentierung mit Visualisierung, Automatisierung und Richtlinienverwaltung für alle Workloads erhalten.

Namespaces, Pods oder Dienste?

Kubernetes definiert drei Hauptcontainer-Entitäten, in denen der ausgehende und eingehende Netzwerkverkehr gesteuert werden kann: ein Pod, ein Dienst oder ein Namespace. (Hinweis: Knoten werden nicht als Ziel zwischen diesen Entitäten betrachtet, und ein Cluster wird als die breiteste Grenze um eine Sammlung von Knoten definiert.) Darüber hinaus wird häufig ein Load Balancer am Clusterperimeter bereitgestellt, was zu vier möglichen Entitäten führt, 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 Runtime-Instanzen werden in einem oder mehreren Pods ausgeführt, und häufig 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 Sicht des Netzwerks bedeutet, dass Ziel- oder Quell-IP-Adressen plötzlich verschwinden können. Netzwerk- und Sicherheitsteams mögen es nicht, wenn Entitäten plötzlich in der Gesamtstruktur verschwinden, was den Umgang mit Routenkonvergenz- und Sicherheitstools erschwert.

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

Es ist wichtig, dass Sie Ihren Anbieter von Mikrosegmentierung fragen, ob er entweder einen Pod oder einen Dienst als Segment definieren kann, damit Sie die Wahl Ihrem Sicherheitsadministrator überlassen können.

Anwendungen, die in Containern bereitgestellt werden, werden in der Regel als Namespace bereitgestellt, wobei der Code im Wesentlichen verteilt innerhalb eines oder mehrerer Pods ausgeführt wird. Ein Container-Namespace ist eine Abstraktion über mehrere Pods und Dienste hinweg.

Illumio ermöglicht es Ihnen beispielsweise, ein "Profil" für einen Namensraum zu definieren und dieses Profil dann als Segment zu definieren. Das Ergebnis ist, dass Illumio die Definition eines Segments entweder für einen Pod, einen Dienst oder einen Namespace ermöglicht. Und im Gegensatz zu Mikrosegmentierungstools, die speziell für containerisierte Umgebungen entwickelt wurden, kann Illumio auch Segmente für den zugrunde liegenden Host, die Ein- und Ausstiegspunkte an der Clustergrenze und die umgebenden Legacy-Workloads definieren, die auf Ressourcen innerhalb von Containern zugreifen müssen. Segmente existieren nicht nur innerhalb von Containern, sondern in der gesamten Cloud-Fabric.

Aus diesem Grund sollten Sie sicherstellen, dass Ihr Mikrosegmentierungsanbieter ü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 erweckt werden und verschwinden. Das bedeutet, dass Ihre Mikrosegmentierungslösung in Echtzeit auf Veränderungen reagieren muss.

Durch die Verwendung der Kubelink-Instanz von Illumio, die in einem Container-Cluster bereitgestellt wird, können Sie dynamisch Workloads erkennen, die bereitgestellt und außer Betrieb genommen werden, unsere Application Dependency Map aktivieren und Tools durchsetzen, um in Echtzeit auf alle Änderungen der verwalteten Workloads zu reagieren. Automatisierung und Orchestrierung sind zwei wichtige Konzepte in Containern, und Illumio implementiert beide zur Operationalisierung des Mikrosegmentierungsmanagements sowohl innerhalb als auch außerhalb der Container-Umgebung.

Die Bereitstellung von Containern in Ihrer Cloud sollte nicht bedeuten, dass Sie auf die Möglichkeit verzichten müssen, Segmente für 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 bei containerisierten Workloads möglich ist, ohne dass es zu Hindernissen kommt. Mit Illumio Core kann Ihr Unternehmen Zero Trust für jeden einzelnen Workload in Ihrer gesamten Cloud-Struktur erreichen – unabhängig von der Skalierung.

Willst du mehr? Lesen Sie, wie Illumio Core Kubernetes und OpenShift absichern kann.

Kontaktieren Sie uns noch heute , um zu erfahren, wie Sie Ihre Container mit Illumio Zero Trust Segmentation sichern können.