Am 25. Oktober 2023 meldete das National Institute of Standards and Technology (NIST) drei CVEs, die den NGINX Ingress Controller for Kubernetes betrafen:
- CVE-2022-4886 – die Pfadbereinigung von ingress-nginx kann mit der
log_format-Direktive umgangen werden. - CVE-2023-5043 – Die Einschleusung von Annotationen in ingress-nginx ermöglicht die Ausführung beliebiger Befehle.
- CVE-2023-5044 – Über die Annotation nginx.ingress.kubernetes.io/permanent-redirect kann Code eingeschleust werden.
Dieser Bericht und nachfolgende Veröffentlichungen (wie etwa „Dringend: Neue Sicherheitslücken im NGINX Ingress Controller für Kubernetes entdeckt“) sorgten für einige Verwirrung (und eine Reihe von Supportanfragen) darüber, welche NGINX Ingress Controller tatsächlich betroffen sind und wer sich mit der Behebung der in diesen CVEs beschriebenen Schwachstellen befassen sollte.
Die Verwirrung ist durchaus verständlich – wussten Sie, dass es mehr als einen auf NGINX basierenden Ingress-Controller gibt? Zunächst einmal gibt es zwei völlig unterschiedliche Projekte mit dem Namen „NGINX Ingress Controller“:
- Community-Projekt – Dieser Ingress-Controller ist im kubernetes/ingress-nginx-Repository auf GitHub zu finden und basiert auf der Datenebene von NGINX Open Source, wird jedoch von der Kubernetes-Community entwickelt und gepflegt. Die Dokumentation wird auf GitHub bereitgestellt.
- NGINX-Projekt – Zu finden im nginxinc/kubernetes-ingress-Repository auf GitHub. Der NGINX Ingress Controller wird von F5 NGINX entwickelt und gepflegt; die Dokumentation ist auf docs.nginx.com verfügbar. Dieses offizielle NGINX-Projekt ist in zwei Editionen erhältlich:
- Auf NGINX Open Source basierend (kostenlose Open-Source-Option)
- Auf NGINX Plus basierend (kommerzielle Option)
Es gibt auch andere auf NGINX basierende Ingress-Controller, beispielsweise Kong. Glücklicherweise lassen sie sich anhand ihrer Namen leicht unterscheiden. Wenn Sie nicht sicher sind, welchen Sie verwenden, überprüfen Sie das Container-Image des laufenden Ingress-Controllers und vergleichen Sie anschließend den Namen des Docker-Images mit den oben aufgeführten Repositorys.
Die oben beschriebenen Schwachstellen (CVE-2022-4886, CVE-2023-5043 und CVE-2023-5044) betreffen ausschließlich das Community-Projekt (kubernetes/ingress-nginx). Die NGINX-Projekte für den NGINX Ingress Controller (nginxinc/kubernetes-ingress, sowohl Open Source als auch kommerziell) sind von diesen CVEs nicht betroffen.
Weitere Informationen zu den Unterschieden zwischen NGINX Ingress Controller und Ingress-Controller-Projekten finden Sie in unserem Blogbeitrag „Leitfaden zur Auswahl eines Ingress Controllers, Teil 4: Optionen für den NGINX Ingress Controller“.
Über den Autor
Ähnliche Blogbeiträge
Die Zukunft von NGINX: Zurück zu unseren Open-Source-Wurzeln
Beim NGINX Sprint 2022 besinnen wir uns auf unsere Open-Source-Wurzeln. Erfahren Sie mehr über die Initiativen, die wir im kommenden Jahr verfolgen, und teilen Sie uns mit, was Sie sich wünschen.
Ein Leitfaden zur Auswahl eines Ingress-Controllers, Teil 1: Ermitteln Sie Ihre Anforderungen
Ein Ingress-Controller kann eines der leistungsstärksten Tools in Ihrem Kubernetes-Stack sein. Erfahren Sie, wie Sie Ihre Ingress-Anforderungen ermitteln, um die beste Option auszuwählen.
Bereitstellung des NGINX Ingress Controllers auf Amazon EKS: So haben wir getestet
Wir haben kürzlich den Lösungsleitfaden zum NGINX Ingress Controller um Empfehlungen zur Dimensionierung für Amazon Elastic Kubernetes Service (EKS) ergänzt. In diesem Blogbeitrag erläutern wir, wie wir diese Empfehlungen erarbeitet haben, und stellen Ihnen alle Informationen zur Verfügung, die Sie benötigen, um selbst ähnliche Tests durchzuführen.
Protokollierung des Datenverkehrs zwischen NGINX und Upstream-Servern bei CDN77
Bei der Fehlersuche bei Datenverkehrsproblemen zwischen NGINX und Upstream-Servern konnte CDN77 die benötigten Daten nur aus dem Fehlerprotokoll mit aktivierter Debug-Ausgabe beziehen, was die Leistung beeinträchtigt und riesige Dateien erzeugt. Daher entwickelte das Team ein neues benutzerdefiniertes Modul, das ausschließlich die benötigten Daten protokolliert.
Ankündigung von NGINX Plus R16
NGINX Plus R16 ist eine einheitliche, elastische Ingress- und Egress-Schicht für Anwendungen, die die Funktionen eines Load Balancers, API-Gateways und einer WAF vereint und neue Features wie clusterfähige Ratenbegrenzung, Schlüssel-Wert-Speicher, „Random with Two Choices“, verbessertes UDP-Load-Balancing und vieles mehr bietet.
5 Gründe für den Umstieg auf softwarebasiertes Load Balancing
Entdecken Sie fünf Gründe für den Wechsel zu einem softwarebasierten Load Balancer wie NGINX Plus, darunter Kosteneinsparungen, die Einführung von DevOps und eine einheitliche Lösung für alle Umgebungen.