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

Microsegmentation is often viewed as challenging to implement at scale. If your goal is to create a segment – a trust boundary – around every single workload in your entire cloud fabric, several factors must be considered during the architecture phase. Hosts that are deployed as bare-metal or VMs are familiar entities, and their behavior is well-known from both a networking and security perspective. But when you include container environments in the overall architecture, you’ll likely introduce some caveats that are not normally significant in traditional network and security architectures.

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

• How do I automate the deployment and management of microsegmentation across all containers 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.

If you choose to deploy one segmentation solution for containers and a different segmentation solution for bare-metal and VMs, the result will be two distinct toolsets that don’t automate or correlate events between them. This approach may work on small scales but will become difficult to operationalize and manage as the deployment grows. You should avoid this siloed approach to workload segmentation. Containerized workloads need to be managed in the same way across the entire compute fabric in order to create a unified solution for deploying and managing all workload segmentation.

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.

By using Illumio’s Kubelink instance deployed into a containers cluster, you can dynamically discover workloads that are deployed and decommissioned, enable our application dependency map, and enforce tools to react in real-time to any and all changes in workloads being managed. Automation and orchestration are two important concepts in containers, and Illumio implements both for operationalizing microsegmentation management both within and outside of container environment.

Deploying containers in your cloud should not mean sacrificing the ability to define segments around workloads, regardless of how they are deployed. Make sure your segmentation solution will continue to scale to the same high numbers as containerized workloads enable, without incurring any roadblocks. With Illumio Core, your company can reach Zero Trust around every single workload in your entire cloud fabric — regardless of scale.

Want more? Read how Illumio Core can secure Kubernetes and OpenShift.

Contact us today to learn how to secure your containers with Illumio Zero Trust Segmentation.