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.
Interessiert an weiteren Inhalten? Hier gehts zu allen Blogs →
