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:


































Installationsmethode: Layer 1:

Ingress Controller
Layer 2:

Mid-Tier Service
Layer 3:

App Tier

1. Agent und Module im selben App-Container

*

*

2. Agent + Module in verschiedenen Containern

*

*

3. Agent im Reverse-Proxy-Modus im selben Container wie die App

*

4. Agent im Reverse-Proxy-Modus im Sidecar-Container

*

*


* Beispiel für Installationsmethoden, siehe unten.

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.

blog1 Method 1 Pod Container — Agent and Module

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.

blog2 Method 2 Multi-Container — Agent and Module

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.

blog3 Method 3 Pod Container — Agent in Reverse Proxy Mode

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.

blog Method 4 Pod Multi-Container — Agent in Reverse Proxy in Sidecar Container

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.

blog5 Layer 1 Method 1 Ingress Pod Container — NGINX or HAProxy

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.

blog6 Layer 1 Method 2 Ingress Pod Multi-Container — NGINX or HAProxy

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.

blog7 Layer 2 Method 4 Multi-Service — Agent in Reverse Proxy

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.

Brendon Macaraeg
Senior Director of Product Marketing
Veröffentlicht am

Lesedauer: 5 Min.

Sie möchten sich mit einem Experten austauschen?
Sprechen Sie mit einem Experten
Diesen Beitrag teilen
Brendon Macaraeg
Senior Director of Product Marketing

Brendon Macaraeg ist Senior Director of Product Marketing bei Fastly. Bevor er zu Fastly kam, leitete er das Produktmarketing-Team bei Signal Sciences und davor konzentrierte er sich auf die Steigerung der Markenbekanntheit und die Vermarktung der Sicherheitsprodukte von CrowdStrike und Symantec. In seiner Freizeit verbringt Brendon viel Zeit in der Natur mit seiner Frau und seinen Kindern.

Sie möchten loslegen?

Setzen Sie sich mit uns in Verbindung oder erstellen Sie einen Account.