Als DevOps-Ingenieur, der mehrere Kubernetes-Anwendungen unterstützt (die von verschiedenen Teams entwickelt wurden), ist es wichtig, einen Ingress-Controller zu haben, der einfach für das Layer-7-Anwendungsrouting und die Durchsetzung von HTTP-Standards in einem vielfältigen Ökosystem konfiguriert werden kann. Kemp LoadMaster nimmt uns das Rätselraten über den Anwendungsingress und die Sicherheitsbedenken für veröffentlichte Kubernetes-Dienste ab. Die Integration von Kemp in Kubernetes mit der Ingress-Controller-API hat unsere Arbeitsabläufe und die Anwendungserfahrung der Endbenutzer erheblich verbessert [AX].
Heute werden wir zeigen, wie unser Team die Load-Balancing-Lösung von Kemp LoadMaster nutzt, um Dienste für externe Kunden und interne Organisationsteams bereitzustellen. Ich werde mich auf die Content Rules Engine konzentrieren (die das Kernelement in diesem Setup ist), aber es ist wichtig zu beachten, dass die ganzheitliche Lösung, die wir verwenden, viele andere Funktionen innerhalb von LoadMaster umfasst (siehe Anhang für diese Themen).
Das Team, dem ich angehöre, veröffentlicht seit 2017 Anwendungen in der Microsoft Azure Kubernetes-Umgebung, und wir haben mehrere Ingress-Controller/Modelle durchgespielt. Wir haben unser eigenes Futter gegessen und verwenden dies intern seit Anfang 2019. Dies hat sich als sehr erfolgreich erwiesen und uns ermöglicht, die Herausforderungen, denen wir gegenüberstehen, direkt anzugehen.
Die Verwendung eines virtuellen Dienstes ist eine gängige und bewährte Methode, um hohe Verfügbarkeit zu gewährleisten und die Verteilung des Datenverkehrs für Anwendungen zu steuern. Ein virtueller Dienst dient als Abstraktion von einem oder mehreren realen Servern. Um dies zu verdeutlichen, stellen wir einen virtuellen Kemp LoadMaster in der Cloud bereit und konfigurieren einen virtuellen Dienst. Dieser virtuelle Dienst leitet dann den Datenverkehr an unsere Kubernetes-Knoten auf den konfigurierten exponierten Ports (reale Server-Sockets im LoadMaster-Jargon) für veröffentlichte Dienste weiter.
Auf Kemp LoadMaster wird das Konzept der virtuellen Dienste noch einen Schritt weitergeführt, indem ein virtueller Dienst subvirtuelle Dienste haben kann. Dies ist besonders nützlich in Szenarien, in denen Sie mehrere Services/Sites/Applikationen/Micro-Services unter einer einzigen IP-Adresse veröffentlichen wollen und/oder um die Service-Konfiguration von Teilkomponenten eines Services zu differenzieren (z. B. Mikrodienst-Architektur).
Kemp LoadMaster vereinfacht die Steuerung und Änderung des Datenverkehrs durch die Verwendung von Inhaltsregeln, die auf der Syntax regulärer Ausdrücke basieren. Die Content-Rules-Engine kann Header hinzufügen/entfernen/bearbeiten, URLs umschreiben, HTTP-Payload-Bodies umschreiben und Content-Matching auf Basis von Headern und/oder URIs durchführen. Regeln für den Inhaltsabgleich können auf der Grundlage von Merkmalen der Anfragen auf subvirtuelle Dienste und "echte Server" angewendet werden. Dieser Blog kratzt nur an der Oberfläche des Funktionsumfangs. Weitere Informationen über die Content Rules Engine finden Sie in der Dokumentation zu den Hauptfunktionen.
In unserer Umgebung verwenden wir in erster Linie diesen Inhaltsabgleich mit dem HTTP-Host-Header der Sites, wobei wir die veröffentlichten Dienste/Mikrodienste durch Abgleich mit dem Subdomänenabschnitt des FQDN unterscheiden. Unser anderer Anwendungsfall ist der Abgleich mit der L3-Quell-IP-Adresse im Paket-Header (src-ip), um nur bestimmten IP-Adressen den Zugriff auf ausgewählte Dienste/Mikrodienste zu gestatten.
Das Team, dem ich angehöre, hat zwei große Kubernetes-Anwendungen und mehrere kleinere Anwendungen, für die wir die Kemp-Produktionsumgebungen verwalten. Mithilfe eines virtuellen Dienstes mit untervirtuellen Diensten zur Darstellung separater Anwendungen und Anwendungs-Mikroservices in Kombination mit einem Inhaltsabgleich können wir das Routing zu exponierten Kubernetes-Sockets problemlos konfigurieren.
Beispiel (basierend auf einer Live-Umgebung)
Im obigen Beispiel gibt es 3 virtuelle Dienste der obersten Ebene: 2 sind für die Unterstützung von Legacy-Anwendungen (Backend für virtuelle Maschinen) und der dritte dient der Bereitstellung von Anwendungen, die auf Kubernetes veröffentlicht werden.
Das obige Beispiel zeigt typische Regeln für die Übereinstimmung von Hostnameninhalten, die für diese Anwendung sinnvoll wären.
Hier wird gezeigt, wie man den Quell-IP-Abgleich konfiguriert, mit dem man den Zugang zu Diensten/Mikrodiensten abhängig oder unabhängig von anderen Regeln einschränken/erlauben kann. So könnte beispielsweise der Zugriff auf einen Verwaltungsbereich einer Anwendung nur über eine einzige Quell-IP-Adresse erfolgen.
Die Option "Content Switching" muss im Abschnitt "Erweiterte Eigenschaften" der Konfiguration aktiviert werden, und die Regeln sollten auf jedes relevante SubVS am unteren Rand angewendet werden. In einigen Szenarien müssen Sie möglicherweise die Rangfolge der Regeln anpassen (Reihenfolge, in der die Regeln für den eingehenden Datenverkehr verarbeitet werden).
Die Konfiguration des virtuellen Dienstes selbst leitet nicht zu irgendetwas weiter, wenn keine echten Server definiert sind. Der letzte Schritt ist das Hinzufügen der exponierten Kubernetes-Knoten-Dienstport(s) zum subvirtuellen Dienst.
Eine detailliertere Erläuterung zur Konfiguration des Hostnamen-Content-Switching finden Sie in diesem Dokument. Eine detailliertere Erklärung zur Konfiguration des Inhaltsschalters der Quell-IP-Adresse finden Sie in diesem Dokument.
Bei Kemp haben wir ein API-Modul für den LoadMaster entwickelt, das eine automatisierte dynamische Verknüpfung von virtuellen Diensten mit Kubernetes-Service-Pods ermöglicht. Der Load-Balancer wird so konfiguriert, dass er mit Kubernetes kommuniziert und dabei eine zertifikatsbasierte Authentifizierung verwendet, um mit dem K8s-API-Server zu kommunizieren. Tags werden zu den Diensten hinzugefügt, für die Sie virtuelle Dienste erstellt haben, und die Wartung der Dienste wird zum Kinderspiel, da Pods automatisch verknüpft/entkoppelt werden, wenn sie erstellt/gelöscht werden.
Da es möglich ist, Content-Regeln zu verwenden, um die Sicherheit in der Anwendungsschicht zu verbessern, hat mein Team es als besonders nützlich empfunden, einige der Anwendungen zu veröffentlichen, bei denen wir nur ein sehr kleines Dev-Profil haben oder nicht direkt zur Diskussion über die Anwendungssicherheit beitragen würden.
Im Laufe der Jahre haben wir unsere Websites mehrfach auditieren und stichprobenartig testen lassen. Ich werde die häufigsten Sicherheitsheader-Injektionen/Änderungen behandeln, die wir auf die Anwendungen angewendet haben. Es ist möglich, Richtlinien für jeden der HTTP-Sicherheitsheader anzuwenden. Es gibt viele fantastische kostenlose Auditing-Tools, aber speziell für die HTTP-Sicherheit würde ich Mozilla Observatory empfehlen. (hier)
Der HTTP Strict-Transport-Security (HSTS)-Antwort-Header teilt Browsern/Anwendungen mit, dass auf diese Website nur über HTTPS zugegriffen werden sollte. Dadurch wird verhindert, dass Clients aufgrund von Fehlkonfigurationen des Servers oder Problemen mit Client-Anwendungen/Browsern unsicher auf die Website zugreifen. (oder weil jemand versehentlich eine Entwicklungsinstanz freigegeben hat....)
Diese Header-Injection-Regel weist den Client und die Zwischengeräte an, dass der Content-Type-Header nicht geändert werden darf und befolgt werden muss. Dies kann nützlich sein, um clientseitige Anwendungen/Browser aufzufordern, Nutzdaten auf eine bestimmte Weise zu behandeln, um ein erwartetes Verhalten zu erzwingen.
Die Header-Injektion weist die Browser an, das Laden von Seiten zu stoppen, wenn sie Cross-Site-Scripting-Angriffe (XSS) erkennen. In neueren Versionen von Browsern ist dies zugunsten eines Content-Security-Policy-Headers veraltet, hat aber seine Berechtigung zur Unterstützung älterer Systeme.
Die Content-Security-Policy (CSP) ist die derzeitige Methode zum Schutz vor mehreren verschiedenen Angriffsvektoren, vor allem im Zusammenhang mit XSS. Als wir in unserer Umgebung CSP auf dem Load-Balancer aktivierten, brachte dies mehrere Sicherheitsbedenken im Zusammenhang mit Workflows innerhalb einer Anwendung ans Licht. Obwohl die Entwickler zu diesem Zeitpunkt nicht sehr erfreut waren, führte dies langfristig zu sinnvollen Prozessänderungen. Weitere Informationen zu CSP finden Sie hier und/oder hier.
Unsere interne Entwicklungsumgebung bei Kemp hat von der Nutzung des erweiterten Application Switching in unserer Kubernetes-Umgebung profitiert. Die Integration einer Kubernetes-Ingress-Controller-API mit den benutzerfreundlichen und robusten Inhaltsrichtlinien-Regelsätzen hat unseren Workflow reibungsloser und sicherer gemacht. Ich hoffe, dieser Bericht ist für Ihre DevOps-Situation von Nutzen. Die Kemp LoadMaster-Lösung hat viele Probleme für unsere Kunden und innerhalb der Kemp Entwicklungsteams gelöst.