Ist Intent-based Networking eine "gescheiterte" Technologie?

Mitte der 2010er Jahre verliebten sich Experten und Analysten des Technologiemarketings gleichermaßen in eine Technologie, die sie Intent-Based Networking (IBN) nannten, und hypten sie ausgiebig.

Heute, fast ein Jahrzehnt später, hört man nicht mehr viel von IBN. Aber das bedeutet nicht, dass es weg ist.

Dieser Artikel beschreibt die Geschichte von IBN und seine wesentlichen Grundlagen für die moderne Cloud-Infrastruktur von heute – und die Cloud-Sicherheit.

Anfang der 2010er Jahre: Anpassung an die schnellen Veränderungen im Cloud-Networking

Kurz zuvor erlebte das Büro des CTO bei HP Networking, dass ähnliche neue Netzwerkabstraktionen isoliert von mehreren Gruppen erfunden wurden, die versuchten, sich an das neue Ausmaß und die neue Veränderungsrate in Cloud-Netzwerken anzupassen. Ein Großteil dieser Arbeit wurde in Open-Source-Projekten (z. B. OpenStack, Open Day Light) geleistet.

HP beschloss, Ressourcen in den Versuch zu investieren, diese Arbeit zu vereinheitlichen, und veranstaltete 2013 den "IBN Summit" in den HP Labs in Palo Alto. Eingeladen wurden alle, von denen bekannt ist, dass sie an Netzwerkrichtlinienlösungen für SDN- und Cloud-Projekte arbeiten, darunter Mitarbeiter von Cisco, HP, RedHat, IBM, Huawei, Brocade, Microsoft, NEC, VMWare usw. Die verschiedenen Parteien stellten Aspekte ihrer Arbeit in diesem Bereich vor und einigten sich darauf, einen Weg zu einer gemeinsamen API zu finden.

Mitte der 2010er Jahre: Definition von IBN

Vertreter vieler dieser Unternehmen arbeiteten dann auch unter meinem Vorsitz in der Arbeitsgruppe North-Bound Interface (NBI) der Open Networking Foundation (ONF) zusammen. Im Oktober 2016 veröffentlichte die ONF ein Dokument, das den Konsens der Mitglieder über eine Definition und einen technischen Überblick für ein IBN-System darstellen soll.

Lesen Sie hier das Dokument "Intent NBI - Definition and Principles".

Die Definition aus diesem Dokument lässt sich durch eine Art goldene Regel zusammenfassen: Die Absicht enthält keine Implementierungsdetails, die sie plattform- oder infrastrukturspezifisch machen würden.

Die Absicht besteht aus deklarativen Aussagen über das gewünschte Netzwerkverhalten in geschäftlicher Hinsicht. Unabhängig davon gibt es einen Mapping-Prozess, der weiß, wie die Absicht in die aktuelle Konfiguration/den aktuellen Zustand/die aktuelle Topologie der Infrastruktur implementiert wird.

Kritiker behaupteten, dass wir die Implementierung wegwerfen und ignorieren würden, so dass es keinen Wert gäbe. Wir wiesen darauf hin, dass wir es nicht wegwerfen, sondern unter der Kontrolle eines Mapping-Prozesses an einen anderen Ort verschieben. Um eine "reine" Absicht zu deklarieren, müssen die Autoren der Richtlinie keine Experten für die Infrastrukturtechnologien sein, sondern sie müssen nur die geschäftlichen Einschränkungen für die Richtlinie verstehen.

In diesem Dokument beschrieb die ONF-Definition eine "Intent Active Loop" innerhalb des Controllers:

"Dieses Element ist für die kontinuierliche Auswertung aktiver Dienstabsichten und Zuordnungen aus dem Repository und den Netzwerkinformationen aus dem SBI-Handler verantwortlich. und das Ergreifen von Maßnahmen, die erforderlich sind, um neue Dienstkonfigurationen zu instanziieren oder bestehende entsprechend zu modifizieren, als Funktion von erkannten Intent-Änderungen (Repository) und/oder von Mapping-Änderungen (Repo) und/oder von Intent NBI."

Die Beschreibung der aktiven Absichtsschleife stimmt mit einem Begriff überein, der aus Kubernetes bekannt geworden ist und Controller beschreibt, die deklarative Absicht in Systemverhaltensweisen übersetzen, als auf einer Continuous Reconciliation Loop (CRL) aufgebaut, die kontinuierlich eine Implementierung der deklarierten Absicht innerhalb der Infrastruktur aufrechterhält.

In diesem Artikel wird der Begriff Continuous Reconciliation Loop (CRL) verwendet, um sich auf alle diese technischen Ansätze zu beziehen.

2017: IBN ist "das nächste große Ding"

Kurz nachdem wir das Dokument veröffentlicht hatten, begann die Branche über IBN zu sprechen, als Gartner den Begriff 2017 prägte und ihn in einem Blogartikel als das "nächste große Ding" bezeichnete.

Die Vermarkter machten IBN schließlich bedeutungslos, was sie auch tun, indem sie zunächst behaupteten, dass sie IBN schon immer hatten. Und dann, als Ergebnis, hörten die Leute irgendwann auf, darüber zu sprechen.

Nach all dem Lärm kann man zurückblicken und sich fragen: War IBN in praktischer Hinsicht ein Misserfolg?

Die Antwort ist nein - ganz im Gegenteil.

Heute: IBN lebt und lebt in moderner Cloud-Infrastruktur

Wir sprechen nicht viel über IBN, aber es ist in der modernen Cloud-Infrastruktur allgegenwärtig.

Drei Beispiele verdeutlichen, wie breit dieser Ansatz in großen Produktionsumgebungen eingesetzt werden kann.

Kubernetes-Netzwerkrichtlinien

Der Container Network Interface (CNI)-Richtliniencontroller von K8, die Certificate Revocation List (CRL), kennt den Status aller Pods/Endpunkte, virtuellen Switches, Sidecar-Proxys, Gateways, NATs usw. Es kennt auch Zuordnungen für die Implementierung (IP-Adressen, Ports, Protokolle, Identität, Autorisierung, Labels, Namespaces usw.) und führt eine kontinuierliche Abstimmungsschleife durch, um die Implementierung mit den Netzwerkrichtlinien konsistent zu halten.

Entwickler stellen Kubernetes-Netzwerkrichtlinien (KNPs) ohne Implementierungsdetails (Intent) bereit, und der Controller macht es so. KNPs ermöglichen es Benutzern, Attribute auf niedrigerer Ebene wie IP-Adresse oder Port anzugeben, aber es empfiehlt sich, bezeichnungsbasierte Selektoren in lokalen Richtliniendeklarationen zu verwenden, um von der Automatisierung des verteilten Zustands in der KNP-Engine zu profitieren.

Illumio Policy Compute Engine (PCE) und Illumio VEN (Agent)

Illumio verfügt über ein ausgereiftes und weit verbreitetes Unternehmensprodukt, das das Intent-Value-Proposition auf Bare-Metal- und virtuelle Maschinen und Container bringt, indem es eine ähnliche labelbasierte Abstraktion verwendet. Dies erstreckt sich über mehrere dynamische Instanzen, die einen CRL-Controller verwenden, um Richtlinieneinschränkungen beizubehalten.

Es gibt einen verteilten Controller (Distributed Controller, PCE), der mit abstrahierten, dynamischen, bezeichnungsbasierten Richtlinien vorkonfiguriert ist und die kontinuierliche Abstimmungsschleife verwendet, um diese Richtlinien im Kontext des aktuellen Infrastrukturzustands und der aktuellen Topologie zu implementieren.

Die tatsächliche Durchsetzung von Richtlinien erfolgt in diesem Fall durch die Programmierung der nativen Tools auf niedrigerer Ebene für verschiedene lokale und öffentliche Cloud-Infrastrukturplattformen.

Juniper/Apstra

Apstra IBN verfügt auch über ein deklaratives Modell mit Automatisierung, um abstrakte Richtlinien in bestimmte Infrastrukturimplementierungen umzuwandeln. Das Problem, das dadurch gelöst wird, unterscheidet sich jedoch geringfügig von den vorherigen Beispielen.

Sowohl Kubernetes Network Policies als auch die Plattform von Illumio können als "Overlay"-Netzwerktechnologien kategorisiert werden. Sie erstellen und steuern Features eines virtuellen Netzwerks auf einem Netzwerk, das bereits über grundlegende Konnektivität zwischen physischen Geräten verfügt.

Die Apstra-Lösung von Juniper ist in der Lage, das "Äúunderlay"-Netzwerk zu erstellen und zu steuern, das Racks voller Rechenzentrumsgeräte umfasst, die über Kabel miteinander verbunden sind. Aber wie in den obigen Beispielen wird die Konsistenz durch den kontinuierlichen Abgleich der deklarativen Richtlinien mit dem Netzwerk gewahrt.  

IBN: Das Rückgrat der skalierbaren Cloud-Performance

Die zusätzliche Abstraktionsschicht, die durch einen absichtsbasierten Ansatz bereitgestellt wird, ist erforderlich, um die Skalierung, Änderungsrate und Leistung zu erreichen, die für Cloudworkloads erforderlich sind.

Wenn Sie Tausende oder mehr dynamische Instanzen einer "Anwendung" haben, die sich ständig ändern, können Menschen nicht auf der Überholspur sein, um Richtlinien zu aktualisieren. Eine absichtsbasierte Schnittstelle "komprimiert" den Regelraum aus der Perspektive des Benutzers und verbirgt die ganze Magie, ihn wahr werden zu lassen, hinter dieser Schnittstelle. Sie ermöglicht es, Instanzen mit ähnlichem/identischem Verhalten als eine Gruppe zu behandeln, auf die die Richtlinie angewendet werden kann.

Wenn Ihre Absicht lautet: "Dinge in Gruppe A können mit Dingen in Gruppe B kommunizieren", erstellen Sie eine einfache Regel, die sich nie ändern muss. Es ist die richtige Regel und führt zum richtigen Verhalten, unabhängig davon, ob es keine Instanzen, eine, zwei, drei oder eine Milliarde Instanzen auf einem einzelnen Server oder Millionen gibt. Es gibt nur eine Regel, aber ihre Implementierung in einem großen System kann dynamische Aktualisierungen von einer Milliarde Firewall-Regeln in hunderttausend Firewalls erfordern.

Es ist die Entwicklung dieser riesigen, verteilten, automatisierten Continuous Reconciliation Loop Controller, die es ermöglichen, globale Netzwerkrichtlinien für groß angelegte verteilte Systeme zu implementieren, die von globalen Unternehmen zunehmend in der Cloud aufgebaut werden.

Die Zeiten einer Excel-Tabelle mit den Regeln für alle Ihre Firewalls sind längst vorbei – jede manuelle, individualisierte Vorgehensweise zur "Programmierung von Firewalls" für größere Systeme ist ebenso obsolet.

Moderne Cloud-Sicherheit setzt auf IBN

IBN hat still und leise die gesamte Fahrt auf dem Hype-Zyklus genommen. Sie ist so tief in die Grundlagen der modernen Vernetzung eingewoben, dass sie nicht mehr mit einem Schlagwort verbunden ist.

Die Tatsache, dass mehrere Parteien isoliert konzeptionell ähnliche Lösungen erfunden haben, ist immer ein starkes Zeichen dafür, dass etwas Wichtiges passiert. Die Personen, die diese Arbeit geleistet haben, sind weitgehend unbekannt, aber sie wissen, dass sie dazu beigetragen haben, die erstaunlichen Dinge zu ermöglichen, die wir heute in der Cloud tun können.

Diese Fähigkeit erweist sich als umso wichtiger, da Cyberbedrohungen zunehmen und insbesondere der Schutz von Zero-Trust-Netzwerken noch wichtiger wird. Die zuverlässige, skalierbare Natur von IBN ermöglicht es Plattformen wie Illumio wiederum, zuverlässige, skalierbare Sicherheit in der Cloud anzubieten.

Erfahren Sie hier mehr darüber, wie Illumio CloudSecure Sicherheitsverletzungen in der Hybrid Cloud eindämmt.

Sind Sie daran interessiert, Ihr Cloud-Netzwerk mit Illumio Zero Trust Segmentation zu sichern? Kontaktieren Sie uns noch heute für eine Beratung und Demo.