Rancher 2x und Let's Encrypt

Update (November 2019): Seit dem 1. November 2019 können Zertifikate von Let’s Encrypt nur noch mit dem cert-manager > 0.8.x getätigt werden. Daher ist die aktuelle Version von diesem Artikel obsolet, da die hier erwähnte Installation nur die Version 0.5.2 beinhaltet. Rancher hat dazu kein Helm-Chart-Update rausgegeben. Aktuell schreibe ich einen Artikel, wie man diesen Misstand umgehen kann. Anschließend werde ich diesen Artikel aktualisieren.

Dieser Artikel – Rancher 2x und Let’s Encrypt – wurde aus „Kubernetes einfach mit Rancher: Cluster (Part-4)” ausgelagert, damit in beiden Beiträgen die Übersicht und leichte Lesbarkeit bewahrt bleibt.

Wer alle Artikel in der Serie Kubernetes einfach mit Rancher gelesen hat, kann übrigens weiterlesen. Alle anderen sei empfohlen, die anderen Artikel zuerst abzuarbeiten.

Ziel ist es, sowohl das manuelle als auch das automatisierte Anfragen und Erstellen eines Let’s-Encrypt-Zertifikats für unseren Cluster bereitzustellen.

Prerequisites / Voraussetzungen

• Eigene Domain
• Fähigkeiten einen DNS-Eintrag zu erstellen und auf das Cluster zu zeigen
• Rancher Kubernetes Cluster (den sollten wir haben)

Für das Beispiel in Rancher 2x und Let’s Encrypt habe ich eine Subdomain erstellt und auf meinen Cluster gezeigt.

Cert-Manager

Wir stellen den Cert-Manager über ein Helm-Chart bereit. Dafür wechseln wir in das „system”-Projekt und wählen „Apps” aus der Navigation.

Nachdem wir auf „Launch” geklickt haben, öffnet sich die Katalog-Ansicht. An dieser Stelle müssen wir rechts oben den Namen des Helm-Charts eingeben, beispielsweise „cert”.

Nun sollten wir die cert-manager Chart aus dem Standard-Katalog wählen. Wir klicken auf „View Details” und gelangen dadurch in die Bereitstellungsmaske.

Die vorgesehene cert-manager-Instanz muss als „Default Cluster Issuer” deklariert werden. Darüber hinaus sollte der „letsencrypt-prod”-Client ausgewählt werden – ansonsten müssten wir diese Schritte wiederholen.

Die erstellten Zertifikate werden mit einer E-Mail-Adresse registriert, daher sollte der pflichtbewusste Benutzer hier seine tatsächliche Adresse eintragen.

Durch Klicken auf „Launch” beginnt die Bereitstellung.

Sobald die Bereitstellung durch ist, können wir den cert-manager einsetzen.

Rancher cert-manager: Einfaches Beispiel

Soweit so gut, nun folgt ein einfaches Beispiel zur Veranschaulichung. Wir erstellen einen einfachen Workload, danach lassen wir Ingress – quasi eine Veröffentlichung – automatisch ein Zertifikat von Let’s Encrypt anfordern.

Rancher Workload

Für Tests verwende ich das „Labs”-Projekt, dadurch bleiben die anderen Projekte sauber. Für dieses Beispiel in Rancher 2x und Let’s Encrypt verwende ich Labs, womit das Beispiel komplett durchgeführt wird. Unter Workloads klicken wir nun auf „Deploy”.

Infolgedessen gelangen wir auf die „Deploy Workload”-Ansicht. Name sowie Namespace können frei gewählt werden, unter „Docker Image” geben wir nun den Image-Namen inklusive Tag an – in unserem Fall nginx:alpine.

Zusätzlich müssen wir nun ein Port-Mapping hinzufügen – Port 80/TCP → Cluster IP. Durch Klicken auf „Launch” wird unser Workload (1 Pod und 1 Service) bereitgestellt.

Rancher Ingress

Jetzt folgt der spannende Teil: die Erstellung eines Ingress-Eintrags. Dafür wechseln wir zu dem „Load Balancing”-Tab und klicken auf „Add Ingress”. In der neuen Maske geben wir nun die benötigten Informationen ein.

Name und Namespace können frei gewählt werden, wohingegen unter „Rules” „Specify a hostname to use” ausgewählt und mit der vorgesehenen Domain gesetzt werden sollte – in meinem Fall ssltest.ak8s.de.

Der vorgefüllte Target-Backend-Eintrag muss gelöscht werden, da dieser auf einen Workload zeigt, wir aber den Service referenzieren möchten.

Anschließend klicken wir auf „+Service” und verweisen den Root-Pfad auf den Service mit dem Port 80 und klicken anschließend auf „Save”.

Leider sind wir noch nicht fertig. Mit dem Speichern werden nun die Standard-Annotations und Labels für unser Ingress gesetzt. Wir hätten die natürlich auch selber setzen können, aber dann hätten wir das ganze Beispiel auch in YAML gestalten können.

Nach der erfolgreichen Ingress-Bereitstellung sollte beim Aufruf der URL – in meinem Fall http://ssltest.ak8s.de – die Standard-Begrüßungsseite von Nginx erwarten. Bis jetzt nur über HTTP. Wir wollen stattdessen SSL, also HTTPS. Dafür müssen wir unseren Ingress bearbeiten und die benötigten Annotations hinzufügen und mit „Save” diese anwenden:

• kubernetes.io/tls-acme: "true"
• certmanager.k8s.io/cluster-issuer: letsencrypt-prod

Finale Steps

Jetzt folgt aber der letzte Schritt. Wir müssen das YAML von unserem Ingress bearbeiten. Dafür klicken wir in der Load-Balancer-Ansicht auf die drei Punkte und wählen „Edit YAML” aus.

Für das Zertifikat benötigt Rancher einen Namen, welcher unter „Resources → Certificates” abgelegt wird. Weshalb wir unser YAML anpassen müssen.

Direkt unter tls.hosts erstellen wir eine neue Zeile und setzen einen Eintrag (in meinem Fall secretName: ssltest-ak8s-de-crt). Das erstellte Zertifikat wird mit diesem Namen unter Certificates abgelegt werden.

Sofern alles fehlerfrei durchlief, können wir unsere Seite nun per HTTPS aufrufen.

Diese ganze Prozedur kann man sich natürlich sparen, indem man auf YAML-Dateien setzt. In der Regel kann mit den meisten Helm-Charts die Konfiguration mitgegeben werden. Dieses Beispiel ist insofern interessant, dass man es zumindest einmal selber an der Oberfläche getätigt hat.