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 .]

Mit der Skalierung von Organisationen werden die Entwicklungs- und Betriebsabläufe in Kubernetes komplexer. Es ist im Allgemeinen kostengünstiger – und kann sicherer –, wenn Teams Kubernetes-Cluster und -Ressourcen gemeinsam nutzen, anstatt dass jedes Team seinen eigenen Cluster erhält. Wenn die Teams diese Ressourcen jedoch nicht auf sichere Weise gemeinsam nutzen oder Hacker Ihre Konfigurationen ausnutzen, kann dies zu schwerwiegenden Schäden an Ihren Bereitstellungen führen.

Mandantenfähigkeitsverfahren und Namespace-Isolierung auf Netzwerk- und Ressourcenebene helfen Teams dabei, Kubernetes-Ressourcen sicher gemeinsam zu nutzen. Sie können das Ausmaß von Sicherheitsverletzungen außerdem erheblich reduzieren, indem Sie Anwendungen auf Mandantenbasis isolieren. Diese Methode trägt zur Verbesserung der Ausfallsicherheit bei, da nur Teilbereiche von Anwendungen, die bestimmten Teams gehören, kompromittiert werden können, während Systeme mit anderen Funktionen intakt 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

NGINX Ingress Controller unterstützt sowohl die standardmäßige Kubernetes-Ingress-Ressource als auch benutzerdefinierte NGINX-Ingress-Ressourcen, die sowohl ein anspruchsvolleres Verkehrsmanagement als auch die Delegierung 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 (Hostname) bereitzustellen, die externen Datenverkehr an Back-End-Anwendungen weiterleiten, und VirtualServerRoute-Ressourcen, um die Verwaltung bestimmter URLs an Anwendungsbesitzer und DevOps-Teams zu delegieren.

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 sind Administratoren nicht an täglichen Änderungen an der NGINX Ingress Controller-Konfiguration beteiligt. Sie sind nur für die Bereitstellung des NGINX Ingress Controllers und des Kubernetes -Dienstes verantwortlich, der die Bereitstellung extern verfügbar macht. Entwickler stellen dann Anwendungen innerhalb eines zugewiesenen Namespace bereit, ohne den Administrator einzubeziehen. Entwickler sind für die Verwaltung von TLS-Geheimnissen, die Definition der Lastausgleichskonfiguration für Domänennamen und die Bereitstellung ihrer Anwendungen durch die Erstellung von VirtualServer- oder Standard- Ingress- Ressourcen verantwortlich.

Um dieses Modell zu veranschaulichen, replizieren wir die Beispielanwendung „bookinfo“ (ursprünglich von Istio erstellt) mit zwei Subdomänen, a.bookinfo.com und b.bookinfo.com , wie im folgenden Diagramm dargestellt. Sobald der Administrator den NGINX Ingress Controller im nginx-ingress -Namespace (grün hervorgehoben) installiert und bereitgestellt hat, erstellen die Teams DevA (pink) und DevB (lila) ihre eigenen VirtualServer-Ressourcen und stellen Anwendungen isoliert innerhalb ihrer Namespaces ( A bzw. B ) bereit.

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

Team DevA wendet das folgende VirtualServer-Ressourcenobjekt an, um Anwendungen für die Domäne a.bookinfo.com im A- Namespace verfügbar zu machen.

In ähnlicher Weise verwendet das Team DevB die folgende VirtualServer-Ressource, um Anwendungen für die Domäne b.bookinfo.com im B -Namespace verfügbar zu machen.

Implementierung eines eingeschränkten Self-Service

In einem eingeschränkten Self-Service-Modell konfigurieren Administratoren VirtualServer-Ressourcen so, dass der in den Cluster eingehende Datenverkehr an den entsprechenden Namespace weitergeleitet wird, delegieren die Konfiguration der Anwendungen in den Namespaces jedoch an die zuständigen Entwicklungsteams. Jedes dieser Teams ist nur für seine Anwendungsunterroute verantwortlich, wie sie in der VirtualServer-Ressource instanziiert ist, und verwendet VirtualServerRoute-Ressourcen, um Verkehrsregeln zu definieren und Anwendungsunterrouten innerhalb seines Namespace verfügbar zu machen.

Wie im Diagramm dargestellt, installiert und stellt der Clusteradministrator den NGINX Ingress Controller im nginx-ingress -Namespace (grün hervorgehoben) bereit und definiert eine VirtualServer-Ressource, die pfadbasierte Regeln festlegt, die sich auf VirtualServerRoute-Ressourcendefinitionen beziehen.

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

Die für die Apps in den Namespaces A und B verantwortlichen Entwicklerteams definieren dann VirtualServerRoute-Ressourcen, um Anwendungsunterrouten innerhalb ihrer Namespaces verfügbar zu machen. Die Teams sind nach Namespace isoliert und dürfen nur Anwendungsunterrouten bereitstellen, die durch vom Administrator bereitgestellte VirtualServer-Ressourcen festgelegt wurden:

• Team DevA (rosa im Diagramm) wendet die folgende VirtualServerRoute-Ressource an, um die vom Administrator für /productpage-A festgelegte Anwendungs-Subroute-Regel verfügbar zu machen.

• Team DevB (lila) wendet die folgende VirtualServerRoute-Ressource an, um die vom Administrator für /productpage-B festgelegte Anwendungs-Subroute-Regel verfügbar zu machen.

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

Notiz: Sie können zusammenführbare Ingress-Typen verwenden, um das Routing über Namespaces hinweg zu konfigurieren. In einem eingeschränkten Self-Service-Delegierungsmodell hat dieser Ansatz im Vergleich zu VirtualServer- und VirtualServerRoute-Ressourcen jedoch drei Nachteile:

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öglichen zusammenführbare Ingress-Typen der primären („Master“) Ingress-Ressource nicht, die Pfade von „Minion“-Ingress-Ressourcen zu steuern.

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

Sie können die rollenbasierte Zugriffskontrolle (RBAC) von Kubernetes verwenden, um den Zugriff eines Benutzers auf Namespaces und NGINX-Ingress-Ressourcen basierend auf den dem Benutzer zugewiesenen Rollen zu regeln.

Beispielsweise kann in einem eingeschränkten Self-Service-Modell nur Administratoren mit Sonderberechtigungen der sichere Zugriff auf VirtualServer-Ressourcen gestattet werden. Da diese Ressourcen den Einstiegspunkt zum Kubernetes-Cluster definieren, kann ein Missbrauch zu systemweiten Ausfällen führen.

Entwickler verwenden VirtualServerRoute-Ressourcen, um Ingress-Regeln für die Anwendungsrouten zu konfigurieren, deren Eigentümer sie sind. Administratoren legen daher RBAC-Richtlinien fest, die es Entwicklern ermöglichen, nur diese Ressourcen zu erstellen. Sie können diese Berechtigung sogar auf bestimmte Namespaces beschränken, wenn sie den Entwicklerzugriff noch stärker regulieren müssen.

In einem vollständigen Self-Service-Modell kann Entwicklern sicher 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-Richtlinienressourcen sind ein weiteres Tool, mit dem verteilte Teams Kubernetes in Multi-Tenancy-Bereitstellungen konfigurieren können. Richtlinienressourcen ermöglichen Funktionen wie Authentifizierung mit OAuth und OpenID Connect (OIDC), Ratenbegrenzung und Web Application Firewall (WAF). Auf Richtlinienressourcen wird in VirtualServer- und VirtualServerRoute-Ressourcen verwiesen, um in der Ingress-Konfiguration wirksam zu 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 verwenden, um auf diese Richtlinien zu verweisen, wie in diesem Beispiel.

Zusammen ermöglichen die Ressourcen NGINX 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 mit anspruchsvollen Anwendungsfällen auf sichere, skalierbare und verwaltebare Weise konfigurieren.

Weitere Informationen zu Richtlinienressourcen finden Sie in der NGINX Ingress Controller-Dokumentation .

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 .