Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit

Jenn GileLeiter Produktmarketing, NGINX

Redaktion – Dieser Beitrag ist Teil einer zehnteiligen Serie:

1. Komplexität mit produktionsreifem Kubernetes reduzieren
2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Traffic-Management
3. So verbessern Sie die Transparenz in Kubernetes
4. Sechs Möglichkeiten, Kubernetes mithilfe von Traffic-Management-Tools abzusichern
5. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
6. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit (dieser Beitrag)
7. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standardlösung vs. kommerzielle Lösung
8. Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller
9. So wählen Sie ein Service Mesh aus
10. Leistungstests von NGINX Ingress Controllern in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können die vollständige Blogreihe auch als kostenloses E-Book herunterladen: „Kubernetes von der Test- in die Produktionsumgebung überführen“.

In Teil 1 unseres Leitfadens zur Auswahl eines Ingress-Controllers haben wir erläutert, wie Sie Ihre Anforderungen ermitteln. Doch für Produkttests ist es noch immer zu früh! In diesem Beitrag erklären wir, wie der falsche Ingress-Controller Ihre Release-Geschwindigkeit verlangsamen und Sie sogar Kunden kosten kann. Wie jedes andere Tool können auch Ingress-Controller Risiken mit sich bringen und die zukünftige Skalierbarkeit beeinträchtigen. Sehen wir uns an, wie Sie Optionen ausschließen können, die möglicherweise mehr schaden als nutzen.

Risiken von Ingress-Controllern

Bei der Einführung eines Tools zur Datenverkehrssteuerung für Kubernetes sollten Sie drei konkrete Risiken berücksichtigen: Komplexität, Latenz und Sicherheit. Diese Aspekte hängen häufig miteinander zusammen: Tritt eines dieser Probleme auf, zeigen sich wahrscheinlich auch die anderen. Jedes davon kann durch einen Ingress-Controller verursacht werden. Ihr Unternehmen muss entscheiden, ob das jeweilige Risiko vertretbar ist. Verbraucher sind heutzutage anspruchsvoll, und alles, was das digitale Nutzungserlebnis beeinträchtigt, kann trotz überzeugender Funktionen inakzeptabel sein.

Komplexität – läuft sie dem Zweck einer Microservices-Architektur zuwider?

Die besten Kubernetes-Tools sind diejenigen, die den Zielen einer Microservices-Architektur entsprechen: Sie sind schlank und einfach konzipiert. Es ist möglich, einen äußerst funktionsreichen Ingress-Controller zu entwickeln, der diesen Prinzipien treu bleibt, doch das ist nicht immer die Regel. Manche Entwickler integrieren zu viele Funktionen oder verwenden komplizierte Skripte, um Fähigkeiten hinzuzufügen, die von der zugrunde liegenden Engine nicht nativ unterstützt werden. Das Ergebnis ist ein unnötig komplexer Ingress-Controller.

Und warum ist das wichtig? In Kubernetes kann sich ein übermäßig komplexes Tool negativ auf die Anwendungsleistung auswirken und die horizontale Skalierbarkeit Ihrer Bereitstellung einschränken. Einen übermäßig komplexen Ingress-Controller erkennen Sie in der Regel an seiner Größe: Je größer sein Ressourcenbedarf, desto komplexer ist das Tool.

Latenz – Verlangsamt der Ingress-Controller Ihre Anwendungen?

Ingress-Controller können aufgrund von Ressourcennutzung, Fehlern und Zeitüberschreitungen die Latenz erhöhen. Untersuchen Sie die zusätzliche Latenz sowohl bei statischen als auch bei dynamischen Bereitstellungen und schließen Sie Optionen aus, die gemäß Ihren internen Anforderungen zu einer inakzeptablen Latenz führen. Weitere Informationen dazu, wie sich Neukonfigurationen auf die Anwendungsgeschwindigkeit auswirken können, finden Sie unter „Leistungstests für NGINX Ingress Controller in einer dynamischen Kubernetes-Cloud-Umgebung“ in unserem Blog.

Sicherheit – Öffnet der Ingress-Controller Hackern Tür und Tor?

Common Vulnerabilities and Exposures (CVEs) sind im heutigen Internet allgegenwärtig, und die Zeit, die Ihr Ingress-Controller-Anbieter benötigt, um einen CVE-Patch bereitzustellen, kann darüber entscheiden, ob Sie geschützt sind oder Opfer eines Sicherheitsvorfalls werden. Je nach Risikotoleranz Ihres Unternehmens sollten Sie Lösungen ausschließen, bei denen die Bereitstellung von Patches länger als einige Tage (oder höchstens Wochen) dauert.

Neben CVEs bergen einige Ingress-Controller noch eine weitere potenzielle Sicherheitslücke. Stellen Sie sich folgendes Szenario vor: Sie arbeiten für einen Onlinehändler und benötigen Hilfe bei der Fehlerbehebung in der Konfiguration Ihres Open-Source-Ingress-Controllers. Kommerzieller Support ist nicht verfügbar, daher schildern Sie das Problem in einem Forum wie Stack Overflow. Jemand bietet seine Hilfe an und möchte die Konfigurations- und Protokolldateien des Ingress-Controllers und anderer Kubernetes-Komponenten auf mögliche Probleme untersuchen. Da Sie unter Druck stehen, das Problem schnell zu lösen, geben Sie die Dateien weiter.

Der „barmherzige Samariter“ hilft Ihnen bei der Lösung Ihres Problems, doch sechs Monate später stellen Sie eine Sicherheitsverletzung fest: Kreditkartennummern wurden aus Ihren Kundendaten gestohlen. Hoppla. Wie sich herausstellt, enthielten die von Ihnen weitergegebenen Dateien Informationen, die dazu genutzt wurden, in Ihre Anwendung einzudringen. Dieses Szenario verdeutlicht einen der wichtigsten Gründe, warum Unternehmen für Support bezahlen: Er garantiert Vertraulichkeit.

Hinweis zu OpenResty-basierten Ingress-Controllern

OpenResty ist eine auf NGINX Open Source basierende Webplattform, die LuaJIT, Lua-Skripte und NGINX-Module von Drittanbietern integriert, um den Funktionsumfang von NGINX Open Source zu erweitern. Es gibt wiederum mehrere auf OpenResty basierende Ingress-Controller, die unserer Ansicht nach im Vergleich zu unseren auf NGINX Open Source und NGINX Plus basierenden Ingress-Controllern potenziell zwei zusätzliche Risiken bergen:

• Zeitüberschreitungen – Wie bereits erwähnt, verwendet OpenResty Lua-Skripte, um erweiterte Funktionen zu implementieren, wie sie auch unser kommerzieller, auf NGINX Plus basierender Ingress Controller bietet. Eine dieser Funktionen ist die dynamische Neukonfiguration. Sie macht eine die Verfügbarkeit beeinträchtigende Anforderung von NGINX Open Source überflüssig – nämlich, dass die NGINX-Konfiguration neu geladen werden muss, wenn sich Service-Endpunkte ändern. Für die dynamische Neukonfiguration mit OpenResty wählt der Lua-Handler den Upstream-Service aus, an den die Anfrage weitergeleitet werden soll. Dadurch entfällt das erneute Laden der NGINX-Konfiguration. Lua muss die Backends jedoch kontinuierlich auf Änderungen prüfen, was Ressourcen beansprucht. Die Verarbeitung eingehender Anfragen dauert dadurch länger, sodass einige Anfragen ins Stocken geraten und die Wahrscheinlichkeit von Zeitüberschreitungen steigt. Mit zunehmender Anzahl von Benutzern und Services wächst die Lücke zwischen der Anzahl eingehender Anfragen pro Sekunde und der Anzahl, die Lua verarbeiten kann, exponentiell. Die Folgen sind höhere Latenz, größere Komplexität und höhere Kosten. Lesen Sie Performance-Tests für NGINX Ingress Controller in einer dynamischen Kubernetes-Cloud-Umgebung, um zu erfahren, wie stark Lua die Latenz erhöhen kann.
• Verzögerungen bei der Bereitstellung von CVE-Patches – Im Vergleich zu den Ingress Controllern von NGINX dauert es zwangsläufig länger, bis Patches für CVEs in Ingress Controllern verfügbar sind, die auf Tools wie OpenResty basieren, welche wiederum auf NGINX Open Source aufbauen. Wie wir ausführlich in Sicherheitslücken mit NGINX Plus schnell und einfach beheben erläutern, werden wir als Anbieter bei der Entdeckung einer CVE in NGINX in der Regel informiert, bevor die CVE öffentlich bekannt gegeben wird. Dadurch können wir einen Patch für NGINX Open Source und NGINX Plus veröffentlichen, sobald die CVE bekannt gegeben wird. Technologien, die auf NGINX Open Source basieren, erfahren möglicherweise erst zu diesem Zeitpunkt von der CVE. Unserer Erfahrung nach werden OpenResty-Patches deutlich später als unsere bereitgestellt – in einem kürzlich aufgetretenen Fall vier Monate später. Patches für einen auf OpenResty basierenden Ingress Controller benötigen zwangsläufig noch mehr Zeit, sodass böswillige Akteure reichlich Gelegenheit haben, die Sicherheitslücke auszunutzen.

Machen Sie Ihren Ingress Controller zukunftssicher

Auch wenn Sie gerade erst anfangen, sich mit Kubernetes zu beschäftigen, möchten Sie es wahrscheinlich eines Tages produktiv einsetzen. In vier zentralen Bereichen werden Ihre Anforderungen im Laufe der Zeit voraussichtlich steigen: Infrastruktur, Sicherheit, Support und Mandantenfähigkeit.

Infrastruktur – Werden Sie Kubernetes in Hybrid- oder Multi-Cloud-Umgebungen einsetzen?

Nur selten legt sich ein Unternehmen vollständig und dauerhaft auf einen einzigen Umgebungstyp fest. Häufiger nutzen Unternehmen eine Kombination aus lokalen Infrastrukturen und Cloud-Umgebungen, darunter Private Clouds, Public Clouds, Hybrid Clouds und Multi-Clouds. (Weitere Informationen zu den Unterschieden zwischen diesen Umgebungen finden Sie unter „Was ist der Unterschied zwischen Multi-Cloud und Hybrid Cloud?“.)

Wie bereits in Teil 1 dieser Reihe erwähnt, ist es verlockend, die in der jeweiligen Umgebung standardmäßig enthaltenen Tools zu verwenden. Allerdings bringen die standardmäßigen Ingress-Controller eine Reihe spezifischer Probleme mit sich. In Teil 3 dieser Reihe gehen wir auf alle Nachteile ein. Das im Hinblick auf die Zukunftssicherheit relevanteste Problem ist jedoch der Vendor-Lock-in: Ein cloudspezifischer Ingress-Controller lässt sich nicht in allen Ihren Umgebungen einsetzen. Die Verwendung standardmäßiger cloudspezifischer Tools schränkt Ihre Skalierbarkeit ein, da Ihnen nur zwei wenig attraktive Alternativen bleiben:

1. Versuchen Sie, die bestehende Cloud so anzupassen, dass sie all Ihre Anforderungen erfüllt
2. Schreiben Sie alle Ihre Konfigurationen für den Ingress-Controller in jeder neuen Umgebung neu – nicht nur für den Lastenausgleich, sondern auch für die Sicherheit!

Während die erste Alternative aus geschäftlichen Gründen oft nicht praktikabel ist, gestaltet sich auch die zweite schwierig, da sie zu einer unübersichtlichen Vielzahl von Tools führt, neue Sicherheitslücken schafft und Ihren Mitarbeitern eine aufwendige Einarbeitung abverlangt. Die dritte und effizienteste Alternative besteht darin, von Anfang an einen infrastrukturunabhängigen Ingress-Controller zu wählen, sodass Sie in all Ihren Umgebungen dasselbe Tool verwenden können.

Bei der Infrastruktur ist noch ein weiterer Aspekt zu berücksichtigen: Zertifizierungen. Nehmen wir als Beispiel die Red Hat OpenShift Container Platform (OCP). Wenn Sie OCP nutzen, wissen Sie wahrscheinlich bereits, dass der Red Hat Marketplace zertifizierte Operatoren für OCP anbietet, darunter den NGINX Ingress Operator. Die Zertifizierungsstandards von Red Hat geben Ihnen die Gewissheit, dass das Tool mit Ihrer Bereitstellung funktioniert und sogar einen gemeinsamen Support durch Red Hat und den Anbieter umfassen kann. Viele Unternehmen schreiben aus Sicherheits- und Stabilitätsgründen den Einsatz zertifizierter Tools vor. Selbst wenn Sie sich derzeit noch in der Testphase befinden, lohnt es sich daher, die Anforderungen Ihres Unternehmens an Produktionsumgebungen im Blick zu behalten.

Sicherheit – Wie sichern Sie Kubernetes von innen ab?

Die Zeiten, in denen Perimetersicherheit allein ausreichte, um Anwendungen und Kunden zu schützen, sind vorbei. Kubernetes-Anwendungen sind am besten geschützt, wenn sich die Sicherheitsmechanismen – einschließlich Authentifizierung und Autorisierung – in unmittelbarer Nähe der Anwendungen befinden. Da Unternehmen zunehmend eine Ende-zu-Ende-Verschlüsselung vorschreiben und innerhalb von Kubernetes ein Zero-Trust-Netzwerkmodell einführen, könnte künftig ein Service Mesh für Sie infrage kommen.

Was hat all das mit Ihrem Ingress-Controller zu tun? Eine ganze Menge! Die Sicherheit (Authentifizierung, Autorisierung, DoS-Schutz, Web Application Firewall) am Ingress-Punkt zu zentralisieren, ist sowohl aus Kosten- als auch aus Effizienzsicht äußerst sinnvoll. Und obwohl sich die meisten Service Meshes in die meisten Ingress-Controller integrieren lassen, kommt es entscheidend darauf an, wie diese Integration erfolgt. Ein Ingress-Controller, der zu Ihrer Sicherheitsstrategie passt, kann Ihnen während des gesamten Entwicklungsprozesses Ihrer Anwendung viel Kopfzerbrechen ersparen.

Lesen Sie Cloudnative Anwendungen sicher und ohne Geschwindigkeitseinbußen bereitstellen, um mehr über die Risiken bei der Bereitstellung cloudnativer Anwendungen zu erfahren, und Anwendungsdienste in Kubernetes bereitstellen, Teil 2, um mehr über die Faktoren zu erfahren, die den optimalen Einsatzort für Sicherheitstools bestimmen.

Support – Wie viel „auf sich allein gestellt“ können Sie sich leisten?

Wenn Teams Kubernetes gerade erst ausprobieren, hat Support – ob durch die Community oder ein Unternehmen – oft nicht die höchste Priorität. Das ist in Ordnung, wenn Ihre Teams viel Zeit haben, eigene Lösungen und Workarounds zu entwickeln. Beim Übergang zum Produktivbetrieb ist dies jedoch nicht nachhaltig. Selbst wenn Sie heute noch keinen Support benötigen, kann es sinnvoll sein, einen Ingress-Controller zu wählen, bei dem Sie später Support hinzubuchen können – oder der eine kostengünstige Supportstufe bietet, die sich bei zunehmender Skalierung erweitern lässt.

Mandantenfähigkeit – wie können sich mehrere Teams und Anwendungen eine Container-Umgebung sicher teilen?

Am Anfang gab es ein Team und eine App … fängt nicht jede Geschichte so an? Oft geht die Geschichte damit weiter, dass dieses eine Team seine Kubernetes-App erfolgreich entwickelt, woraufhin das Unternehmen weitere Dienste auf Kubernetes betreibt. Und natürlich gilt: mehr Dienste = mehr Teams = mehr Komplexität.

Um maximale Effizienz zu erreichen, setzen Unternehmen auf Mandantenfähigkeit und ein Kubernetes-Modell, das die von ihren Geschäftsprozessen vorgegebenen Zugriffs- und Isolationsanforderungen erfüllt und zugleich die Übersichtlichkeit und Kontrollmöglichkeiten bietet, die ihre Betreiber benötigen. Einige Ingress-Controller können Sie dabei unterstützen, diese Cluster mithilfe verschiedener Funktionen und Konzepte zu unterteilen: mehrere Ingresses, Klassen, Namespaces und Ressourcen mit begrenztem Geltungsbereich, die die Einrichtung rollenbasierter Zugriffskontrollen (RBAC) ermöglichen.

Nächster Schritt: Optionen eingrenzen

Nachdem Sie sich nun Gedanken über Ihre Anforderungen, Ihre Risikobereitschaft und die Zukunftssicherheit gemacht haben, verfügen Sie über genügend Informationen, um die sehr große Auswahl an Ingress-Controllern einzugrenzen. Eine Unterteilung in Kategorien kann Ihnen dabei helfen, diesen Schritt schnell zu bewältigen. In Teil 3 unserer Reihe betrachten wir drei verschiedene Kategorien von Ingress-Controllern und gehen auf ihre jeweiligen Vor- und Nachteile ein.

Über den Autor

Jenn GileLeiter Produktmarketing, NGINX

Weitere Blogbeiträge von Jenn Gile