Update (November 2019): Seit dem 1. November 2019 können Zertifikate von lets 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, es wird höchst wahrscheinlich auch keins geben. Aktuell schreibe ich einen Artikel wie man diesen Misstand umgehen kann. Anschließend werde ich diesen Artikel aktualisieren.
Dieser Artikel Rancher 2x und Lets 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 es empfohlen, die anderen Artikel soweit abzuarbeiten.
Ziel ist es sowohl das manuelle als auch das automatisierte – z.B. über das deployment – Anfragen und Erstellen eines Let´s Encrypt Zertifikats für unseren Cluster bereitzustellen.
Prerequirements / 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 Lets 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 dadurch gelangen wir 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 Email 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 an der Oberfläche danach lassen wir ingress – quasi eine Veröffentlichung – automatisch ein Zertifikat von Let´s Encrypt anfordern.
Rancher Workload
Für Tests verwende ich das lab Projekt dadurch bleiben die anderen Projekte sauber. Für dieses – Beispiel in Rancher 2x und Lets 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 nun 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 jedenfalls 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 3 Punkte und wählen Edit yaml aus.
Für das Zertifikat benötigt Rancher einen Namen – welcher unter Ressources->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.
[…] Dieses Kapitel liegt nun als eigener Artikel vor, so dass weiterhin die Lesbarkeit und der Lesefluss weiter besteht. Ansonsten war dieser Artikel einfach viel zu lang. […]
[…] bis hier alle vorhergehenden 5 Teile gelesen und umgesetzt haben. Wir brauchen einen RKE Cluster, Let´s Encrypt Cert Manager, Storage und Lust 🙂 […]