Sieben Bereitstellungsmöglichkeiten für die Fastly Next-Gen WAF in Kubernetes

Im Sport haben sich Trainer bei Strategiebesprechungen mit ihren Teams traditionell auf Spielpläne aus Papier verlassen. Inzwischen nutzen viele von ihnen Tablet-PCs, um schnell und flexibel über wichtige Spielzüge und sportliche Leistungen zu sprechen. Ähnlich verhält es sich mit DevOps-Teams, die neue Tools und Frameworks wie Anwendungscontainer und Kubernetes – ein System zur Container-Orchestrierung – nutzen, um Apps effizienter und schneller zu erstellen und zu veröffentlichen.

Container wie Docker packen eine Anwendung mit allem, was sie braucht, damit sie in jeder Umgebung zuverlässig läuft. Auf diese Weise können Entwickler ihren Code schneller veröffentlichen. Im Zuge der zunehmenden Nutzung von Containern hat sich Kubernetes zu einem beliebten Tool entwickelt, um die Bereitstellung und Verwaltung von containerisierten Anwendungen in großem Umfang zu automatisieren. Wie es im Cloud Native Survey Report 2021 der CNCF heißt:

• Inzwischen nutzen oder evaluieren ganze 96 % der Unternehmen Kubernetes – ein beträchtlicher Anstieg im Vergleich zu 83 % im Jahr 2020 und gerade einmal 78 % im Jahr davor.

• 93 % der Unternehmen nutzen oder planen den Einsatz von Containern in der Produktivumgebung (ein leichter Anstieg verglichen mit den 92 % aus der Umfrage des Vorjahres).

• Schätzungen zufolge nutzen inzwischen über 5,6 Millionen Entwickler Kubernetes. 

Fastly weiß, wie wichtig es ist, Kubernetes Kunden flexible Installationsoptionen zu bieten. In einem früheren Blogpost haben wir eine Möglichkeit vorgestellt, wie Sie die Fastly Next-Gen WAF (powered by Signal Sciences) mit Kubernetes zur automatischen Skalierung des Layer-7-Schutzes Ihrer Webanwendungen einsetzen können. In diesem Beitrag stellen wir Ihnen eine umfassende Liste von Möglichkeiten für die Installation der Fastly Next-Gen WAF mit Kubernetes vor.

Zunächst aber ein kurzer Überblick über unsere Softwarekomponenten: Die von uns entwickelte patentierte Methode für die Kommunikation zwischen einem Agent und einem Module, die innerhalb der Infrastruktur des Kunden ausgeführt werden und bandbreitenunabhängig mit unserer Cloud Engine kommunizieren, liefert aktuelle und erweiterte Informationen. Das Module wird nicht benötigt, wenn die Fastly Next-Gen WAF im Reverse-Proxy-Modus ausgeführt wird. Mehr dazu aber später.

Sie können sich unsere Bereitstellungsoptionen als 3-mal-4-Matrix vorstellen: Es gibt drei „Layer“, auf denen Sie die Fastly Next-Gen WAF in Kubernetes installieren können, und vier „Methoden“, wie Sie die Bereitstellung vornehmen können.

Layer

Wir arbeiten uns von der obersten Ebene des Stacks bis hinunter zur Anwendungsebene vor und erläutern, warum Sie sich für die eine oder die andere Ebene entscheiden sollten, je nachdem, wie Ihr Unternehmen die Softwarebereitstellung handhabt.

An der Spitze befindet sich der Kubernetes Ingress Controller. Diese Option bietet sich vor allem dann an, wenn Sie a) über einen Ingress Controller verfügen und b) ein Team haben, das die Sicherheit aller Anwendungen, die sich unterhalb/hinter dem Ingress Controller befinden, zentralisieren möchte.

An zweiter Stelle kommt der Middle-Tier- oder Service-Layer, für den Sie sich entscheiden sollten, wenn Sie a) keinen Ingress Controller haben oder b) einen anderen Loadbalancer für den Front Traffic einsetzen, die Fastly Next-Gen WAF aber aus bestimmten Gründen nicht dort installieren möchten (auch wenn dies selbstverständlich möglich ist).

An dritter Stelle steht der Anwendungs-Layer, der dann für Sie infrage kommt, wenn Sie Ihre Anwendungsteams in die Lage versetzen wollen, die Installation selbst durchzuführen.

Methoden

Innerhalb jedes der beschriebenen Layer können Sie die Fastly Next-Gen WAF in Verbindung mit Kubernetes auf eine der folgenden vier Arten nutzen:

1. Module und Agent im selben Container

2. Module und Agent in zwei separaten Sidecar-Containern

3. Agent im Reverse-Proxy-Modus im selben Anwendungscontainer

4. Agent im Reverse-Proxy-Modus in einem Sidecar-Container des Anwendungscontainers

Aus drei Layer und vier Bereitstellungsmethoden ergeben sich insgesamt 12 Installationsoptionen. Es muss wohl kaum betont werden, wie viel Flexibilität Container und Kubernetes bieten. Die Fastly Next-Gen WAF unterstützt zwar alle 12 Optionen, aber wir konzentrieren uns in diesem Blogpost auf die sieben in der folgenden Tabelle mit Sternchen versehenen Methoden:

Methode 1: Pod-Container – Agent und Module

Mit dieser Methode lassen sich Agent und Module im selben Kubernetes Pod-Container bereitstellen. Der Agent und das Module befinden sich auf derselben Ebene wie die Anwendung.

Methode 2: Multi-Container – Agent und Module

Bei dieser Option sind Module und Agent getrennt. Das Module wird zusammen mit der App in einem einzigen Container und der Agent in einem separaten Container bereitgestellt. Obwohl sich das Module und der Agent in verschiedenen Containern befinden, befinden sich beide im selben Kubernetes Pod. Der Container des Agents und der des Modules teilen sich ein Medium zur Kommunikation über einen Domain Socket.

Methode 3: Pod-Container – Agent im Reverse-Proxy-Modus

Falls der Agent der Fastly Next-Gen WAF im Reverse-Proxy-Modus ausgeführt wird, kann er sich im selben Pod-Container wie die Anwendung befinden. Ähnlich wie bei Option 1 befindet sich die Fastly Next-Gen WAF hier auf einer Ebene mit der Anwendung. Der einzige Unterschied ist die Konfiguration des Modules.

Methode 4: Pod-Multi-Container – Agent im Reverse-Proxy-Modus in einem Sidecar-Container

Ähnlich wie bei Option 2 wird der Agent hier im Reverse-Proxy-Modus ohne Module bereitgestellt – mit dem Unterschied, dass sich der Agent in einem anderen Container als die Anwendung befindet. Die Anfrage durchläuft den Agent-Container, bevor sie an den Anwendungscontainer weitergeleitet wird. Agent- und Anwendungscontainer koexistieren im selben Pod.

Für Layer 1 und 2 wird auf den Ingress-Service zurückgegriffen. Im Gegensatz zu herkömmlichen WAFs, bei denen die Regeln für jede der hinter dem Ingress-Service steckenden Anwendungen individuell angepasst werden müssen, kommt die Fastly Next-Gen WAF ohne diesen Overhead aus, da wir anhand unserer eigens entwickelten SmartParse Methode Anfragen dynamisch erkennen.

Layer 1, Methode 1: Ingress-Pod-Container – NGINX oder HAProxy

Diese Option ermöglicht die Bereitstellung des Modules und des Agents im selben Container, in dem sich auch die NGINX oder HAProxy Ingress-Pods befinden. Das Module sitzt auf NGINX oder HAProxy, während sich der Agent im selben Container befindet. Alle Anfragen laufen über den Ingress-Pod und werden bei Bedarf automatisch skaliert. Der Anwendungs-Pod befindet sich hinter dem Ingress-Pod.

Layer 1, Methode 2: Ingress-Pod-Multi-Container – NGINX oder HAProxy

Hier verhält sich alles ähnlich wie bei Option 6 – mit dem einzigen Unterschied, dass sich das Module und der Agent in separaten Containern innerhalb desselben Ingress-Pods befinden. Genau wie bei Option 2 müssen Agent- und Module-Container das Medium zur Kommunikation über einen Domain Socket gemeinsam nutzen. Diese Bereitstellungsmethode schützt Kubernetes Cluster vor Zugriff aus dem offenen Internet.

Layer 2, Methode 4: Multi-Service – Agent im Reverse-Proxy-Modus

Bei dieser Bereitstellungsoption wird der Agent im Reverse-Proxy-Modus und in einem von der Anwendung getrennten Pod ausgeführt. Der Agent-Pod empfängt und prüft die Anfrage und blockiert oder leitet sie an den Anwendungs-Pod weiter. Auf diese Weise lassen sich Agent und Anwendung getrennt voneinander automatisch skalieren.

Ultimative Flexibilität bei der Absicherung von Anwendungen und Microservices

Die Fastly Next-Gen WAF bietet Ihnen ultimative Flexibilität beim Schutz Ihrer Anwendungen und Microservices – und zwar unabhängig davon, wie Ihr DevOps-Team Container mit Kubernetes einsetzt. Diese Installationsbeispiele sollen unseren Kunden Ideen dafür liefern, wie sie ihre Anwendungen vom ersten Tag an und selbst dann schützen können, wenn sich ihre Anwendungsbereitstellung mit Kubernetes ändert.