Sechs Möglichkeiten zur Sicherung von Kubernetes mit Traffic-Management-Tools

Redakteur – Dieser Beitrag ist Teil einer 10-teiligen Serie:

1. Reduzieren Sie die Komplexität mit produktionsreifem Kubernetes
2. So verbessern Sie die Ausfallsicherheit in Kubernetes mit erweitertem Verkehrsmanagement
3. So verbessern Sie die Sichtbarkeit in Kubernetes
4. Sechs Möglichkeiten zur Sicherung von Kubernetes mithilfe von Traffic-Management-Tools (dieser Beitrag)
5. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Identifizieren Sie Ihre Anforderungen
6. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 2: Risiken und Zukunftssicherheit
7. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 3: Open Source vs. Standard vs. Kommerziell
8. Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller
9. So wählen Sie ein Service Mesh aus
10. Leistungstests für NGINX-Ingress-Controller in einer dynamischen Kubernetes-Cloud-Umgebung

Sie können den kompletten Blogsatz auch als kostenloses E-Book herunterladen: Kubernetes vom Test zur Produktion bringen .

Wie im Abschnitt „Cloudnative Apps ohne Geschwindigkeitsverlust sichern“ erläutert, haben wir drei Faktoren beobachtet, die die Sicherung cloudnativer Apps schwieriger machen als die Sicherung herkömmlicher Apps:

1. Cloudnative App-Bereitstellung führt zu einem Wildwuchs an Tools und bietet inkonsistente Dienste auf Unternehmensniveau
2. Die Kosten für die Bereitstellung cloudnativer Apps können unvorhersehbar und hoch sein
3. SecOps-Teams haben Probleme beim Schutz von Cloud-nativen Apps und stehen im Konflikt mit DevOps

Obwohl alle drei Faktoren die Sicherheit gleichermaßen beeinflussen können, ist der dritte Faktor möglicherweise das am schwierigsten zu lösende Problem – vielleicht, weil er am „menschlichsten“ ist. Wenn SecOps nicht in der Lage oder befugt ist, Cloud-native Apps zu schützen, sind einige der Folgen offensichtlich (Schwachstellen und Verstöße), andere jedoch verborgen, darunter verringerte Agilität und ein Stocken der digitalen Transformation.

Lassen Sie uns diese versteckten Kosten genauer untersuchen. Organisationen entscheiden sich für Kubernetes , weil es Agilität und Kosteneinsparungen verspricht. Wenn es jedoch in einer Kubernetes-Umgebung zu Sicherheitsvorfällen kommt, ziehen die meisten Organisationen ihre Kubernetes-Bereitstellungen aus der Produktion . Dadurch werden Initiativen zur digitalen Transformation verlangsamt, die für die Zukunft des Unternehmens von entscheidender Bedeutung sind – ganz zu schweigen von der Verschwendung von Entwicklungsaufwand und Geld. Die logische Schlussfolgerung lautet: Wenn Sie versuchen, Kubernetes vom Test in die Produktion zu bringen, muss Sicherheit als strategische Komponente betrachtet werden, für die sich jeder in der Organisation einsetzt.

In diesem Beitrag behandeln wir sechs Sicherheitsanwendungsfälle, die Sie mit Kubernetes-Verkehrsmanagementtools lösen können. So können SecOps mit DevOps und NetOps zusammenarbeiten, um Ihre Cloud-nativen Apps und APIs besser zu schützen. Eine Kombination dieser Techniken wird häufig verwendet, um eine umfassende Sicherheitsstrategie zu erstellen, die die Sicherheit von Apps und APIs gewährleistet und gleichzeitig die Auswirkungen auf die Kunden minimiert.

1. Beheben Sie CVEs schnell, um Cyberangriffe zu vermeiden
2. Stoppen Sie OWASP Top 10 und Denial-of-Service -Angriffe
3. Entlasten Sie Apps von Authentifizierung und Autorisierung
4. Einrichten von Self‑Service mit Leitplanken
5. Implementieren Sie eine End-to-End -Verschlüsselung
6. Stellen Sie sicher, dass Clients eine starke Verschlüsselung mit einer vertrauenswürdigen Implementierung verwenden

Sicherheits- und Identitätsterminologie

Bevor wir uns in die Anwendungsfälle stürzen, hier ein kurzer Überblick über einige Sicherheits- und Identitätsbegriffe, die Ihnen in diesem Beitrag begegnen werden.

• Authentifizierung und Autorisierung – Funktionen, die erforderlich sind, um sicherzustellen, dass nur die „richtigen“ Benutzer und Dienste Zugriff auf Backends oder Anwendungskomponenten erhalten:

  • Authentifizierung – Überprüfung der Identität , um sicherzustellen, dass die anfragenden Kunden tatsächlich die Personen sind, für die sie sich ausgeben. Dies wird durch ID-Tokens wie Passwörter oder JSON Web Tokens (JWTs) erreicht.

  • Autorisierung – Überprüfung der Berechtigung zum Zugriff auf eine Ressource oder Funktion. Dies wird durch Zugriffstoken erreicht, beispielsweise Layer-7-Attribute wie Sitzungscookies, Sitzungs-IDs, Gruppen-IDs oder Token-Inhalte.

• Kritische Sicherheitslücken und Gefährdungen (CVEs) – Eine Datenbank mit öffentlich bekannt gewordenen Fehlern „in einer Software-, Firmware-, Hardware- oder Servicekomponente, die auf eine ausgenutzte Schwachstelle zurückzuführen sind und sich negativ auf die Vertraulichkeit, Integrität oder Verfügbarkeit einer oder mehrerer betroffener Komponenten auswirken“ ( https://www.cve.org/ ). CVEs können von den Entwicklern entdeckt werden, die das Tool verwalten, von einem Penetrationstester, einem Benutzer oder Kunden oder jemandem aus der Community (z. B. einem „Bughunter“). Es ist üblich, dem Softwarebesitzer Zeit zu geben, einen Patch zu entwickeln, bevor die Sicherheitslücke öffentlich bekannt gegeben wird, um böswilligen Akteuren keinen Vorteil zu verschaffen.

• Denial-of-Service-Angriff (DoS) – Ein Angriff, bei dem ein böswilliger Akteur eine Website mit Anfragen (TCP/UDP oder HTTP/HTTPS) überflutet, um die Site zum Absturz zu bringen. Da DoS-Angriffe die Verfügbarkeit beeinträchtigen, besteht ihr Hauptergebnis in einer Schädigung des Rufs des Ziels. Gegen einen Distributed -Denial-of-Service-Angriff (DDoS) , bei dem mehrere Quellen auf dasselbe Netzwerk oder denselben Dienst abzielen, ist aufgrund des potenziell großen Angreifernetzwerks schwieriger abzuwehren. Zum DoS-Schutz ist ein Tool erforderlich, das Angriffe adaptiv erkennt und verhindert. Weitere Informationen finden Sie unter „Was ist Distributed Denial of Service (DDoS)?“.

• Ende-zu-Ende-Verschlüsselung (E2EE) – Das Verfahren der vollständigen Verschlüsselung von Daten beim Übergang vom Benutzer zur App und zurück. E2EE erfordert SSL-Zertifikate und möglicherweise mTLS.

• Mutual TLS (mTLS) – Die Praxis, sowohl für den Client als auch für den Host eine Authentifizierung (über ein SSL/TLS-Zertifikat) zu verlangen. Die Verwendung von mTLS schützt auch die Vertraulichkeit und Integrität der zwischen Client und Host übertragenen Daten. mTLS kann bis auf die Kubernetes-Pod-Ebene zwischen zwei Diensten im selben Cluster eingesetzt werden. Eine hervorragende Einführung in SSL/TLS und mTLS finden Sie unter „Was ist mTLS?“ bei F5 Labs.

• Single Sign-On (SSO) – SSO-Technologien (einschließlich SAML, OAuth und OIDC) erleichtern die Verwaltung von Authentifizierung und Autorisierung.

  • Vereinfachte Authentifizierung – SSO macht es überflüssig, dass ein Benutzer für jede unterschiedliche Ressource oder Funktion über ein eindeutiges ID-Token verfügt.

  • Standardisierte Autorisierung – SSO erleichtert die Festlegung von Benutzerzugriffsrechten basierend auf Rolle, Abteilung und Dienstaltersstufe, sodass die Berechtigungen nicht mehr für jeden Benutzer einzeln konfiguriert werden müssen.

• SSL (Secure Sockets Layer)/TLS (Transport Layer Security) – Ein Protokoll zum Herstellen authentifizierter und verschlüsselter Verbindungen zwischen vernetzten Computern. SSL/TLS-Zertifikate authentifizieren die Identität einer Website und stellen eine verschlüsselte Verbindung her. Obwohl das SSL-Protokoll 1999 veraltet und durch das TLS-Protokoll ersetzt wurde, ist es immer noch üblich, diese verwandten Technologien als „SSL“ oder „SSL/TLS“ zu bezeichnen. Der Einheitlichkeit halber verwenden wir im weiteren Verlauf dieses Beitrags SSL/TLS .

• Web Application Firewall (WAF) – Ein Reverse-Proxy , der ausgeklügelte Angriffe auf Apps und APIs (einschließlich OWASP Top 10 und anderer fortgeschrittener Bedrohungen) erkennt und blockiert, gleichzeitig aber „sicheren“ Datenverkehr durchlässt. WAFs schützen vor Angriffen, die dem Ziel durch Diebstahl vertraulicher Daten oder Entführung des Systems schaden wollen. Einige Anbieter konsolidieren WAF- und DoS-Schutz im selben Tool, während andere separate WAF- und DoS-Tools anbieten.

• Zero Trust – Ein Sicherheitskonzept, das häufig in Organisationen mit höherer Sicherheit verwendet wird, aber für alle relevant ist, bei denen Daten in allen Phasen der Speicherung und des Transports gesichert werden müssen. Dies bedeutet, dass die Organisation beschlossen hat, standardmäßig keinem Benutzer oder Gerät zu „vertrauen“, sondern eine gründliche Überprüfung des gesamten Datenverkehrs zu verlangen. Eine Zero-Trust-Architektur umfasst typischerweise eine Kombination aus Authentifizierung, Autorisierung und mTLS mit einer hohen Wahrscheinlichkeit, dass die Organisation E2EE implementiert.

Anwendungsfall: Beheben Sie CVEs schnell, um Cyberangriffe zu vermeiden

Lösung: Verwenden Sie Tools mit zeitnahen und proaktiven Patch-Benachrichtigungen

Einer Studie des Ponemon Institute zufolge betrug im Jahr 2019 zwischen der Veröffentlichung eines Patches für eine kritische oder hochprioritäre Sicherheitslücke und dem Zeitpunkt, als Organisationen Angriffe bemerkten, bei denen versucht wurde, diese Sicherheitslücke auszunutzen, eine durchschnittliche „Schonfrist“ von 43 Tagen. Bei F5 NGINX haben wir beobachtet, dass sich dieses Zeitfenster in den darauffolgenden Jahren deutlich verkleinert hat ( im Fall von Apple iOS 15 im Jahr 2021 sogar bis zum Tag Null ). Deshalb empfehlen wir, Patches so schnell wie möglich durchzuführen. Was aber, wenn für Ihre Verkehrsmanagement-Tools noch Wochen oder sogar Monate nach der Bekanntgabe einer CVE keine Patches verfügbar sind?

Tools, die von Community-Mitwirkenden (und nicht von einem dedizierten Engineering-Team) entwickelt und gepflegt werden, hinken den CVE-Ankündigungen möglicherweise Wochen oder Monate hinterher. Daher ist es unwahrscheinlich, dass Organisationen innerhalb dieses 43-tägigen Zeitfensters Patches bereitstellen können. In einem Fall benötigte OpenResty vier Monate, um einen NGINX-bezogenen Sicherheitspatch anzuwenden. Dadurch war jeder, der einen auf OpenResty basierenden Ingress-Controller verwendete, mindestens vier Monate lang angreifbar, aber realistisch gesehen dauert es normalerweise noch länger, bis Patches für Software verfügbar sind, die auf einem Open-Source-Projekt basiert.

Um CVE-Patches schnellstmöglich zu erhalten, achten Sie bei der Auswahl der Traffic-Management-Tools auf zwei Merkmale:

• Ein engagiertes Entwicklungsteam – Wenn die Tool-Entwicklung von einem Entwicklungsteam und nicht von Freiwilligen aus der Community verwaltet wird, wissen Sie, dass es eine Gruppe von Leuten gibt, die sich um die Funktionsfähigkeit des Tools kümmern und die schnellstmögliche Veröffentlichung eines Patches priorisieren können.
• Eine integrierte Codebasis – Ohne externe Abhängigkeiten (wie wir sie mit OpenResty besprochen haben) sind Patches nur einen agilen Sprint entfernt.

Weitere Informationen zum CVE-Patching finden Sie unter „Sicherheitslücken schnell und einfach mit NGINX Plus beheben“ .

Anwendungsfall: Stoppen Sie OWASP Top 10 und DoS-Angriffe

Lösung: Stellen Sie flexiblen, Kubernetes-freundlichen WAF- und DoS-Schutz bereit

Die Wahl des richtigen WAF- und DoS-Schutzes für Kubernetes-Apps hängt (zusätzlich zu den Funktionen) von zwei Faktoren ab:

• Flexibilität – Es gibt Szenarien, in denen es am besten ist, Tools innerhalb von Kubernetes bereitzustellen. Daher möchten Sie infrastrukturunabhängige Tools, die innerhalb oder außerhalb von Kubernetes ausgeführt werden können. Wenn Sie für alle Ihre Bereitstellungen dasselbe Tool verwenden, können Sie Richtlinien wiederverwenden und die Lernkurve für Ihre SecOps-Teams verkürzen.
• Footprint – Die besten Kubernetes-Tools haben einen kleinen Footprint, der einen angemessenen Ressourcenverbrauch mit minimalen Auswirkungen auf Durchsatz, Anfragen pro Sekunde und Latenz ermöglicht. DevOps-Teams lehnen Sicherheitstools häufig ab, weil sie den Eindruck haben, dass diese Apps verlangsamen. Die Wahl eines leistungsstarken Tools mit geringem Platzbedarf kann die Wahrscheinlichkeit einer Einführung erhöhen.

Ein Tool, das WAF und DoS-Schutz konsolidiert, mag zwar effizienter erscheinen, es ist jedoch davon auszugehen, dass es sowohl hinsichtlich der CPU-Auslastung (aufgrund des größeren Platzbedarfs) als auch hinsichtlich der Flexibilität Probleme gibt. Sie sind gezwungen, WAF und DoS-Schutz zusammen einzusetzen, auch wenn Sie nicht beides benötigen. Letztendlich können beide Probleme die Gesamtbetriebskosten Ihrer Kubernetes-Bereitstellungen in die Höhe treiben und gleichzeitig zu Budgetproblemen bei anderen wichtigen Tools und Diensten führen.

Nachdem Sie die richtigen Sicherheitstools für Ihr Unternehmen ausgewählt haben, müssen Sie entscheiden, wo diese Tools bereitgestellt werden sollen. Es gibt vier Orte, an denen Anwendungsdienste normalerweise zum Schutz von Kubernetes-Apps bereitgestellt werden können:

• An der Vordertür (auf einem externen Load Balancer wie F5 NGINX Plus oder F5 BIG‑IP ) – Gut für „grobkörnigen“ globalen Schutz, da Sie damit globale Richtlinien auf mehrere Cluster anwenden können
• Am Rand (auf einem Ingress-Controller wie dem F5 NGINX Ingress Controller ) – Ideal für die Bereitstellung eines „feinkörnigen“ Schutzes, der in einem einzelnen Cluster Standard ist.
• Beim Dienst (auf einem leichten Load Balancer wie NGINX Plus) – Kann ein notwendiger Ansatz sein, wenn es innerhalb eines Clusters eine kleine Anzahl von Diensten gibt, die einen gemeinsamen Bedarf an einzigartigen Richtlinien haben.
• Am Pod (als Teil der Anwendung) – Ein sehr individueller Ansatz, der verwendet werden kann, wenn die Richtlinie spezifisch für die App ist

Welche der vier Optionen ist also die beste? Nun … das kommt darauf an!

Wo kann eine WAF bereitgestellt werden?

Wir werden uns zunächst die WAF-Bereitstellungsoptionen ansehen, da diese tendenziell eine differenziertere Auswahl erfordern.

• Vordertür und Rand – Wenn Ihre Organisation eine Sicherheitsstrategie mit „Defense in Depth“ bevorzugt, empfehlen wir die Bereitstellung einer WAF sowohl beim externen Load Balancer als auch beim Ingress-Controller, um eine effiziente Balance zwischen globalen und benutzerdefinierten Schutzmechanismen zu erreichen.
• Vordertür oder Rand – In Ermangelung einer „Defense-in-Depth“-Strategie ist ein einzelner Standort akzeptabel und der Bereitstellungsort hängt von den Eigentümern ab. Wenn ein herkömmliches NetOps-Team für die Sicherheit verantwortlich ist, kann es diese möglicherweise bequemer auf einem herkömmlichen Proxy (dem externen Load Balancer) verwalten. DevSecOps-Teams, die mit Kubernetes vertraut sind (und ihre Sicherheitskonfiguration lieber in der Nähe ihrer Clusterkonfigurationen haben möchten), können sich jedoch für die Bereitstellung einer WAF auf der Eingangsebene entscheiden.
• Pro Dienst oder Pod – Wenn Ihre Teams spezielle Anforderungen an ihre Dienste oder Apps haben, können sie zusätzliche WAFs à la carte bereitstellen. Aber Vorsicht: Diese Standorte sind mit höheren Kosten verbunden. Neben einer längeren Entwicklungszeit und einem höheren Cloud-Budget kann diese Wahl auch zu höheren Betriebskosten im Zusammenhang mit der Fehlerbehebung führen – beispielsweise bei der Feststellung: „Welche unserer WAFs blockiert unbeabsichtigt den Datenverkehr?“

Wo kann DoS-Schutz eingesetzt werden?

Der Schutz vor DoS-Angriffen ist einfacher, da er nur an einer Stelle erforderlich ist – entweder an der Eingangstür oder am Ingress-Controller. Wenn Sie eine WAF sowohl an der Front Door als auch am Edge bereitstellen, empfehlen wir Ihnen, den DoS-Schutz vor der Front Door-WAF bereitzustellen, da dieser am globalsten ist. Auf diese Weise lässt sich unerwünschter Datenverkehr aussortieren, bevor er die WAF erreicht, und Sie können Ihre Rechenressourcen effizienter nutzen.

Weitere Einzelheiten zu jedem dieser Bereitstellungsszenarien finden Sie unter Bereitstellen von Anwendungsdiensten in Kubernetes, Teil 2 .

Anwendungsfall: Auslagerung von Authentifizierung und Autorisierung aus Apps

Lösung: Zentralisieren Sie die Authentifizierung und Autorisierung am Zugangspunkt

Eine häufige nicht funktionale Anforderung, die in Apps und Dienste integriert wird, ist die Authentifizierung und Autorisierung. Im kleinen Maßstab führt dieses Vorgehen zu einer überschaubaren Komplexität, die akzeptabel ist, wenn für die App keine häufigen Updates erforderlich sind. Doch mit immer schnelleren Release-Geschwindigkeiten im größeren Maßstab wird die Integration von Authentifizierung und Autorisierung in Ihre Apps unhaltbar. Die Sicherstellung, dass jede App die entsprechenden Zugriffsprotokolle einhält, kann von der Geschäftslogik der App ablenken oder, schlimmer noch, übersehen werden und zu einem Informationsverstoß führen. Zwar kann die Verwendung von SSO-Technologien durch den Verzicht auf separate Benutzernamen und Passwörter zugunsten eines einzigen Satzes von Anmeldeinformationen die Sicherheit verbessern, Entwickler müssen jedoch dennoch Code in ihre Apps integrieren, um eine Schnittstelle zum SSO-System zu schaffen.

Es gibt einen besseren Weg: Verlagern Sie die Authentifizierung und Autorisierung auf einen Ingress-Controller.

Da der Ingress-Controller bereits den gesamten in den Cluster eingehenden Datenverkehr überprüft und an die entsprechenden Dienste weiterleitet, ist er eine effiziente Wahl für eine zentrale Authentifizierung und Autorisierung. Dadurch müssen Entwickler die Logik im Anwendungscode nicht mehr erstellen, verwalten und replizieren. Stattdessen können sie mithilfe der nativen Kubernetes-API schnell SSO-Technologien auf der Eingangsebene nutzen.

Weitere Informationen zu diesem Thema finden Sie unter Implementieren der OpenID Connect-Authentifizierung für Kubernetes mit Okta und NGINX Ingress Controller .

Anwendungsfall: Self-Service mit Guardrails einrichten

Lösung: Implementieren Sie eine rollenbasierte Zugriffskontrolle (RBAC).

Kubernetes verwendet RBAC, um die Ressourcen und Vorgänge zu steuern, die verschiedenen Benutzertypen zur Verfügung stehen. Dies ist eine wertvolle Sicherheitsmaßnahme, da sie einem Administrator oder Superuser ermöglicht, zu bestimmen, wie Benutzer oder Benutzergruppen mit jedem Kubernetes-Objekt oder bestimmten Namespace im Cluster interagieren können.

Während Kubernetes RBAC standardmäßig aktiviert ist, müssen Sie darauf achten, dass Ihre Kubernetes-Verkehrsverwaltungstools auch RBAC-fähig sind und den Sicherheitsanforderungen Ihres Unternehmens entsprechen. Durch die Implementierung von RBAC erhalten Benutzer eingeschränkten Zugriff auf die Funktionen, die sie für ihre Arbeit benötigen, ohne auf die Bearbeitung eines Tickets warten zu müssen. Wenn RBAC nicht konfiguriert ist, können Benutzer jedoch Berechtigungen erhalten, die sie nicht benötigen oder auf die sie keinen Anspruch haben. Bei Missbrauch der Berechtigungen kann dies zu Sicherheitslücken führen.

Ein Ingress-Controller ist ein Paradebeispiel für ein Tool, das bei Konfiguration mit RBAC zahlreichen Personen und Teams dienen kann. Wenn der Ingress-Controller eine feinkörnige Zugriffsverwaltung ermöglicht – sogar bis hinunter zu einem einzelnen Namespace –, können Sie RBAC verwenden, um eine effiziente Ressourcennutzung durch Mandantenfähigkeit zu ermöglichen.

Beispielsweise könnten mehrere Teams den Ingress-Controller wie folgt verwenden:

• NetOps-Team – Konfiguriert externe Einstiegspunkte der Anwendung (wie Hostnamen und TLS-Zertifikate) und delegiert Verkehrskontrollrichtlinien an verschiedene Teams.
• DevOps-Team A – Stellt TCP/UDP-Load-Balancing- und Routing-Richtlinien bereit
• DevOps-Team B – Konfiguriert Ratenbegrenzungsrichtlinien, um Dienste vor übermäßigen Anfragen zu schützen.
• Identity Team – Verwaltet Authentifizierungs- und Autorisierungskomponenten und konfiguriert mTLS-Richtlinien als Teil einer End-to-End -Verschlüsselungsstrategie
• DevSecOps-Team – Legt WAF-Richtlinien fest

Um zu erfahren, wie Sie RBAC im NGINX Ingress Controller nutzen können, sehen Sie sich „Erweiterte Kubernetes-Bereitstellungen mit NGINX Ingress Controller“ an. Ab 13:50 erklären unsere Experten, wie Sie RBAC und Ressourcenzuweisung für Sicherheit, Self-Service und Multi-Tenancy nutzen können.

Anwendungsfall: Implementieren Sie eine End-to-End-Verschlüsselung

Lösung: Verwenden Sie Tools zum Verkehrsmanagement

Für Organisationen, die mit sensiblen oder persönlichen Daten umgehen, wird die Ende-zu-Ende-Verschlüsselung (E2EE) zunehmend zu einer Anforderung. Ob es um Finanzdaten oder Social-Media-Nachrichten geht: Die Erwartungen der Verbraucher an den Datenschutz in Verbindung mit Vorschriften wie der DSGVO und HIPAA treiben die Nachfrage nach dieser Art von Schutz voran. Der erste Schritt zur Erreichung von E2EE besteht darin, entweder Ihre Backend-Apps so zu strukturieren, dass sie SSL/TLS-Verkehr akzeptieren, oder ein Tool zu verwenden, das Ihre Apps von der SSL/TLS-Verwaltung entlastet (die bevorzugte Option zur Trennung von Sicherheitsfunktion, Leistung, Schlüsselverwaltung usw.). Anschließend konfigurieren Sie Ihre Verkehrsmanagement-Tools je nach Komplexität Ihrer Umgebung.

Häufigstes Szenario: E2EE mit einem Ingress-Controller

Wenn Sie Apps mit nur einem Endpunkt haben (einfache Apps oder monolithische Apps, die Sie in Kubernetes „gehoben und verschoben“ haben) oder keine Dienst-zu-Dienst -Kommunikation stattfindet, können Sie einen Ingress-Controller verwenden, um E2EE innerhalb von Kubernetes zu implementieren.

Schritt 1: Stellen Sie sicher, dass Ihr Ingress-Controller nur verschlüsselte SSL/TLS-Verbindungen mithilfe von serviceseitigen oder mTLS-Zertifikaten zulässt, idealerweise sowohl für eingehenden als auch für ausgehenden Datenverkehr.

Schritt 2: Beheben Sie die typische Standardeinstellung, die erfordert, dass der Ingress-Controller den Datenverkehr entschlüsselt und erneut verschlüsselt, bevor er ihn an die Apps sendet. Dies kann auf verschiedene Arten erreicht werden – die von Ihnen gewählte Methode hängt von Ihrem Ingress-Controller und Ihren Anforderungen ab:

• Wenn Ihr Ingress-Controller SSL/TLS-Passthrough unterstützt, kann er SSL/TLS-verschlüsselte Verbindungen basierend auf dem Service Name Indication (SNI)-Header weiterleiten, ohne sie zu entschlüsseln oder Zugriff auf die SSL/TLS-Zertifikate oder -Schlüssel zu benötigen.
• Alternativ können Sie eine SSL/TLS-Terminierung einrichten, bei der der Ingress-Controller den Datenverkehr beendet und ihn dann an die Backends oder Upstreams weiterleitet – entweder im Klartext oder durch erneute Verschlüsselung des Datenverkehrs mit mTLS oder serviceseitigem SSL/TLS zu Ihren Kubernetes-Diensten.

Weniger häufiges Szenario: E2EE mithilfe eines Ingress-Controllers und Service Mesh

Wenn in Ihrem Cluster eine Dienst-zu-Dienst- Kommunikation stattfindet, müssen Sie E2EE auf zwei Ebenen implementieren: Ingress-Egress-Verkehr mit dem Ingress-Controller und Dienst-zu-Dienst -Verkehr mit einem Service-Mesh . Bei E2EE besteht die Rolle eines Service Mesh darin, sicherzustellen, dass nur bestimmte Dienste miteinander kommunizieren dürfen und dass dies auf sichere Weise geschieht. Wenn Sie ein Service Mesh für E2EE einrichten, müssen Sie eine Zero-Trust-Umgebung mithilfe von zwei Faktoren aktivieren: mTLS zwischen Diensten (eingestellt auf die Anforderung eines Zertifikats) und Verkehrszugriffskontrolle zwischen Diensten (die vorgibt, welche Dienste zur Kommunikation autorisiert sind). Idealerweise implementieren Sie auch mTLS zwischen den Anwendungen (verwaltet von einem Service Mesh und dem Ingress-Egress-Controller), um echte E2EE-Sicherheit im gesamten Kubernetes-Cluster zu gewährleisten.

Weitere Informationen zum Verschlüsseln von über das Kabel offengelegten Daten finden Sie in „Die mTLS-Architektur im NGINX Service Mesh“ .

Anwendungsfall: Stellen Sie sicher, dass Clients eine starke Verschlüsselung mit einer vertrauenswürdigen Implementierung verwenden

Lösung: Einhaltung der Federal Information Processing Standards (FIPS)

In der Softwarebranche bezieht sich FIPS normalerweise auf die Veröffentlichung speziell zur Kryptografie, FIPS PUB 140-2 „Sicherheitsanforderungen für kryptografische Module“, eine gemeinsame Entwicklung der Vereinigten Staaten und Kanadas. Es standardisiert die Prüfung und Zertifizierung kryptografischer Module, die von den Bundesbehörden beider Länder zum Schutz sensibler Informationen anerkannt werden. „Aber warten Sie!“, sagen Sie. „FIPS ist mir egal, da ich nicht mit nordamerikanischen Regierungsstellen zusammenarbeite.“ Unabhängig von Ihrer Branche oder Ihrem Standort kann es sich lohnen, FIPS-konform zu werden, denn FIPS ist de facto auch die globale kryptografische Basis.

Die Einhaltung von FIPS muss nicht schwierig sein, erfordert aber, dass sowohl Ihr Betriebssystem als auch die relevanten Verkehrsmanagement-Tools im FIPS-Modus arbeiten können. Es besteht ein weit verbreitetes Missverständnis, dass die FIPS-Konformität einfach durch das Ausführen des Betriebssystems im FIPS-Modus erreicht wird. Selbst wenn sich das Betriebssystem im FIPS-Modus befindet, ist es immer noch möglich, dass Clients, die mit Ihrem Ingress-Controller kommunizieren, keine starke Verschlüsselung verwenden. Beim Betrieb im FIPS-Modus verwenden Ihr Betriebssystem und Ihr Ingress-Controller möglicherweise nur eine Teilmenge der typischen SSL/TLS-Chiffren.

Das Einrichten von FIPS für Ihre Kubernetes-Bereitstellungen erfolgt in vier Schritten:

• Schritt 1: Konfigurieren Sie Ihr Betriebssystem für den FIPS-Modus
• Schritt 2: Überprüfen Sie, ob sich das Betriebssystem und OpenSSL im FIPS-Modus befinden.
• Schritt 3: Installieren des Ingress-Controllers
• Schritt 4: Überprüfen Sie die Konformität mit FIPS 140-2, indem Sie eine FIPS-Statusprüfung durchführen

Wenn im folgenden Beispiel der FIPS-Modus sowohl für das Betriebssystem als auch für die von NGINX Plus verwendete OpenSSL-Implementierung aktiviert ist, wird der gesamte Endbenutzerdatenverkehr von und zu NGINX Plus mithilfe einer validierten, FIPS-fähigen Krypto-Engine entschlüsselt und verschlüsselt.

Weitere Informationen zu FIPS finden Sie unter „Erreichen der FIPS-Konformität mit NGINX Plus“ .

Machen Sie Kubernetes mit NGINX sicherer

Wenn Sie bereit sind, einige (oder alle) dieser Sicherheitsmethoden zu implementieren, müssen Sie sicherstellen, dass Ihre Tools über die richtigen Funktionen und Fähigkeiten verfügen, um Ihre Anwendungsfälle zu unterstützen. NGINX kann mit unserer Suite produktionsreifer Kubernetes-Verkehrsmanagementtools helfen:

• NGINX Ingress Controller – NGINX Plus-basierter Ingress Controller für Kubernetes, der erweiterte Verkehrskontrolle und -gestaltung, Überwachung und Sichtbarkeit, Authentifizierung und SSO übernimmt und als API-Gateway fungiert.

• F5 NGINX App Protect – Ganzheitlicher Schutz für moderne Apps und APIs, basierend auf den marktführenden Sicherheitstechnologien von F5, der sich in NGINX Ingress Controller und NGINX Plus integrieren lässt. Verwenden Sie einen modularen Ansatz für Flexibilität in Bereitstellungsszenarien und optimale Ressourcennutzung:

  • NGINX App Protect WAF – Ein starkes, leichtes WAF, das mit PCI DDS-Konformität vor OWASP Top 10 und darüber hinaus schützt.

  • NGINX App Protect DoS – Verhaltensbasierte DoS-Erkennung und -Minderung mit konsistentem und adaptivem Schutz über Clouds und Architekturen hinweg.

• F5 NGINX Service Mesh – Leichtes, schlüsselfertiges und entwicklerfreundliches Service Mesh mit NGINX Plus als Enterprise-Sidecar.

Fordern Sie zunächst Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an und laden Sie das stets kostenlose NGINX Service Mesh herunter .