Aktivieren von Multi-Tenancy und Namespace-Isolation in Kubernetes mit NGINX

[ Herausgeber – Dieser Beitrag ist ein Auszug aus unserem umfassenden eBook „Verwaltung des Kubernetes-Verkehrs mit F5 NGINX“: Ein praktischer Leitfaden . Laden Sie es noch heute kostenlos herunter .]

Wenn Unternehmen wachsen, werden Entwicklungs- und Betriebsabläufe in Kubernetes komplexer. Es ist oft kosteneffizienter – und sicherer –, wenn Teams Kubernetes-Cluster und Ressourcen gemeinsam nutzen, statt jeder sein eigenes Cluster zu betreiben. Wenn Teams Ressourcen nicht sicher teilen oder Hacker Ihre Konfigurationen ausnutzen, können Ihre Bereitstellungen jedoch schwerwiegenden Schaden nehmen.

Multi-Tenancy-Praktiken und Namensraum-Isolierung auf Netzwerk- und Ressourcenebene ermöglichen es Ihnen, Kubernetes-Ressourcen sicher im Team zu teilen. Sie können Sicherheitsvorfälle auch deutlich begrenzen, indem Sie Anwendungen mandantenweise isolieren. So erhöhen Sie die Resilienz, weil nur Anwendungsbereiche bestimmter Teams betroffen sind, während Systeme mit anderen Funktionen unverändert bleiben.

NGINX Ingress Controller unterstützt mehrere Multi-Tenancy-Modelle, wir erkennen jedoch zwei primäre Muster. Das Muster des Infrastrukturdienstanbieters umfasst normalerweise mehrere NGINX Ingress Controller-Bereitstellungen mit physischer Isolierung, während das Unternehmensmuster normalerweise eine gemeinsam genutzte NGINX Ingress Controller-Bereitstellung mit Namespace-Isolierung verwendet. In diesem Abschnitt untersuchen wir das Unternehmensmuster im Detail. Informationen zum Ausführen mehrerer NGINX Ingress Controller finden Sie in unserer Dokumentation .

Delegation mit NGINX Ingress Controller

Der NGINX Ingress Controller unterstützt sowohl die standardmäßige Kubernetes Ingress-Ressource als auch benutzerdefinierte NGINX Ingress-Ressourcen, die Ihnen eine feinere Steuerung des Datenverkehrs ermöglichen und die Konfigurationsverantwortung auf mehrere Teams verteilen. Die benutzerdefinierten Ressourcen umfassen VirtualServer, VirtualServerRoute, GlobalConfiguration, TransportServer und Policy.

Mit dem NGINX Ingress Controller verwenden Cluster-Administratoren VirtualServer-Ressourcen, um Ingress-Domänenregeln (Hostnamen) zu erstellen, die externen Datenverkehr an Backend-Anwendungen weiterleiten. Mit VirtualServerRoute-Ressourcen geben sie die Verwaltung bestimmter URLs an Anwendungsbesitzer und DevOps-Teams weiter.

Beim Implementieren von Multi-Tenancy in Ihrem Kubernetes-Cluster können Sie zwischen zwei Modellen wählen: vollständiger Self-Service und eingeschränkter Self-Service .

Implementierung eines vollständigen Self-Service

In einem vollständigen Self-Service-Modell greifen Administratoren nicht in die täglichen Änderungen der NGINX Ingress Controller-Konfiguration ein. Sie übernehmen lediglich die Bereitstellung des NGINX Ingress Controllers und des Kubernetes Service, der das Deployment extern zugänglich macht. Entwickler bringen Anwendungen in einem zugewiesenen Namespace eigenständig auf den Weg, ohne den Administrator einzubeziehen. Dabei verwalten Entwickler TLS-Geheimnisse, legen die Lastausgleichskonfiguration für Domainnamen fest und machen ihre Anwendungen sichtbar, indem sie VirtualServer- oder standardmäßige Ingress-Ressourcen erstellen.

Um dieses Modell zu zeigen, replizieren wir die Beispielanwendung bookinfo (ursprünglich von Istio erstellt) mit zwei Subdomains, a.bookinfo.com und b.bookinfo.com, wie im folgenden Diagramm dargestellt. Nachdem Sie als Administrator den NGINX Ingress Controller im nginx-ingress-Namespace (grün hervorgehoben) installiert und bereitgestellt haben, erstellen die Teams DevA (pink) und DevB (lila) ihre jeweiligen VirtualServer-Ressourcen und setzen Anwendungen isoliert in ihren eigenen Namespaces (A und B) um.

Die Teams DevA und DevB legen Ingress-Regeln für ihre Domänen fest, um externe Verbindungen zu ihren Anwendungen weiterzuleiten.

Team DevA setzt das folgende VirtualServer-Ressourcenobjekt ein, um Anwendungen für die Domain a.bookinfo.com im Namespace A bereitzustellen.

Ebenso wendet das Team DevB die folgende VirtualServer-Ressource an, um Anwendungen für die Domain b.bookinfo.com im Namespace B bereitzustellen.

Implementierung eines eingeschränkten Self-Service

In einem eingeschränkten Self-Service-Modell konfigurieren Administratoren VirtualServer-Ressourcen, um den Datenverkehr, der in den Cluster gelangt, an den passenden Namespace weiterzuleiten, überlassen jedoch die Konfiguration der Anwendungen in den Namespaces den verantwortlichen Entwicklungsteams. Jedes Team ist ausschließlich für seinen in der VirtualServer-Ressource definierten Anwendungs-Unterpfad zuständig und nutzt VirtualServerRoute-Ressourcen, um Verkehrsregeln festzulegen und Anwendungs-Unterpfade innerhalb seines Namespaces zugänglich zu machen.

Wie im Diagramm gezeigt, installiert und setzt der Clusteradministrator den NGINX Ingress Controller im nginx-ingress-Namespace (grün markiert) ein und erstellt eine VirtualServer-Ressource, die pfadbasierte Regeln definiert, welche sich auf VirtualServerRoute-Ressourcendefinitionen beziehen.

Diese VirtualServer-Ressourcendefinition legt zwei pfadbasierte Regeln fest, die auf VirtualServerRoute-Ressourcendefinitionen für die beiden Unterrouten /productpage-A und /productpage-B verweisen.

Die Entwicklerteams für die Apps in den Namespaces A und B definieren anschließend VirtualServerRoute-Ressourcen, um Anwendungssubrouten innerhalb ihrer Namespaces freizugeben. Die Teams sind durch Namespaces voneinander getrennt und dürfen nur Anwendungssubrouten bereitstellen, die durch vom Administrator konfigurierte VirtualServer-Ressourcen festgelegt sind:

• Team DevA (rosa im Diagramm) setzt die folgende VirtualServerRoute-Ressource ein, um die vom Administrator definierte Anwendungs-Subroute-Regel für /productpage-A bereitzustellen.

• Team DevB (lila) setzt die folgende VirtualServerRoute-Ressource ein, um die vom Administrator für /productpage-B festgelegte Anwendungs-Subroute zugänglich zu machen.

Weitere Informationen zu Funktionen, die Sie in VirtualServer- und VirtualServerRoute-Ressourcen konfigurieren können, entnehmen Sie der NGINX Ingress Controller-Dokumentation.

Hinweis: Sie können zusammenführbare Ingress-Typen verwenden, um Anforderungsweiterleitung über Namespaces hinweg einzurichten. Im eingeschränkten Self-Service-Delegierungsmodell bringt dieser Ansatz jedoch drei Nachteile gegenüber VirtualServer- und VirtualServerRoute-Ressourcen mit sich:

1. Es ist weniger sicher.
2. 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, Ingress-Regeln für Hostnamen innerhalb ihres Namespaces festzulegen.
3. Im Gegensatz zu VirtualServer- und VirtualServerRoute-Ressourcen ermöglicht der zusammenführbare Ingress-Typ der primären („Master“) Ingress-Ressource nicht, die Pfade der „Minion“-Ingress-Ressourcen zu steuern.

Nutzung von Kubernetes RBAC in einem eingeschränkten Self-Service-Modell

Mit Kubernetes role‑based access control (RBAC) steuern Sie den Zugriff von Benutzern auf Namespaces und NGINX Ingress-Ressourcen anhand ihrer zugewiesenen Rollen.

In einem eingeschränkten Self-Service-Modell dürfen nur Administratoren mit speziellen Rechten sicher auf VirtualServer-Ressourcen zugreifen – weil diese Ressourcen den Einstiegspunkt zum Kubernetes-Cluster darstellen, kann Missbrauch zu Ausfällen im gesamten System führen.

Entwickler nutzen VirtualServerRoute-Ressourcen, um Ingress-Regeln für die von ihnen verwalteten Anwendungsrouten zu konfigurieren. Administratoren legen RBAC-Richtlinien fest, die Entwickler darauf beschränken, nur diese Ressourcen anzulegen. Sie können diese Berechtigung sogar auf bestimmte Namespaces begrenzen, wenn Sie den Entwicklerzugang noch gezielter steuern möchten.

In einem vollständigen Self-Service-Modell können Sie Entwicklern sicher Zugriff auf VirtualServer-Ressourcen gewähren. Gleichzeitig kann der Administrator diese Berechtigung auf bestimmte Namespaces einschränken.

Weitere Informationen zur RBAC-Autorisierung finden Sie in der Kubernetes-Dokumentation .

Richtlinien hinzufügen

NGINX-Richtlinienressourcen sind ein weiteres Werkzeug, mit dem Sie verteilte Teams bei der Konfiguration von Kubernetes in Multi-Tenancy-Bereitstellungen unterstützen. Sie ermöglichen Funktionen wie die Authentifizierung über OAuth und OpenID Connect (OIDC), Ratenbegrenzung und eine Web Application Firewall (WAF). Wir verweisen auf Richtlinienressourcen in VirtualServer- und VirtualServerRoute-Ressourcen, damit sie in der Ingress-Konfiguration wirksam werden.

Beispielsweise kann ein Team, das für das Identitätsmanagement in einem Cluster verantwortlich ist, JSON Web Token (JWT) oder OIDC-Richtlinien wie die folgenden definieren, die Okta als OIDC-Identitätsanbieter (IdP) verwenden.

NetOps- und DevOps-Teams können VirtualServer- oder VirtualServerRoute-Ressourcen nutzen, um auf Richtlinien zuzugreifen, wie in diesem Beispiel gezeigt.

NGINX Policy, VirtualServer und VirtualServerRoute ermöglichen gemeinsam verteilte Konfigurationsarchitekturen, mit denen Sie die Systemkonfiguration einfach an andere Teams delegieren können. Sie können Module aus verschiedenen Namespaces kombinieren und den NGINX Ingress Controller mit anspruchsvollen Use Cases sicher, skalierbar und einfach verwalten.

Weitere Informationen zu Richtlinienressourcen finden Sie in der Dokumentation des NGINX Ingress Controllers.

Dieser Beitrag ist ein Auszug aus unserem umfassenden E-Book „ Verwaltung des Kubernetes-Verkehrs mit NGINX“: Ein praktischer Leitfaden . Laden Sie es noch heute kostenlos herunter .

Testen Sie den auf NGINX Plus basierenden NGINX Ingress Controller noch heute selbst in einer 30-tägigen kostenlosen Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .