SSL/TLS für Kubernetes Ingress einrichten

Web- und Mobilanwendungen sowie API-basierte Microservice-Endpunkte sind heute der Standard. Diese Anwendungen sind über das HTTP-Webprotokoll erreichbar. Die Verschlüsselung durch Secure Sockets Layer oder Transport Layer Security (SSL/TLS) ist unverzichtbar, um die Kommunikation zwischen Client und Server sowie über API-Back-Ends hinweg zu schützen.

SSL/TLS sind zertifikatsbasierte Verschlüsselungsverfahren. SSL ist seit über 20 Jahren Standard. TLS ist eine sicherere Weiterentwicklung von SSL, die auf demselben Konzept basiert, aber strengere Verschlüsselungsverfahren nutzt.

TLS-Zertifikate können von einer internen Zertifizierungsstelle einer Organisation selbstsigniert oder von einer der vielen öffentlichen Zertifizierungsstellen ausgestellt werden, etwa von GoDaddy, DigiCert, Symantec, GlobalSign und Let’s Encrypt. Bei verschlüsselter IP-basierter Kommunikation ist der Datenverkehr vor Angreifern geschützt, die Datenpakete abfangen.

In einer Kubernetes-Umgebung laufen Workload-Container innerhalb des Kubernetes-Netzwerks. Üblicherweise werden sie über einen HTTP-basierten Ingress-Controller für die Außenwelt (das Internet) zugänglich gemacht – einen API-basierten Dienst, der den Datenverkehr an die PODs weiterleitet. Um die Sicherheit in diesem Szenario zu gewährleisten, sollten wir eine SSL/TLS-basierte Verschlüsselung für den Kubernetes-Cluster konfigurieren.

Bei jedem typischen Szenario mit Datenaustausch – zum Beispiel beim Senden von Benutzername und Passwort zur Authentifizierung oder beim Abrufen vertraulicher Daten wie Zugriffsschlüsseln für Anwendungs- und Speicherendpunkte, Datenbankverbindungszeichenfolgen und Ähnlichem – bietet Verschlüsselung stets einen Sicherheitsgewinn.

Dieser Artikel zeigt, wie Sie TLS/SSL-Zertifikate mit dem Ingress-Controller in Kubernetes konfigurieren. Wir richten einen NGINX Ingress-Controller ein, erstellen ein selbstsigniertes SSL/TLS-Zertifikat, legen die erforderlichen Regeln fest, um das Zertifikat mit dem Controller zu verknüpfen, und verbinden ihn mit einem Kubernetes-Beispielanwendungsdienst.

TLS/SSL-Zertifikate konfigurieren

Stellen Sie zunächst sicher, dass Kubernetes auf Ihrem lokalen Computer (z. B. Docker mit Kubernetes oder MiniKube) oder in einer gehosteten Cloud-Umgebung wie Azure (AKS), AWS (EKS), GCP (GKS) oder Ocean (DOKS) läuft und Helm installiert ist.

Für diese Demonstration verwenden wir eine standardmäßige Azure Kubernetes Service-Bereitstellung, wie in diesem Microsoft Learn-Artikel gezeigt, und ein kostenloses Azure-Abonnement. Die meisten Schritte sind jedoch Kubernetes-spezifisch und nicht an eine bestimmte Cloud gebunden. Sie können daher unabhängig von Ihrer Kubernetes-Hosting-Umgebung mitmachen.

Den Ingress-Controller erstellen

Beginnen wir damit, die Konfiguration des Ingress-Controllers in den Kubernetes-Cluster einzuspielen. Dafür gibt es mehrere Optionen, darunter NGINX, Googles Cloud Load Balancer, Traefik und Contour. In diesem Artikel verwenden wir NGINX, einen bekannten Ingress-Controller, dessen Einrichtung nicht allzu komplex ist. Er wird von der Kubernetes-Community ingress-nginx auf GitHub bereitgestellt.  

Neben den verschiedenen Ingress-Controllern gibt es auch mehrere Möglichkeiten, sie einzurichten, etwa mit Helm oder kubectl. Für diese Demonstration verwenden wir Helm, da es mit jeder Kubernetes-Architektur funktioniert.

Die Bereitstellung umfasst die folgenden Schritte:

• Den Namen eines neuen Kubernetes-Namespace festlegen, der vom Ingress-Controller verwendet wird. Dafür dient die Variable NAMESPACE.

• Das Paket des ingress-nginx-Controllers mit dem Befehl helm repo add herunterladen.

• Die Konfiguration mit helm repo update aktualisieren.

• Das Paket mit dem Befehl helm install installieren.

Da dieses Beispiel Azure und den Azure Load Balancer verwendet, wird der Befehl helm install um die Integration mit den Health-Probes des Azure Load Balancers ergänzt. Diese Konfiguration unterscheidet sich je nach Kubernetes-Umgebung (On-Premises, Azure, AWS, GCP usw.).

Führen Sie in der Befehlszeile Folgendes aus:

1NAMESPACE=ingress-nginx
2
3helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
4helm repo update
5
6helm install ingress-nginx ingress-nginx/ingress-nginx \
7  --create-namespace \
8  --namespace $NAMESPACE \
9  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

Die folgende Abbildung zeigt den vollständigen helm-Befehl:

Die Ausgabe beim Erstellen des NGINX-Controllers sieht etwa so aus wie in der folgenden Abbildung:

Überprüfen Sie anschließend mit dem folgenden Befehl, ob der Ingress-Controller installiert wurde:

1kubectl --namespace ingress-nginx get services -o wide -w ingress-nginx-controller

Die folgende Abbildung zeigt die Ausgabe des obigen Befehls.

Rufen Sie in Ihrem Browser die für ingress-nginxcontroller angegebene EXTERNAL-IP auf. Ingress-Regeln haben wir noch nicht festgelegt, da der Datenverkehr noch nicht an einen tatsächlichen Anwendungsdienst weitergeleitet wird. Daher wird ein HTTP-Fehler 404 angezeigt. Sie sehen jedoch, dass der NGINX-Controller reagiert.

Beachten Sie, dass die externe IP-Adresse auf einem Mac möglicherweise als localhost statt als IP-Nummer angezeigt wird.

Wenn Sie auf die Meldung Nicht sicher klicken, sehen Sie, dass kein Zertifikat verwendet wird:

Rufen Sie nun dieselbe IP-Adresse erneut auf, diesmal mit HTTPS. Daraufhin wird im Browser eine Warnung angezeigt, dass die Verbindung nicht sicher ist, wie unten dargestellt:

Klicken Sie auf die Schaltfläche Erweitert und anschließend auf Weiter zu .

Klicken Sie im selben Tab Nicht sicher auf das Zertifikatssymbol, das unten hervorgehoben ist:

Daraufhin werden die Details des integrierten Fake-Zertifikats des Ingress-Controllers angezeigt, wie unten dargestellt. Dieses Zertifikat werden wir ersetzen.

Ein SSL/TLS-Zertifikat auswählen

SSL/TLS-Zertifikate können auf verschiedene Arten bezogen werden:

• Selbstsigniert: Dieser Zertifikatstyp wird üblicherweise intern verwendet und basiert auf der eigenen PKI-Zertifizierungsstelle (Public Key Infrastructure, CA).

• Von einer öffentlichen Zertifizierungsstelle bezogen: Dieser Typ wird typischerweise für Anwendungen verwendet, die über das öffentliche Internet erreichbar sind. Unternehmen kaufen SSL/TLS-Zertifikate bei einer öffentlichen Zertifizierungsstelle wie GlobalSign, Symantec, DigiCert oder GoDaddy. Der größte Vorteil einer öffentlichen CA ist, dass moderne Browser den Stammzertifikaten vertrauen, mit denen alle ausgestellten Zertifikate validiert werden. Zertifikate sind üblicherweise ein bis fünf Jahre gültig.

• Let’s Encrypt: Let’s Encrypt ist ein gemeinnütziges Projekt. Der wichtigste Unterschied zu öffentlichen CAs ist, dass SSL/TLS-Zertifikate bei Let’s Encrypt kostenlos sind. Außerdem sind Let’s-Encrypt-Zertifikate nur drei Monate gültig.

Zusätzlich zum SSL/TLS-Zertifikatstyp müssen wir Wartungsaufgaben wie den regelmäßigen Austausch von Zertifikaten und Schlüsseln berücksichtigen. Für den in diesem Artikel beschriebenen Kubernetes- und Ingress-Controller-Anwendungsfall kommen geplante Aufgaben zum Erstellen neuer SSL/TLS-Zertifikate und Cronjobs auf Ihrem Kubernetes-Cluster zum Anlegen neuer Secrets infrage. Wichtig ist auch, eine passende Gültigkeitsdauer für Zertifikate Ihrer öffentlichen CA oder von Let’s Encrypt zu wählen.

Ein weiterer Aspekt der SSL/TLS-Verschlüsselung und -Sicherheit ist die Entscheidung, ob die Verschlüsselung auf Ebene des Ingress-Controllers, des Pods oder der Anwendung oder auf beiden Ebenen erfolgen soll. Jedes Szenario hat Vor- und Nachteile. Auf Ingress-Ebene können Sie alle eingehenden Ingress-Anfragen direkt mit den Kubernetes-Back-End-Diensten verknüpfen.

Wenn SSL/TLS-Zertifikate im laufenden Pod oder in der Anwendung gespeichert werden, erhöht das deren Komplexität. Es kann jedoch geschäftliche Gründe dafür geben, zusätzlich zum internetseitigen verschlüsselten Datenverkehr gemäß der Controller-Konfiguration auch die Verschlüsselung des Datenverkehrs zwischen Ingress-Controller und Pod oder Anwendung sicherzustellen.Für diese Demonstration erstellen wir ein selbstsigniertes Zertifikat. Die Schritte sind für die beiden anderen Optionen jedoch ähnlich.

Führen Sie auf einem Mac oder Linux-Computer oder in der Shell einer Cloud-Plattform (hier Cloud Shell) den folgenden openssl-Befehl aus:

1mkdir certs
2
3openssl req -x509 -nodes -days 9999 -newkey rsa:2048 -keyout certs/ingress-tls.key -out certs/ingress-tls.crt

Die folgende Abbildung zeigt die Ausgabe des obigen Befehls.

Geben Sie die Organisationsinformationen ein, die in die Zertifikatsanforderung aufgenommen werden sollen, zum Beispiel den Organisationsnamen, den Ländercode, den Standort und die E-Mail-Adresse. In dieser Demonstration wird www.ingress-tls.com als vollqualifizierter Domänenname (FQDN) des Zertifikats verwendet.

Dadurch werden die Zertifikatsdatei (CRT-extension) und die Datei mit dem privaten Zertifikatsschlüssel (KEY-extension) im Ordner \certs erstellt.

Das Kubernetes-Secret erstellen

Als Nächstes müssen wir das Zertifikat und den Schlüssel mit einem Kubernetes-Secret verknüpfen. Führen Sie dazu den folgenden Befehl aus:

1kubectl create secret tls ingress-cert --namespace dev --key=certs/ingress-tls.key --cert=certs/ingress-tls.crt -o yaml

Das Secret selbst lässt sich mit kubectl get secret abrufen. Die Ausgabe sieht etwa so aus wie in der folgenden Abbildung:

Eine neue Beispielanwendung im Ingress-Namespace veröffentlichen

Erstellen Sie als Nächstes eine neue Datei sample-app.yaml mit der folgenden Syntax (achten Sie auf die Einrückung in YAML):

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: sample-app
5  namespace: default
6spec:
7  selector:
8    matchLabels:
9      app: sample
10  replicas: 2
11  template:
12    metadata:
13      labels:
14        app: sample
15    spec:
16      containers:
17      - name: sample
18        image: "gcr.io/google-samples/hello-app:2.0"
19
20---
21
22apiVersion: v1
23kind: Service
24metadata:
25  name: sample-app-service
26  namespace: default
27  labels:
28    app: sample
29spec:
30  type: ClusterIP
31  selector:
32    app: sample
33  ports:
34  - port: 80
35    targetPort: 8080
36    protocol: TCP

Dadurch werden ein neuer Dienst und eine Beispielanwendung (mit dem Google-Beispielcontainer-Image hello-app) im bereits vorhandenen Namespace ingress-nginx erstellt. Beachten Sie, dass der Code das SSL/TLS-Secret diesem Namespace zuweist. Sie können es daher nur für Anwendungen und Dienste verwenden, die darin ausgeführt werden.

Spielen Sie die Konfiguration anschließend mit dem folgenden Befehl in den Kubernetes-Cluster ein:

1kubectl apply -f sample-app.yaml:

Die SSL/TLS-Integration zwischen Ingress-Controller und Beispielanwendung erstellen

Erstellen Sie abschließend eine weitere Datei mit dem Namen sample-ingress.yaml und deklarieren Sie die Ingress-Ressource mit den folgenden SSL/TLS-Konfigurationsparametern:

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: sample-app-ingress
5  namespace: default
6spec:
7  ingressClassName: nginx
8  tls:
9  - hosts:
10    - www.ingress-tls.com
11    secretName: ingress-cert
12  rules:
13  - host: "www.ingress-tls.com"
14    http:
15      paths:
16        - pathType: Prefix
17          path: "/"
18          backend:
19            service:
20              name: sample-app-service
21              port:
22                number: 80

Im obigen Beispiel wenden die folgenden Parameter SSL/TLS an und verknüpfen es mit dem Secret:

1tls:
2  - hosts:
3    - www.ingress-tls.com
4    secretName: ingress-cert
5  rules:
6  - host: "www.ingress-tls.com"

Im Abschnitt „paths“ am Ende der Datei wird festgelegt, dass alle eingehenden Anfragen an den Host an den im vorherigen Schritt erstellten Dienst sample-app-service (die Google-Containeranwendung hello-app) weitergeleitet werden.

Führen Sie den Befehl kubectl erneut aus, um die Konfiguration in den Kubernetes-Cluster einzuspielen:

1kubectl apply -f sample-app-ingress.yaml

Um die Verbindung zum FQDN zu testen, aktualisieren Sie die DNS-Hosts-Datei auf Ihrem lokalen Computer (auf einem Mac oder Linux-Computer normalerweise /etc/hosts, unter Windows C:\Windows\System32\Drivers\Etc\Hosts). Tragen Sie dort die Zuordnung der IP-Adresse des Ingress-Controllers zum verwendeten FQDN ein.

Hinweis: Wenn Sie die lokale Hosts-Datei nicht aktualisieren möchten oder können, können Sie den DNS-Resolver https://nip.io verwenden. Der Name unseres Ingress-Controllers würde beispielsweise zu 20.245.164.52.nip.io aufgelöst. Diese Adresse verweist auf die IP-Adresse des Controllers 20.245.164.52.

Öffnen Sie den Browser und rufen Sie den FQDN auf, den Sie für das Zertifikat verwendet haben (in unserem Beispiel www.ingress-tls.com oder 20.245.164.52.nip.io). Beachten Sie, dass die Warnung „Nicht sicher“ weiterhin angezeigt wird, da der Browser dem selbstsignierten Zertifikat nicht vertraut. Klicken Sie auf Erweitert und anschließend auf Weiter, um die Anwendungs-URL zu öffnen:

Wie Sie sehen, funktioniert die Beispielanwendung (links die Begrüßung „Hello, world!“) erwartungsgemäß mit dem zuvor erstellten selbstsignierten SSL/TLS-Zertifikat.

Weitere Informationen finden Sie im Tool CNCF Cert Manager. Es bietet eine fortschrittlichere Möglichkeit, Zertifikate zu verwalten und Secrets automatisch zu erstellen.

Verschiedene Ingress-Anbieter im Vergleich

In dieser Anleitung haben wir den beliebten NGINX Ingress-Controller verwendet – doch es gibt viele weitere Controller. Wenn Sie gerade erst mit Kubernetes anfangen, ist das Open-Source-Projekt NGINX eine unkomplizierte Lösung, um den Datenverkehr zu verteilen und Ihre Cluster-Workloads zu schützen. NGINX bietet auch eine stärker auf Unternehmen ausgerichtete Version namens NGINX Plus. Alternativ können Sie Kong verwenden, eine weitere kommerzielle Alternative, die auf demselben Code wie NGINX basiert. Traefik ist eine weitere kommerzielle Lösung mit umfassender Protokollunterstützung, hoher Verfügbarkeit und weiteren Funktionen. 

Jede Lösung, für die wir uns entscheiden, interagiert mit der Kubernetes Ingress API. Anfang dieses Jahres hat Kubernetes jedoch die Beta-Version der Gateway API veröffentlicht. Sie könnte eine interessante Alternative zur aktuellen Ingress API werden, insbesondere aufgrund ihrer granularen rollenbasierten Zugriffskontrollfunktionen. Neben der Unterstützung mehrerer Standardprotokolle wie HTTP und TCP/UDP bietet die Gateway API den bedeutenden Vorteil, dass sie auch integrierte TLS-Unterstützung bieten wird.

Da sich die Gateway API noch in einem frühen Entwicklungsstadium befindet (derzeit in der Beta), ist es zu früh, um abzusehen, wie sich die Ingress API und die Gateway API künftig zueinander verhalten werden. Die Gateway API, die als Nachfolgerin der Ingress API gedacht war, könnte mehr Funktionen bieten, als lediglich die der Ingress API nachzubilden. Wie andere Anbieter und Erweiterungen sich darauf einstellen werden, ist derzeit jedoch noch unklar. Die gute Nachricht ist: Sicherheit hat höchste Priorität, und TLS wird standardmäßig für das Routing eingesetzt.

Fazit

Überall dort, wo Kubernetes-Workloads und -Dienste als internetfähige Anwendungen bereitgestellt werden, kommen Ingress-Controller zum Einsatz. Neben der Reverse-Proxy-Funktionalität empfiehlt es sich dringend, SSL/TLS-Zertifikate in Ihre Ingress-Architektur zu integrieren. So wird der Datenverkehr zwischen dem Client (Browser) und dem Server (Kubernetes-Service-Anwendung) verschlüsselt. Kubernetes unterstützt verschiedene Ingress-Anbieter und akzeptiert unterschiedliche SSL/TLS-Zertifikate als Secrets. Weitere Best Practices finden Sie in unserem Kubernetes-Sicherheitsleitfaden.

Mit standardmäßigen Kubernetes-Verwaltungsbefehlen wie Helm und kubectl sollte die Integration von SSL/TLS nicht komplizierter sein als das Bereitstellen eines Kubernetes-Dienstes. Sehen Sie sich auch unseren Leitfaden zur Implementierung von TLS/SSL in Python an.

Die Kommunikation zwischen der Außenwelt und Ihren Anwendungen mithilfe von SSL/TLS-Zertifikaten abzusichern, ist nur ein Schritt hin zu sichereren Anwendungen: Sie müssen auch alle Phasen des Softwareentwicklungslebenszyklus absichern. Erkennen und beheben Sie potenzielle Schwachstellen im Code, den Sie schreiben, und in den Open-Source-Projekten, die Sie verwenden – mit Snyk Code und Snyk Open Source. Mit Snyk Container schaffen Sie eine sicherere Basis mit einem sicheren Basis-Image und erkennen zusätzliche Schwachstellen, die möglicherweise während des Build-Prozesses eingeführt werden. Prüfen Sie schließlich mit Snyk IaC, ob der von Ihnen bereitgestellte Code keine Sicherheitslücken enthält.