Sichereres Konfigurationsmanagement mit NGINX Controller

Bei Gesprächen mit unseren Kunden im letzten Jahr sind uns einige wiederkehrende Themen aufgefallen, die sie dazu motivieren, Orchestrierungsprodukte wie NGINX Controller zu evaluieren:

• Komplexität – Das Verwalten, Warten, Validieren und Anwenden großer Mengen einzelner Konfigurationsobjekte aus verschiedenen Quellen ist nicht einfach.
• Fragilität – Eine Skalierung kann schnell erfolgen, häufig als Reaktion auf ein Ereignis. Manchmal geschieht es aus strategischer Sicht, aber wie so oft in jeder Betriebsabteilung geschieht es ungeplant und organisch.
• Sicherheit – Die Vermeidung von Fehlern und das Erkennen von Problemen vor der Bereitstellung in der Produktion sind Eckpfeiler der agilen Methodik. Sie tragen auch dazu bei, Komplexität und Fragilität zu verringern.

Dies sind keine Bedenken, mit denen Kunden im Allgemeinen konfrontiert werden, wenn sie eine Anwendung zum ersten Mal bereitstellen. Sie treten vielmehr im Laufe der Zeit auf, wenn die Anwendung erfolgreich wird und skaliert werden muss. Wir sind zu dem Schluss gekommen, dass die Skalierung – oder genauer gesagt die ungeplante Skalierung – die häufigste Ursache für die oben aufgeführten Probleme ist.

Glücklicherweise berücksichtigt das Konfigurationsobjektmodell des NGINX-Controllers alle drei Probleme:

• Es reduziert die Bereitstellungskomplexität , indem alle Konfigurationskomponenten, die sich auf einen bestimmten Satz von NGINX Plus- Instanzen auswirken könnten, an einem einzigen Ort gesammelt werden.
• Es reduziert die Fragilität , indem es Teams ermöglicht, Konfigurationen zu validieren und zu testen, bevor sie in die Produktion gehen. Dadurch werden schnelle Fehler vermieden und der fließende Produktionsbenutzerverkehr sichergestellt.
• Es fördert die Sicherheit , da es sehr flexibel ist. Anstatt Sie zu zwingen, Ihre Prozesse an das Modell anzupassen, ist das Konfigurationsobjektmodell so konzipiert, dass es sich an Ihren Geschäftsabläufen und der Aufgabenteilung orientiert – Sie können verschiedenen Geschäftseinheiten bei Bedarf die entsprechenden Eigentumsrechte an Konfigurationselementen übertragen.

Controller-Konfigurationsobjekte

Lassen Sie uns etwas tiefer in einige wichtige Konfigurationsobjekte eintauchen, um Ihnen eine bessere Vorstellung davon zu geben, wie das Controller-Modell funktioniert.

Umgebungen

In den meisten Organisationen durchläuft Software vor der Veröffentlichung mehrere Phasen: Entwicklung, Benutzerakzeptanz, Vorproduktion, Produktion und andere Phasen der Qualitätsprüfung. Diese Phasen entsprechen dem NGINX-Controllerobjekt, das als Umgebung bezeichnet wird.

Eine Umgebung ist eine Isolationszone für Konfigurationselemente innerhalb des Controllers. Dies ist normalerweise die Ebene, auf der die rollenbasierte Zugriffskontrolle (RBAC) definiert wird. Umgebungen können identische Konfigurationsartefakte durch die verschiedenen Phasen tragen und dabei minimale Änderungen an Dingen wie Zielservern, Rechenzentren und anderen Infrastrukturobjekten vornehmen, die sich zwischen Umgebungen häufig unterscheiden.

Gateways

Ein Gateway ist ein Konfigurationsobjekt innerhalb einer Umgebung, das häufig als oberste Ebene zum Definieren der Bereitstellung von Anwendungen für Kunden verwendet wird (Einstellungen wie Hostname, Protokoll und TLS/SSL-Verhalten). Solche Einstellungen können jedoch auch auf einer niedrigeren Ebene vorgenommen werden. In der Praxis sind es meist die Netzwerkbetriebsteams (NetOps), die für die Verwaltung von Edge-Netzwerkgeräten oder der DMZ zuständig sind, die Gateway-Objekte besitzen. Gateways nutzen außerdem das Konzept der „Platzierung“. Dabei handelt es sich um die Art und Weise, wie Sie den Controller und die NGINX Plus-Instanzen verknüpfen, die die Konfigurationen empfangen und die eigentliche Arbeit ausführen.

Apps

Die nächste Ebene darunter ist das App-Konfigurationsobjekt, wo Sie mit der Modellierung von Anwendungen und der Gruppierung von verkehrsgestaltenden Verhaltensweisen beginnen. Sie können so viele oder so wenige Apps verwenden, wie Sie benötigen, um die Anforderungen Ihrer Organisation zu erfüllen. Die einzige Voraussetzung ist, dass eine App innerhalb einer Umgebung eindeutig sein muss.

Komponenten

Innerhalb einer App beschreiben Komponenten das gewünschte Traffic-Shaping-Verhalten für die App. Im einfachsten Fall wird der gesamte Datenverkehr für einen bestimmten Pfadnamen an dieselbe Servergruppe gesendet. Komponenten steuern aber auch erweiterte Gestaltungsmöglichkeiten wie Header-Manipulation, URL-Umschreiben, Backend-Lastausgleichsverhalten, Cookie-Verarbeitung und andere Einstellungen. Auf dieser Ebene können auch Hostname und TLS/SSL-Verhalten definiert werden.

Alles zusammenfügen

Hier ist eine visuelle Darstellung der Beziehung zwischen den Konfigurationsobjekten:

Beachten Sie, dass nur zwei Gruppen mit dem Controller interagieren – in diesem Fall zwei Entwicklungsteams, Referral und Transfers . Tatsächlich wissen wir, dass die Zahl der an der Anwendungsbereitstellung und -sicherheit beteiligten Personen wahrscheinlich viel größer ist und die Bereiche Netzwerk und Sicherheit (Platform Ops), DevOps, App-Entwicklung und mehr abdeckt. Die Teams mit dem größten Wissen können Richtlinien festlegen und Self-Service-Workflows erstellen, die sich an Best Practices orientieren und Leitlinien für die Teams bereitstellen, die mit Apps, Komponenten und Gateways in der „Dev“-Umgebung arbeiten, die sich über die Rechenzentrumsstandorte Ost und West des Unternehmens erstreckt.

Betrachten wir dies aus einer etwas anderen Perspektive, eher aus der Perspektive der einzelnen Geschäftsbereiche (LOB) . LOB-Eigentümer treffen zunehmend Anwendungsentscheidungen für moderne Apps.

Das folgende Diagramm veranschaulicht ein realistischeres Szenario mit einem viel größeren Benutzerpool, der verschiedene LOB-Teams und Shawn umfasst, die Person, die alle Zertifikatserneuerungen verwaltet.

Jetzt haben wir mehr einzelne Akteure und Pipelines, die den resultierenden Datenfluss beeinflussen.

Während jede einzelne Pipeline die verschiedenen Objektänderungen von der Quellcodeverwaltung (wie GitHub) zum Controller durchläuft, werden die Konfigurationsobjekte auf der Controllerseite validiert und dann mit allen zugehörigen Objekten kombiniert, bevor die Änderungen an die NGINX Plus-Instanzen weitergegeben werden.

Auf diese Weise kann Controller dazu beitragen, das Konfigurationsmanagement sicherer zu machen – indem er gewährleistet, dass die neuesten Änderungen mit vorherigen Einstellungen und mit Einstellungen anderer Anwendungs- und LOB-Eigentümer kompatibel sind.

Wir sind uns bewusst, dass in der Praxis alle Konfigurationen, die auf eine einzelne NGINX Plus-Instanz angewendet werden, möglich sein müssen – die Einstellungen dürfen jedoch nicht im Konflikt stehen, sich überschneiden oder miteinander kollidieren. Außerdem ist es wichtig, Konflikte im Vorfeld zu erkennen und die Leute zu informieren, die für die Konfiguration der einzelnen Komponenten zuständig sind.

Wenn im obigen Beispiel die Empfehlungskomponente versucht, dasselbe Regex-Muster zu verwenden, das die Übertragungskomponente bereits implementiert hat, wird ein Pfadkonflikt sofort erkannt und das Empfehlungsteam kann lange vor dem Versuch, diese Konfiguration in der Produktion einzusetzen, benachrichtigt werden. So werden die vielen Kopfschmerzen vermieden, die mit einer Fehlkonfiguration einhergehen.

In Bezug auf Zertifikate kann Shawn – über die RBAC-Funktionalität des Controllers – Zertifikatsänderungen sofort implementieren. Die Betreuer des Gateways und der Komponenten müssen lediglich auf die richtigen Zertifikate verweisen und Shawn kann diese während ihres eigenen Lebenszyklus zuverlässig verwalten. Wenn Shawn ein Zertifikat im Controller aktualisiert, wird es an die richtigen Instanzen weitergeleitet, ohne dass die mit dem Ablauf eines Zertifikats verbundene Panik auftritt.

Da der NGINX Controller nun über alle Ihre Konfigurationsobjekte und eine Platzierungszuordnung zu einer oder mehreren NGINX Plus-Instanzen verfügt, kann er die letzten Schritte ausführen: das Anwenden der Konfiguration.

Sicherheit in der Praxis

Letztendlich besteht das Ziel des Konfigurationsmanagements mit Controller darin, die richtige Konfiguration auf den richtigen NGINX Plus-Instanzen am richtigen Ort anzuwenden. Indem sichergestellt wird, dass Apps, Komponenten, Gateways und alle zugehörigen Zertifikate und Instanzen richtig konfiguriert sind, werden sicherere und skalierbarere Bereitstellungen erreicht.

Diese abschließende Überprüfung ist der letzte Teil des Konfigurationsverwaltungsprozesses, den Controller einfacher und sicherer macht. Die gesamte Konfiguration wird überprüft, da sie auf eine NGINX Plus-Instanz angewendet wird, bei der es Änderungen an zugehörigen Objekten gab – wie etwa die Sitzungspersistenz in einer Web-Workload-Gruppe für NGINX Plus, die als Proxy bereitgestellt wurde – um sicherzustellen, dass die Instanz mit der gewünschten Konfiguration kompatibel ist. Wenn diese Bedingung erfüllt ist, wird die Konfiguration angewendet. Und als letztes Sicherheitsmerkmal: Wenn beim Anwenden der Konfiguration etwas fehlschlägt, greift der Controller auf eine vorherige Konfiguration zurück.

Controller stellt nicht nur sicher, dass die Konfigurationen den Anforderungen entsprechen, sondern kann auch erweiterte NGINX-Funktionen wie Session Draining nutzen, wenn eine neue Konfiguration angewendet wird. So wird garantiert, dass die Verfügbarkeit und Leistung der Sites auch bei Änderungen erhalten bleibt.

Für Betriebsteams tragen die oben beschriebenen Konzepte und Workflow-Designs zur Sicherheit bei, die NGINX Controller im Bereich Konfigurationsmanagement bietet. Diese Sicherheitsvorkehrungen tragen dazu bei, Arbeitsabläufe und die verschiedenen Teams, die mit modernen Apps arbeiten, aufeinander abzustimmen und gleichzeitig die Anforderungen des Unternehmens zu erfüllen.

Um NGINX Controller auszuprobieren, starten Sie noch heute Ihre kostenlose 30-Tage-Testversion oder kontaktieren Sie uns, um Ihre Anwendungsfälle zu besprechen .