Was ist eine Kubernetes-WAF?

Eine Kubernetes-WAF ist eine Web Application Firewall, die dazu dient, in Kubernetes-Umgebungen ausgeführte Webanwendungen und APIs vor bösartigem Traffic auf dem Anwendungs-Layer zu schützen. Sie ist ein wichtiger Bestandteil der Kubernetes-Sicherheit.

Kubernetes erleichtert die Bereitstellung, Skalierung und Verwaltung containerisierter Apps, schützt diese Anwendungen jedoch nicht automatisch vor Bedrohungen wie SQL Injection, Cross-Site-Scripting (XSS), Command Injection, bösartigen Bots oder anderen Webangriffen. Eine WAF fügt einen Anwendungssicherheits-Layer hinzu, der HTTP- und HTTPS-Anfragen analysiert und bösartige Aktivitäten erkennen, blockieren oder protokollieren kann, bevor sie geschützte Workloads erreichen.

Je nach Architektur kann eine WAF an der Edge, zusammen mit der Kubernetes-Ingress-Infrastruktur oder innerhalb der Kubernetes-Umgebung selbst betrieben werden. Der richtige Ansatz hängt von den Anwendungen, der Traffic-Architektur, den Performance-Anforderungen und dem Sicherheitsmodell eines Unternehmens ab.

Wie funktioniert eine Kubernetes-WAF?

Eine Kubernetes-WAF ist eine WAF, die auf Kubernetes bereitstellte Anwendungen und APIs schützt. Eine herkömmliche WAF sitzt zwischen Nutzern und einer Webanwendung und analysiert eingehende Anfragen auf bösartige Aktivitäten. Dasselbe Prinzip gilt für Kubernetes, aber die Umgebung hinter der WAF kann aus vielen Containern, Pods, Services, APIs und Microservices bestehen, die sich dynamisch ändern und skalieren können.

Eine Kubernetes-Anwendung hat möglicherweise einen Anfragepfad ähnlich wie diesen:

Nutzer – CDN/Edge – WAF – Kubernetes-Ingress oder -Gateway – Service – Pod

Die genaue Position der WAF variiert. Einige Unternehmen deployen Sicherheitssoftware in ihren Kubernetes-Clustern. Andere prüfen den Traffic mithilfe einer Cloud- oder Edge-WAF, bevor er den Cluster erreicht. Hybride Ansätze können mehr als einen Durchsetzungspunkt verwenden.

Das Ziel ist dasselbe: bösartigen App-Traffic zu identifizieren und zu stoppen, bevor er Kubernetes-Workloads instrumentalisieren oder beeinträchtigen kann.

Kubernetes-WAF-Prozessablauf
Eine Kubernetes-WAF überprüft Anfragen auf dem Anwendungs-Layer und wendet Sicherheitslogik an, bevor sie geschützte Workloads erreichen können.

Eine typische Anfrage könnte folgende Schritte durchlaufen:

Ein Nutzer oder Client sendet eine HTTP-Anfrage. Die Anfrage könnte für eine Website, API oder einen anderen über das Internet zugänglichen Service bestimmt sein, der auf Kubernetes ausgeführt wird.
Die WAF prüft die Anfrage. Je nach Deployment kann dies auf der Edge oder näher am Kubernetes-Workload geschehen.
Die WAF analysiert Informationen auf dem Anwendungs-Layer. Sie kann Elemente wie URLs, Parameter, Header, Cookies, Anfrage-Bodys und API-Payloads überprüfen.
Sicherheitsregeln und Erkennungsmechanismen bewerten den Traffic. Das System ermittelt, ob die Anfrage legitim, verdächtig oder bösartig erscheint.
Eine Maßnahme wird ergriffen. Die WAF kann die Anfrage zulassen, blockieren, protokollieren oder eine andere konfigurierte Antwort anwenden.
Zulässiger Traffic wird an Kubernetes weitergeleitet. Die Anfrage kann dann den entsprechenden Loadbalancer, Ingress Controller oder das Gateway zum Kubernetes-Service und letztlich zum relevanten Pod durchlaufen.

Moderne WAFs können Angriffssignaturen durch Verhaltensanalysen, Bedrohungsdaten, Rate Limiting, Bot Detection oder andere Sicherheitssignale ergänzen.

Warum benötigen Kubernetes-Umgebungen eine WAF?

Kubernetes bietet wichtige Infrastruktur- und Orchestrierungsfunktionen, ersetzt jedoch nicht die Sicherheit auf dem Anwendungs-Layer. Hier sind die Gründe, warum eine WAF in einer Kubernetes-Umgebung erforderlich ist:

Kubernetes-Anwendungen sind weiterhin Webanwendungen
Das Verschieben einer Anwendung in Container beseitigt keine Schwachstellen in ihrem Code. Eine auf Kubernetes gehostete Anwendung kann weiterhin SQL Injection, XSS, Command Injection, Pfad-Traversal, Authentifizierungsangriffen, API-Missbrauch und anderen Webbedrohungen ausgesetzt sein.

Kubernetes fördert verteilte Architekturen
Kubernetes wird häufig für Microservices und API-gesteuerte Anwendungen verwendet. Dies kann viele App-Endpunkte mit unterschiedlichen Funktionen, Anforderungen an den Datenzugriff und Risikoprofilen schaffen. APIs werden folglich zu einem wichtigen Teil der Angriffsfläche.

Kubernetes-Umgebungen ändern sich schnell
Pods können automatisch erstellt, zerstört und neu geplant werden. Anwendungen können außerdem mehrmals täglich über CI/CD-Pipelines aktualisiert werden. Die Sicherheitsarchitektur muss mit diesem dynamischen Modell funktionieren, anstatt sich auf statische Annahmen über die Infrastruktur zu stützen.

Über das Internet zugängliche Workloads werden kontinuierlich angegriffen
Öffentliche Anwendungen und APIs können Schwachstellen-Scans, Exploit-Versuche, Angriffe auf Anmeldedaten, bösartige Bots und DDoS-Traffic verzeichnen, unabhängig davon, ob das Backend auf Kubernetes, virtuellen Maschinen oder physischen Servern ausgeführt wird.

Wie eine WAF hilft
Kubernetes-Sicherheit umfasst mehrere unterschiedliche Aspekte. Cluster-Konfiguration, Secrets-Management, Netzwerk-Richtlinien, Identitäts- und Zugriffsmanagement, Container-Sicherheit, Bildscanning, Laufzeitsicherheit und WAF-Schutz lösen verschiedene Probleme.

Eine WAF trägt speziell zum Schutz des Anwendungs-Layers bei. Sie sollte nicht als Ersatz für die Absicherung der Kubernetes-Plattform selbst behandelt werden.

Vor welchen Bedrohungen kann eine Kubernetes-WAF schützen?

Je nach WAF kann der Schutz auf dem Anwendungs-Layer unter anderem folgende Angriffe abwehren:

SQL Injection
Cross-Site Scripting
Command Injection
Path Traversal
Bösartige HTTP-Anfragen
Ausnutzung bekannter Sicherheitslücken
API-Angriffe
Scannen und Sondieren von Apps

In Kombination mit komplementären Technologien können Organisationen auch bösartige Bots, Angriffe auf Zugangsdaten, Scraping, DDoS-Angriffe auf dem Anwendungs-Layer und andere Formen von automatisiertem Missbrauch bekämpfen.

Die OWASP Top 10 sind eine nützliche Referenz zum Verständnis der wichtigsten Kategorien von Sicherheitsrisiken für Webanwendungen. Man sollte jedoch nicht erwarten, dass eine WAF jedes OWASP-Risiko eliminiert, da einige Schwachstellen das Design der Anwendung, die Autorisierung, die Konfiguration oder die Geschäftslogik betreffen, die in der Anwendung selbst behoben werden müssen.

Was sind die Best Practices für die Bereitstellung einer WAF mit Kubernetes?

Eine WAF ist am effektivsten, wenn sie Teil einer breiteren Kubernetes- und Anwendungssicherheitsstrategie ist.

1. Schützen Sie Anwendungen nach Möglichkeit, bevor Traffic den Cluster erreicht
Eine auf der Edge bereitgestellte WAF kann bösartige Anfragen erkennen, bevor sie Kubernetes-Netzwerk-, Ingress-, Rechen- und Anwendungsressourcen verbrauchen. Die vorgelagerte Reduzierung unerwünschten Traffics kann sowohl die Sicherheit als auch die Effizienz der Infrastruktur verbessern.

2. Schützen Sie APIs ebenso wie Webseiten
In Kubernetes-Umgebungen werden häufig API-gesteuerte Microservices gehostet. Erfassen Sie extern zugängliche APIs und stellen Sie sicher, dass Sicherheitsrichtlinien API-Endpoints berücksichtigen, anstatt nur herkömmlichen Browser-Traffic zu schützen.

3. Schränken Sie direkten Zugriff auf Origins ein
Wenn eine Anwendung Internet-Traffic über einen Edge-Sicherheits-Layer empfangen soll, sollten Angreifer diesen Layer nicht einfach umgehen können, indem sie sich direkt mit einem exponierten Origin verbinden. Beschränken Sie, sofern die Architektur es zulässt, den Origin-Zugriff auf autorisierte Traffic-Pfade.

4. Integrieren Sie Sicherheit in CI/CD
Kubernetes-Deployments sind häufig automatisiert, daher sollte sich die Sicherheit in dasselbe betriebliche Modell einfügen. Infrastructure-as-Code, versionskontrollierte Richtlinien, automatisierte Sicherheitstests und wiederholbare Deployments können Konfigurationsdrift reduzieren.

5. Starten Sie mit Transparenz
Bevor Sie Traffic aggressiv blockieren, sollten Sie verstehen, was die WAF erkennt. Überwachungs- oder Logging-Modi können Teams dabei helfen, potenzielle False Positives zu evaluieren und das normale Verhalten der Anwendung zu verstehen, bevor neue Regeln durchgesetzt werden.

6. Halten Sie die Sicherheitsrichtlinien überschaubar
Mehr Regeln sorgen nicht zwangsläufig für bessere Sicherheit. Übermäßig komplexe Richtlinien können schwer zu verwalten sein und zu False Positives führen. Priorisieren Sie besonders wichtige Schutzmaßnahmen und überprüfen Sie veraltete Ausnahmen regelmäßig.

7. Kombinieren Sie WAF- und Bot-Schutz
Eine valide HTTP-Anfrage kann dennoch bösartig sein, wenn sie tausendfach automatisiert wird. Bot-Management kann eine WAF ergänzen, indem es bösartige Automatisierungen bei Aktivitäten wie Credential Stuffing, Scanning, Scraping und App-Missbrauch identifiziert.

8. Schützen Sie sich vor DDoS-Angriffen
Eine WAF sollte nicht die einzige Verteidigungsmaßnahme gegen Denial-of-Service-Angriffe sein. Verwenden Sie einen geeigneten Netzwerk- und Anwendungs-Layer-DDoS-Schutz, damit Angriffs-Traffic abgemildert werden kann, bevor er Kubernetes- oder App-Ressourcen erschöpft.

9. Überwachen Sie Sicherheitsereignisse zentral
Integrieren Sie WAF-Sicherheits-Telemetrie bei Bedarf mit Logging-, Sicherheitsinformations- und Ereignismanagement- sowie Observability-Plattformen. Entwicklungs-, Betriebs- und Sicherheitsteams sollten in der Lage sein, Angriffe zu untersuchen, ohne Informationen manuell über einzelne Pods hinweg korrelieren zu müssen.

10. Beheben Sie Schwachstellen in der App
Ein WAF fügt eine wichtige Verteidigungsschicht hinzu, ersetzt aber nicht die sichere Entwicklung. Patchen Sie weiterhin Abhängigkeiten, testen Sie Anwendungen, korrigieren Sie unsichere Konfigurationen, implementieren Sie eine starke Autorisierung und beheben Sie anfälligen Code.

Sollte eine WAF innerhalb oder außerhalb von Kubernetes laufen?

Beide Ansätze sind möglich.

WAF in Kubernetes
Eine WAF oder Sicherheitskomponente kann innerhalb oder in der Nähe der Kubernetes-Umgebung betrieben werden und sich potenziell in Ingress-Infrastruktur oder App-Services integrieren. Dieser Ansatz kann Unternehmen Deployment-Flexibilität und Sicherheitskontrollen nahe an einzelnen Workloads bieten.

Allerdings kann eine Cluster-interne Sicherheitsinfrastruktur Cluster-Ressourcen verbrauchen und muss möglicherweise mit dem Angriffs-Traffic skalieren.

WAF außerhalb von Kubernetes
Eine externe oder Edge-WAF prüft Anfragen, bevor sie Kubernetes erreichen. Dadurch kann verhindert werden, dass bösartige Anfragen Ingress-, Netzwerk-, Rechen- und App-Ressourcen innerhalb des Clusters verbrauchen. Zudem wird der Layer zur Sicherheitsdurchsetzung von der Infrastruktur entkoppelt, die er schützt.

Hybrid-Deployment
Einige Organisationen kombinieren Edge-Sicherheit mit Kontrollen, die näher an den Workloads liegen. Das geeignete Modell hängt von der Architektur, den Compliance-Anforderungen, den betrieblichen Praktiken, den Anwendungen und dem Bedrohungsmodell der Organisation ab.

Wer braucht eine Kubernetes-WAF?

Unternehmen sollten WAF-Schutz in Betracht ziehen, wenn ihre Kubernetes-Umgebungen über das Internet zugängliche Webanwendungen oder APIs hosten.

SaaS-Anbieter
SaaS-Anwendungen stellen in der Regel Anmeldesysteme, APIs, Dashboards und kundenorientierte Funktionen bereit, die von Angreifern ins Visier genommen werden können.

E-Commerce-Unternehmen
Auf Kubernetes gehostete Onlineshops, Checkout-Systeme, Suchfunktionen und APIs können Injection-Versuchen, bösartigen Bots, Account-Angriffen und DDoS-Bedrohungen ausgesetzt sein.

Finanzdienstleistungen
Anwendungen, die Finanzinformationen oder -transaktionen verarbeiten, können neben starker Authentifizierung, Autorisierung, Verschlüsselung und sicherer Entwicklung von mehrschichtiger Anwendungssicherheit profitieren.

Medien- und Verlagsunternehmen
Content-Plattformen mit hohem Traffic können Schwachstellen-Scans, Scraping, automatisiertem Missbrauch und plötzlichen Traffic-Spitzen ausgesetzt sein.

API-First-Unternehmen
Unternehmen, die eine große Anzahl öffentlicher APIs betreiben, benötigen Kontrollen, die in der Lage sind, App-Endpunkte zu schützen, ohne sich ausschließlich auf herkömmliche Netzwerksicherheit zu verlassen.

Unternehmen, die Microservices einsetzen
Wenn Unternehmen monolithische Apps in verteilte Services aufteilen, kann die Anzahl der APIs und Anwendungsschnittstellen erheblich steigen. Eine WAF kann an der Stelle, an der diese Anwendungen nicht vertrauenswürdigem Traffic ausgesetzt sind, eine zusätzliche Sicherheitsebene bieten.

Ist Kubernetes-Sicherheit dasselbe wie Anwendungssicherheit?

Nein. Die Kubernetes-Sicherheit umfasst die zugrunde liegende Container-Orchestrierungsumgebung, einschließlich Bereichen wie:

Clusterzugriff
RBAC
Geheimnisse
Netzwerkrichtlinien
Containerabbildungen
Pod-Sicherheit
Node-Sicherheit
Laufzeitsicherheit
Lieferkettensicherheit

Anwendungssicherheit konzentriert sich auf die Software, die auf dieser Infrastruktur läuft, einschließlich ihres Codes, ihrer APIs, der Authentifizierung, der Autorisierung und der Verarbeitung von Nutzereingaben. Eine WAF befasst sich in erster Linie mit Bedrohungen auf dem Anwendungs-Layer. Organisationen, die Kubernetes einsetzen, müssen daher sowohl die Plattform als auch die darauf laufenden Anwendungen absichern.

Reicht eine Kubernetes-WAF aus, um APIs zu schützen?

Kurze Antwort: nein. Eine WAF ist ein wichtiger Layer, aber umfassende API-Sicherheit erfordert im Allgemeinen zusätzliche Kontrollen.

Unternehmen sollten auch Folgendes berücksichtigen:

Starke Authentifizierung und Autorisierung
API-Erkennung und -Inventar
Schema- und Eingabevalidierung
Rate Limiting
Bot-Schutz
DDoS-Abwehr
Sichere API-Entwicklung
Logging und Monitoring
Angemessener Schutz vor Missbrauch der Geschäftslogik

Ziel ist es, sowohl herkömmliche Web-Exploits als auch Angriffe zu verhindern, die ansonsten legitime API-Funktionen missbrauchen.

Wie ergänzt Fastly Kubernetes-Umgebungen?

Fastly kann in Kubernetes gehostete Anwendungen schützen, ohne dass sich der primäre Sicherheitsdurchsetzungspunkt in jedem Kubernetes-Cluster befinden muss. Bei einer typischen Architektur kann die Edge-Cloud-Plattform von Fastly vor in Kubernetes gehosteten Anwendungen platziert werden:

Nutzer – Fastly-Edge – Kubernetes-Infrastruktur – App-Workloads

Eingehender App-Traffic erreicht zuerst Fastly, wo Bereitstellungs- und Sicherheitskontrollen angewendet werden können, bevor zulässige Anfragen an die Kubernetes-Umgebung weitergeleitet werden. Diese Architektur kann Unternehmen dabei helfen, bösartigen oder unnötigen Traffic von der Kubernetes-Infrastruktur fernzuhalten, während sie gleichzeitig einen konsistenten Sicherheits-Layer über Cluster und Anwendungsumgebungen hinweg bereitstellt.

Wie funktioniert die Fastly Next-Gen WAF mit Kubernetes?

Die Fastly Next-Gen WAF kann auf Kubernetes gehostete Webanwendungen und APIs schützen. Sie unterstützt mehrere Deployment-Modelle, darunter Cloud-WAF-Deployments auf der Fastly-Edge sowie Bereitstellungsoptionen näher an der Anwendungsinfrastruktur. Dies bietet Organisationen Flexibilität bei der Entscheidung, wo die Überprüfung der Anwendungssicherheit stattfinden soll.

Die WAF von Fastly nutzt die SmartParse-Technologie, um Anfrageparameter zu analysieren und bösartiges Anwendungsverhalten zu erkennen. Anstatt sich ausschließlich auf herkömmliche musterbasierte Regeln zu verlassen, ist SmartParse darauf ausgelegt, die Absicht hinter Anfragen zu erkennen und False Positives zu reduzieren.

Für Kubernetes-Anwendungen kann dies Schutz vor Angriffsklassen wie den folgenden bieten:

SQL Injection
Cross-Site Scripting
Command Injection
Path Traversal
Sonstige Angriffe auf den Anwendungs-Layer

Ein Edge-Deployment kann außerdem die Menge an bösartigem Traffic reduzieren, der Kubernetes-Cluster überhaupt erst erreicht.

Kann Fastly mehrere Kubernetes-Cluster schützen?

Ja. Eine edgebasierte Sicherheitsarchitektur kann nützlich sein, wenn Anwendungen mehrere Cluster, Regionen oder Infrastrukturanbieter umfassen. Anstatt für jeden Cluster einen völlig separaten, öffentlich zugänglichen Sicherheits-Stack zu erfordern, kann der Traffic über Fastly geleitet werden, bevor er an den entsprechenden App-Origin weitergeleitet wird.

Dies kann für Unternehmen nützlich sein, die Folgendes betreiben:

Mehrere Kubernetes-Cluster
regionsübergreifende Bereitstellungen
Hybrid-Cloud-Anwendungen
Multi-Cloud-Architekturen
Kubernetes- neben Nicht-Kubernetes-Infrastruktur

Die genaue Konfiguration hängt von der Netzwerk- und Ursprungsarchitektur der App ab.

Welche weiteren Sicherheitsfunktionen von Fastly ergänzen den Kubernetes-WAF-Schutz?

WAF-Schutz ist ein Teil des umfassenderen Anwendungssicherheitsportfolios von Fastly.

Fastly Bot Management
Fastly Bot Management hilft dabei, automatisierten Traffic zu identifizieren und zu kontrollieren. Dies kann den WAF-Schutz vor Bots ergänzen, die an Schwachstellen-Scans, Credential-Angriffen, Scraping und App-Missbrauch beteiligt sind.

Fastly DDoS Protection
Fastly DDoS Protection trägt dazu bei, Anwendungen vor Angriffen zu schützen, die darauf abzielen, Netzwerk- oder Anwendungsressourcen zu überlasten. Die Abwehr von Angriffen auf der Edge kann verhindern, dass große Mengen an unerwünschtem Traffic die Kubernetes-Infrastruktur erreichen.

Rate Limiting
Rate Limiting kann dazu beitragen, sensible und rechenintensive App-Endpoints zu schützen. Für Kubernetes-Anwendungen kann dies besonders nützlich für APIs, Authentifizierungs-Endpoints, Suchfunktionen und andere Services sein, bei denen übermäßige Anfragen Backend-Ressourcen verbrauchen könnten.

CDN und Caching
Das CDN von Fastly kann geeignete Inhalte auf der Edge cachen und so Anfragen reduzieren, die Kubernetes-Workloads erreichen müssen. Dies kann die App-Performance verbessern und gleichzeitig den Bedarf an Ingress-Controllern, Services, Pods, Datenbanken und sonstiger Origin-Infrastruktur reduzieren.

Echtzeittransparenz
Fastly bietet Funktionen für Echtzeit-Logging und Observability, die Sicherheits- und Betriebsteams dabei unterstützen können, Traffic-Muster zu verstehen und bösartige Aktivitäten zu untersuchen. Dies kann die Kubernetes-native Observability ergänzen, indem es Transparenz über den Traffic schafft, bevor dieser den Cluster erreicht.