[Redaktion– Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „Kubernetes-Datenverkehr mit F5 NGINX verwalten: Ein Praxisleitfaden“. Laden Sie es noch heute kostenlos herunter.]
Mit zunehmender Größe von Unternehmen werden die Entwicklungs- und Betriebsabläufe in Kubernetes komplexer. Im Allgemeinen ist es kostengünstiger – und kann auch sicherer sein –, wenn Teams Kubernetes-Cluster und -Ressourcen gemeinsam nutzen, anstatt jedem Team einen eigenen Cluster bereitzustellen. Wenn Teams diese Ressourcen jedoch nicht auf sichere Weise gemeinsam nutzen oder Hacker Schwachstellen in Ihren Konfigurationen ausnutzen, kann dies erhebliche Schäden an Ihren Bereitstellungen verursachen.
Mandantenfähige Konzepte und die Isolierung von Namespaces auf Netzwerk- und Ressourcenebene helfen Teams dabei, Kubernetes-Ressourcen sicher gemeinsam zu nutzen. Darüber hinaus können Sie das Ausmaß von Sicherheitsverletzungen erheblich reduzieren, indem Sie Anwendungen mandantenweise isolieren. Diese Methode erhöht die Ausfallsicherheit, da nur Teilbereiche von Anwendungen kompromittiert werden können, die bestimmten Teams gehören, während Systeme, die andere Funktionen bereitstellen, intakt bleiben.
NGINX Ingress Controller unterstützt mehrere Multi-Tenancy-Modelle, wobei wir hauptsächlich zwei Muster beobachten. Das Infrastrukturdienstanbieter-Muster umfasst in der Regel mehrere physisch isolierte Bereitstellungen von NGINX Ingress Controller, während beim Unternehmensmuster üblicherweise eine gemeinsam genutzte Bereitstellung von NGINX Ingress Controller mit Namespace-Isolierung zum Einsatz kommt. In diesem Abschnitt befassen wir uns eingehend mit dem Unternehmensmuster. Informationen zum Betrieb mehrerer NGINX Ingress Controller finden Sie in unserer Dokumentation.
Delegierung mit dem NGINX Ingress Controller
NGINX Ingress Controller unterstützt sowohl die standardmäßige Kubernetes-Ingress-Ressource als auch benutzerdefinierte NGINX-Ingress-Ressourcen, die eine ausgefeiltere Datenverkehrssteuerung und die Übertragung der Kontrolle über die Konfiguration an mehrere Teams ermöglichen. Die benutzerdefinierten Ressourcen sind VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer und Policy.
Mit NGINX Ingress Controller verwenden Clusteradministratoren VirtualServer-Ressourcen, um Ingress-Domänenregeln (Hostnamenregeln) bereitzustellen, die externen Datenverkehr an Backend-Anwendungen weiterleiten. Mithilfe von VirtualServerRoute-Ressourcen delegieren sie außerdem die Verwaltung bestimmter URLs an Anwendungsverantwortliche und DevOps-Teams.
Bei der Implementierung von Mandantenfähigkeit in Ihrem Kubernetes-Cluster können Sie zwischen zwei Modellen wählen: vollständiger Self-Service und eingeschränkter Self-Service.
Vollständige Self-Service-Funktionalität implementieren
Bei einem vollständigen Self-Service-Modell sind Administratoren nicht an den alltäglichen Änderungen der Konfiguration des NGINX Ingress Controllers beteiligt. Sie sind lediglich für die Bereitstellung des NGINX Ingress Controllers und des Kubernetes-Service verantwortlich, der die Bereitstellung nach außen zugänglich macht. Entwickler stellen anschließend Anwendungen innerhalb eines zugewiesenen Namespace bereit, ohne den Administrator einzubeziehen. Sie sind für die Verwaltung von TLS-Secrets, die Definition der Load-Balancing-Konfiguration für Domainnamen und die Bereitstellung ihrer Anwendungen durch das Erstellen von VirtualServer- oder standardmäßigen Ingress-Ressourcen verantwortlich.
Zur Veranschaulichung dieses Modells replizieren wir die Beispielanwendung „bookinfo“ (ursprünglich von Istio erstellt) mit den beiden Subdomains a.bookinfo.com und b.bookinfo.com, wie im folgenden Diagramm dargestellt. Nachdem der Administrator den NGINX Ingress Controller im Namespace nginx-ingress (grün hervorgehoben) installiert und bereitgestellt hat, erstellen die Teams DevA (rosa) und DevB (violett) ihre eigenen VirtualServer-Ressourcen und stellen Anwendungen isoliert in ihren jeweiligen Namespaces (A bzw. B) bereit.
Die Teams DevA und DevB legen Ingress-Regeln für ihre Domains fest, um externe Verbindungen an ihre Anwendungen weiterzuleiten.
Team DevA wendet das folgende VirtualServer-Ressourcenobjekt an, um Anwendungen für die Domain a.bookinfo.com im Namespace A bereitzustellen.
Codebeispiel wird geladen…
Analog dazu wendet das Team DevB die folgende VirtualServer-Ressource an, um Anwendungen für die Domain b.bookinfo.com im Namespace B bereitzustellen.
Codebeispiel wird geladen…
Eingeschränkte Self-Service-Funktionen implementieren
In einem eingeschränkten Self-Service-Modell konfigurieren Administratoren VirtualServer-Ressourcen so, dass in den Cluster eingehender Datenverkehr an den entsprechenden Namespace weitergeleitet wird. Die Konfiguration der Anwendungen in den Namespaces übertragen sie jedoch den zuständigen Entwicklungsteams. Jedes dieser Teams ist ausschließlich für die im Rahmen der VirtualServer-Ressource eingerichtete Subroute seiner Anwendung verantwortlich und verwendet VirtualServerRoute-Ressourcen, um Regeln für den Datenverkehr zu definieren und Anwendungs-Subroutes innerhalb seines Namespace bereitzustellen.
Wie im Diagramm dargestellt, installiert und implementiert der Clusteradministrator den NGINX Ingress Controller im Namespace „nginx-ingress“ (grün hervorgehoben) und definiert eine VirtualServer-Ressource, die pfadbasierte Regeln festlegt, die auf VirtualServerRoute-Ressourcendefinitionen verweisen.
Diese VirtualServer-Ressourcendefinition legt zwei pfadbasierte Regeln fest, die auf VirtualServerRoute-Ressourcendefinitionen für zwei Unterrouten verweisen: /productpage-A und /productpage-B.
Codebeispiel wird geladen…
Die für die Apps in den Namespaces zuständigen Entwicklerteams A und B definieren anschließend VirtualServerRoute-Ressourcen, um Anwendungsunterrouten innerhalb ihrer Namespaces bereitzustellen. Die Teams sind nach Namespace voneinander isoliert und dürfen nur die Anwendungsunterrouten bereitstellen, die durch die vom Administrator bereitgestellten VirtualServer-Ressourcen festgelegt sind:
- Das Team DevA (im Diagram rosa dargestellt) wendet die folgende VirtualServerRoute-Ressource an, um die vom Administrator festgelegte Regel für die Anwendungs-Unterroute
/productpage-Abereitzustellen.Codebeispiel wird geladen…
- Team DevB (violett) wendet die folgende VirtualServerRoute-Ressource an, um die vom Administrator festgelegte Subroutenregel für die Anwendung unter
/productpage-Bbereitzustellen.Codebeispiel wird geladen…
Weitere Informationen zu den Funktionen, die Sie in VirtualServer- und VirtualServerRoute-Ressourcen konfigurieren können, finden Sie in der Dokumentation zum NGINX Ingress Controller.
Hinweis: Sie können zusammenführbare Ingress-Typen verwenden, um das Routing über Namespace-Grenzen hinweg zu konfigurieren. In einem eingeschränkten Self-Service-Delegierungsmodell hat dieser Ansatz gegenüber VirtualServer- und VirtualServerRoute-Ressourcen jedoch drei Nachteile:
- Es ist weniger sicher.
- Je größer und komplexer Ihre Kubernetes-Bereitstellung wird, desto anfälliger wird sie für versehentliche Änderungen, da zusammenführbare Ingress-Typen Entwickler nicht daran hindern, innerhalb ihres Namespace Ingress-Regeln für Hostnamen festzulegen.
- Im Gegensatz zu VirtualServer- und VirtualServerRoute-Ressourcen ermöglichen zusammenführbare Ingress-Typen es der primären („Master“-)Ingress-Ressource nicht, die Pfade von untergeordneten („Minion“-)Ingress-Ressourcen zu steuern.
Nutzung von Kubernetes-RBAC in einem eingeschränkten Self-Service-Modell
Mit der rollenbasierten Zugriffssteuerung (RBAC) von Kubernetes können Sie den Zugriff eines Benutzers auf Namespaces und NGINX-Ingress-Ressourcen anhand der ihm zugewiesenen Rollen steuern.
Beispielsweise kann in einem eingeschränkten Self-Service-Modell nur Administratoren mit besonderen Berechtigungen ein sicherer Zugriff auf VirtualServer-Ressourcen gewährt werden. Da diese Ressourcen den Zugangspunkt zum Kubernetes-Cluster definieren, kann eine missbräuchliche Verwendung zu systemweiten Ausfällen führen.
Entwickler verwenden VirtualServerRoute-Ressourcen, um Ingress-Regeln für die ihnen zugeordneten Anwendungsrouten zu konfigurieren. Daher legen Administratoren RBAC-Richtlinien fest, die es Entwicklern erlauben, ausschließlich diese Ressourcen zu erstellen. Bei Bedarf können sie diese Berechtigung sogar auf bestimmte Namespaces beschränken, um den Zugriff der Entwickler noch stärker zu regulieren.
In einem vollständigen Self-Service-Modell kann Entwicklern bedenkenlos Zugriff auf VirtualServer-Ressourcen gewährt werden. Der Administrator kann diese Berechtigung jedoch auch hier auf bestimmte Namespaces beschränken.
Weitere Informationen zur RBAC-Autorisierung finden Sie in der Kubernetes-Dokumentation.
Richtlinien hinzufügen
NGINX-Policy-Ressourcen sind ein weiteres Werkzeug, mit dem verteilte Teams Kubernetes in mandantenfähigen Bereitstellungen konfigurieren können. Policy-Ressourcen ermöglichen Funktionen wie die Authentifizierung mittels OAuth und OpenID Connect (OIDC), Ratenbegrenzung und Web Application Firewall (WAF). Damit Policy-Ressourcen in der Ingress-Konfiguration wirksam werden, wird in VirtualServer- und VirtualServerRoute-Ressourcen auf sie verwiesen.
Beispielsweise kann ein Team, das für die Identitätsverwaltung in einem Cluster zuständig ist, JSON Web Token (JWT)- oder OIDC-Richtlinien wie die folgende definieren, die Okta als OIDC-Identitätsanbieter (IdP) verwendet.
Codebeispiel wird geladen…
NetOps- und DevOps-Teams können VirtualServer- oder VirtualServerRoute-Ressourcen verwenden, um auf diese Richtlinien zu verweisen, wie in diesem Beispiel gezeigt.
Codebeispiel wird geladen…
Gemeinsam ermöglichen die NGINX-Ressourcen Policy, VirtualServer und VirtualServerRoute verteilte Konfigurationsarchitekturen, in denen Administratoren die Konfiguration problemlos an andere Teams delegieren können. Teams können Module über Namespaces hinweg zusammenstellen und den NGINX Ingress Controller sicher, skalierbar und einfach verwaltbar für anspruchsvolle Anwendungsfälle konfigurieren.
Weitere Informationen zu Policy-Ressourcen finden Sie in der Dokumentation zum NGINX Ingress Controller.
Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „Kubernetes-Datenverkehr mit NGINX verwalten: Ein Praxisleitfaden“. Laden Sie es noch heute kostenlos herunter.
Testen Sie den auf NGINX Plus basierenden NGINX Ingress Controller selbst im Rahmen einer 30-tägigen kostenlosen Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.