Entdecken Sie die Sicherheitsverbesserungen in Ingress-NGINX v1.2.0 und wie Sie Ihre Kubernetes-Architektur absichern können.
Die Ingress ist eines der am häufigsten angegriffenen Komponenten in Kubernetes. Ein Ingress definiert in der Regel einen HTTP-Reverse-Proxy, der ins Internet exponiert wird und mehrere Websites enthält. Zudem hat er privilegierten Zugang zur Kubernetes-API, beispielsweise um Secrets für TLS-Zertifikate und deren private Schlüssel zu lesen.
Obwohl es sich hierbei um eine riskante Komponente in Ihrer Architektur handelt, ist sie immer noch der beliebteste Weg, um Ihre Dienste ordnungsgemäß bereitzustellen.
Ingress-NGINX war Teil von Sicherheitsbewertungen, die auf ein großes Problem hinwiesen: Wir führen nicht alle notwendigen Sanitärmaßnahmen durch, bevor wir die Konfiguration in eine nginx.conf-Datei umwandeln, was zu Informationslecks führen kann.
Dieses Risiko haben wir erkannt und die Notwendigkeit, es zu beheben, verstanden. Dies ist jedoch ein komplexer Prozess, weshalb wir in der aktuellen Version (v1.2.0) einen anderen Ansatz gewählt haben, um dieses Risiko zu reduzieren (aber nicht zu beseitigen!).
Eine der größten Herausforderungen besteht darin, dass Ingress-NGINX den Web-Proxy-Server (NGINX) zusammen mit dem Ingress-Controller betreibt, der Zugriff auf die Kubernetes-API hat und die nginx.conf-Datei erstellt.
Das bedeutet, dass NGINX den gleichen Zugriff auf das Dateisystem des Controllers hat wie das Kubernetes-Service-Account-Token und andere Konfigurationen aus dem Container. Obwohl es unser Ziel ist, diese Komponenten zu trennen, benötigte das Projekt eine schnelle Antwort; das führte uns zur Idee, chroot() zu verwenden.
Schauen wir uns an, wie ein Ingress-NGINX-Container vor dieser Änderung aussah:
Wie wir sehen können, ist der gleiche Container (nicht der Pod, der Container!), der den HTTP-Proxy bereitstellt, derjenige, der Ingress-Objekte überwacht und das Container-Volume schreibt.
Jetzt lernen Sie die neue Architektur kennen:
Was bedeutet das alles? Eine grundlegende Zusammenfassung ist, dass wir den NGINX-Dienst als Container innerhalb des Controller-Containers isolieren.
Zwar ist dies nicht ganz korrekt, um zu verstehen, was hier gemacht wurde, ist es wichtig zu wissen, wie Linux-Container (und die zugrunde liegenden Mechanismen wie Kernel-Namensräume) funktionieren. Sie können mehr über cgroups im Kubernetes-Glossar erfahren: cgroup und mehr darüber, wie cgroups mit Namespaces im NGINX-Projektartikel Was sind Namespaces und cgroups und wie funktionieren sie? erfahren.
(Bitte beachten Sie, dass Linux-Kernel-Namensräume etwas anderes sind als Kubernetes-Namensräume).
Mit diesen Änderungen möchten wir den Sicherheitsstandard für Ihre Kubernetes-Anwendungen erhöhen. ayedo unterstützt Sie dabei, die bestmöglichen Sicherheitspraktiken in Ihrer Infrastruktur zu implementieren.
Quelle: Kubernetes Blog
Profitieren Sie von skalierbarem App Hosting in Kubernetes, hochverfügbarem Ingress Loadbalancing und erstklassigem Support durch unser Plattform Team. Mit der ayedo Cloud können Sie sich wieder auf das konzentrieren, was Sie am besten können: Software entwickeln.
Moderne generative KI- und große Sprachmodelle (LLMs) stellen Kubernetes vor einzigartige Herausforderungen im Datenverkehrsmanagement. Im Gegensatz zu typischen kurzlebigen, zustandslosen Webanfragen …
Einführung in die Verwaltung von Sidecar-Containern in Kubernetes In der Welt von Kubernetes sind Sidecar-Container nützliche Helfer, die Funktionen erweitern oder zusätzliche Aufgaben für die …
Wir freuen uns, die allgemeine Verfügbarkeit der Gateway API v1.3.0 bekanntzugeben! Diese Version wurde am 24. April 2025 veröffentlicht und bringt spannende neue Funktionen mit sich. Was ändert sich …
Wer Anwendungen produktiv betreibt, braucht keine schönen Dashboards, sondern harte Daten. Performance-Probleme entstehen nie dann, wenn Zeit für Debugging ist. Sie kommen genau dann, wenn Systeme …
Die Frage stellt sich immer wieder. Entwicklerteams liefern Features, optimieren Releases, bauen saubere Architekturen — und dann hängen sie trotzdem noch in der Infrastruktur. Kubernetes-Cluster …
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →