Wie kann ich das Kubernetes Dashboard per HTTPS absichern?
- Zugriffswege und Sicherheitsüberlegungen
- Absicherung direkt über kubectl proxy oder Port-Forwarding (lokaler Zugriff)
- Absicherung über einen Ingress Controller mit TLS
- Selbstsigniertes Zertifikat für das Dashboard verwenden
- Beispiel: HTTPS mit Ingress Controller (NGINX) und Lets Encrypt
- Zusammenfassung
Das Kubernetes Dashboard ist ein webbasierter UI-Controller, der oftmals innerhalb eines Kubernetes-Clusters eingesetzt wird, um Ressourcen zu verwalten und den Clusterzustand zu überwachen. Standardmäßig ist das Dashboard jedoch nicht per HTTPS abgesichert, wenn man direkt darauf zugreift. Um das Dashboard sicher über HTTPS zu verwenden, gibt es verschiedene Ansätze, bei denen Zertifikate verwendet und der Traffic verschlüsselt wird.
Zugriffswege und Sicherheitsüberlegungen
Normalerweise läuft das Dashboard innerhalb des Clusters ohne HTTPS, da der Zugang über kubectl proxy oder einen Ingress Controller erfolgt. Für einen produktiven oder externen Zugriff empfiehlt es sich jedoch, HTTPS zu verwenden, damit die Verbindung verschlüsselt und gegen Man-in-the-Middle-Angriffe geschützt ist. Zudem soll der Zugang nach Möglichkeit über Authentifizierung und Autorisierung abgesichert werden.
Absicherung direkt über kubectl proxy oder Port-Forwarding (lokaler Zugriff)
Wenn Sie lokal das Dashboard betrachten, kann kubectl proxy verwendet werden, welches standardmäßig HTTP nutzt, aber nur lokal erreichbar ist. Für HTTPS können Sie einen lokalen Reverse-Proxy wie nginx oder Caddy einrichten, der das Dashboard über HTTPS mit einem selbstsignierten oder öffentlichen Zertifikat bereitstellt. So wird der Zugriff vom Browser zum Proxy verschlüsselt. Diese Lösung ist jedoch eher für den lokalen Zugang sinnvoll und nicht für externe Zugriffe geeignet.
Absicherung über einen Ingress Controller mit TLS
Für den Zugriff auf das Dashboard von außen ist eine Absicherung über einen Ingress Controller oft die beste Wahl. Dabei wird ein Ingress-Objekt im Cluster erstellt, das den Dashboard-Service exponiert und gleichzeitig TLS-Termination übernimmt. Beispielsweise kann man NGINX Ingress Controller, Traefik oder andere verwenden, die TLS-Zertifikate (etwa von Lets Encrypt oder selbstsignierte) nutzen.
Dazu erstellen Sie zunächst ein TLS-Secret mit Ihrem Zertifikat und Schlüssel, das dann in der Ingress-Definition referenziert wird. Das Ingress-Objekt konfiguriert dann HTTPS auf Ihrem Dashboard-Endpunkt, pusht den Traffic verschlüsselt und leitet ihn intern zum Dashboard-Service weiter.
Selbstsigniertes Zertifikat für das Dashboard verwenden
Alternativ zum Ingress können Sie auch direkt im Dashboard Deployment ein selbstsigniertes Zertifikat einbringen. Dazu erstellen Sie ein TLS-Secret im Namespace kubernetes-dashboard mit Zertifikat und privatem Schlüssel. Anschließend passen Sie die Deployment-Konfiguration an, um das Zertifikat bereitzustellen und die Dashboard-Pods so zu konfigurieren, dass sie HTTPS unterstützen. Dies ist allerdings etwas aufwendiger und weniger flexibel für Änderungen. Zudem benötigt Ihr Browser eine Ausnahme für das selbstsignierte Zertifikat.
Beispiel: HTTPS mit Ingress Controller (NGINX) und Lets Encrypt
Ein gängiger Weg ist folgender: Zuerst installieren Sie den NGINX Ingress Controller im Cluster (z.B. mit Helm). Danach erstellen Sie ein ClusterIssuer oder Issuer-Objekt mit cert-manager, um automatisch Zertifikate von Lets Encrypt zu erhalten. Anschließend legen Sie ein Ingress-Manifest an, das auf das Dashboard verweist und die TLS-Konfiguration mit dem Zertifikat des Issuers nutzt.
So kann das Dashboard über HTTPS unter einer von Ihnen definierten Domain (z. B. dashboard.example.com) erreichbar sein, mit validem und automatisiert erneuertem Zertifikat. Wichtig ist dabei, dass der Ingress nur für zugelassene Benutzer erreichbar ist, etwa über Firewalls, Authentifizierung wie OAuth2-Proxy oder andere Mechanismen, weil das Dashboard sonst potenziell kritische Clusterinformationen preisgeben kann.
Zusammenfassung
Das Kubernetes Dashboard per HTTPS abzusichern bedeutet im Wesentlichen, den Zugriff über verschlüsselte HTTP-Verbindungen bereitzustellen. Für lokale Zugriffe sind Reverse-Proxies mit TLS oder kubectl proxy in Kombination mit lokalen HTTPS-Proxys sinnvoll. Für externe Zugriffe ist der Einsatz eines Ingress Controllers mit TLS-Zertifikaten der Standardweg. Dabei nutzt man zumeist automatisierte Zertifikatsverwaltung über Tools wie cert-manager. Alternativ können auch selbstsignierte Zertifikate verwendet werden, wenn man die Zertifikate in den Browser importiert oder Ausnahmen akzeptiert. Wichtig ist aber stets, den Zugriff zusätzlich ausreichend zu authentifizieren und zu autorisieren, da das Dashboard umfangreiche administrative Rechte am Cluster hat.