Erfahrt, wie ihr die Let’s-Encrypt-Erfahrung hinter der Firewall nutzen und Zertifikate mit einem DevOps-Ansatz verwalten könnt. Jetzt gibt es keine Ausreden mehr, eure Webanwendungen außerhalb der Produktion über unverschlüsseltes HTTP zu betreiben!
Timothy Harris
An American living in Denmark. Tim used to work for Eficode. He has more than 20 years of experience in development, operations, continuous integration, and delivery.
Das Problem
Für Webanwendungen ist die Kommunikation über SSL/HTTPS ein Muss. Einfach gesagt: Unverschlüsselter HTTP-Datenverkehr ist ein Sicherheitsrisiko.
Das ist nichts Neues, und es ist schwer, einen öffentlichen Webservice in Produktion zu finden, der nicht mit SSL abgesichert ist. Bei Nicht-Produktionsumgebungen sieht es allerdings ganz anders aus.
Als DevOps-Berater habe ich aufgehört zu zählen, wie oft ich Nicht-Produktions-, Entwicklungs-, Test-, QA- und Staging-Umgebungen gesehen habe, die über reines HTTP laufen. Generell denke ich, dass die Hauptgründe dafür folgende sind:
Diese Umgebungen befinden sich oft hinter einer Firewall und sind nicht für die Außenwelt zugänglich. Daher sehen Entwickler meist keine Notwendigkeit, ein Zertifikat zu beschaffen, da sie sich in einem Intranet/LAN sicher fühlen.
Die Beschaffung und Erneuerung eines Zertifikats ist oft zeitaufwendig, wenn Let’s Encrypt nicht genutzt werden kann.
Der Prozess ist oft manuell oder in einer anderen Organisation zentralisiert, was nicht zu Entwicklungsprozessen passt, die von CI/CD gesteuert werden.
Fragt einen beliebigen Sicherheitsexperten: Er wird euch sagen, dass solche Netzwerke ständig kompromittiert werden und unverschlüsselter Datenverkehr angreifbar ist. Dieses Sicherheitsgefühl ist trügerisch.
Entwicklungsteams, die CI/CD einsetzen, arbeiten schnell – Release-Zyklen sind häufig, sowohl für bestehende als auch für neue Auslieferungen. Auf die Erstellung eines Zertifikats zu warten, ist daher keine Option. Der neue Service wird in den internen Umgebungen bereitgestellt – nur eben nicht mit SSL/HTTPS.
Bei CI/CD ist der Deployment-Prozess automatisiert. Dass automatisierte Deployments und Tests auf die Erneuerung eines Zertifikats warten und dadurch fehlschlagen, ist keine Option.
Die Lösung
Der beste Weg, sicherzustellen, dass jeder Webservice über HTTPS mit einem gültigen Zertifikat läuft, ist, den Prozess so einfach wie möglich zu gestalten – durch Automatisierung. Wenn ihr einen Webservice bereitstellt, sollte es einfach passieren. Ein DevOps-Ansatz ist automatisiert und wiederholbar.
Let’s Encrypt hat dies für öffentliche Webservices mit dem Protokoll Automated Certificate Management Environment (ACME) ermöglicht.
Bei nicht öffentlichen Nicht-Produktionsumgebungen hilft das jedoch kaum. Um Let’s Encrypt zu nutzen, müsst ihr die Firewall an einer Stelle öffnen. Ein typisches Beispiel könnte wie im folgenden Diagramm aussehen:
Dafür müsst ihr:
die DNS-01-Challenge verwenden.
einen DNS-Anbieter haben, der das ACME-Protokoll unterstützt.
die Domain veröffentlicht haben, auch wenn sie nicht erreichbar ist.
über einen Mechanismus zur Verteilung der Zertifikate verfügen.
eine Öffnung in der Firewall haben.
Diese Lösung ist aus mehreren offensichtlichen Gründen nicht optimal.
Zum Glück bietet Smallstep eine Zertifizierungsstelle (CA), die das ACME-Protokoll unterstützt. Sie ist Open Source, schlank und bietet mehrere Möglichkeiten, Zertifikate bereitzustellen und zu verwalten.
Die Smallstep CA wurde für DevOps und moderne Systeme entwickelt. Sie kann als Container verpackt, auf einem K8's-Cluster ausgeführt und mit Provisioning-Tools wie Chef, Ansible, Puppet usw. automatisiert werden. So könnt ihr die Let’s-Encrypt-Erfahrung nutzen und Zertifikate automatisiert verwalten.
Ein Diagramm dieser Lösung könnte etwa so aussehen:
Die HTTP-01-Challenge ist einfacher.
Es ist nicht nötig, einen DNS-Anbieter einzubinden.
Es ist nicht nötig, die Firewall zu öffnen.
Es ist nicht nötig, Domains zu veröffentlichen.
Ihr müsst keinen Mechanismus zur Verteilung der Zertifikate implementieren und warten, da es viele vorhandene ACME-Clients gibt, die ihr nutzen könnt. Dazu gehören beispielsweise Traefik, ACME.sh, Certbot und die CLI von Smallstep.
Viele Unternehmen verwenden und verteilen bereits intern signierte Zertifikate. Mit der Smallstep CA könnt ihr die Root-Zertifikate importieren.
Das ist eine deutlich sauberere Lösung.
Die Demo
Ich habe ein Repository mit einer einfachen Demo-Implementierung erstellt, die die CA von Smallstep mit der Lösung hinter der Firewall verwendet.
Ich habe die CA containerisiert und eine docker-compose-Datei erstellt, um sie einfach zu starten. Ein Entrypoint-Skript initialisiert die CA mit einigen in einer .env-Datei definierten Werten.
Anschließend habe ich zwei Proxys (Nginx und Traefik) containerisiert und docker-compose-Dateien erstellt, um die Ausstellung und Erneuerung von Zertifikaten für einen einfachen „Hello World!“-Webservice zu demonstrieren.
Ich habe Traefik gewählt, weil es ACME nativ unterstützt. Ihr müsst nur die Compose-Datei mit den richtigen Werten konfigurieren (CA, Challenge-Typ usw.), und Traefik übernimmt alles – einschließlich der Zertifikatserneuerung.
Ich habe Nginx gewählt, weil es ACME nicht nativ unterstützt. Stattdessen habe ich die CLI von Smallstep, die die Ausstellung und Erneuerung von Zertifikaten unterstützt, in das Nginx-Image integriert und ein Entrypoint-Skript erstellt, das das Zertifikat ausstellt und den Erneuerungs-Daemon startet. Die Nginx-Konfiguration verweist lediglich auf die Zertifikate, die der Smallstep-ACME-Client ausstellt und erneuert.
Um es auszuprobieren, klont das Repository und folgt der Anleitung für den Schnellstart. Der grundlegende Ablauf sieht jedoch wie folgt aus:
Tragt einige Umgebungsvariablen in die .env-Datei ein.
Aktualisiert eure Host-Datei.
Startet den CA-Container, ruft den Fingerprint ab und fügt ihn zur Datei .env hinzu.
Fügt das von der CA beim Starten des Containers generierte Root-Zertifikat zum Zertifikatsspeicher eures Hosts hinzu. Normalerweise würde dies von ITOPs übernommen.
Startet Traefik oder Nginx, um die Zertifikatausstellung zu sehen.
Hier ist ein Screencast, der das Setup demonstriert. Er zeigt das Starten der Zertifizierungsstelle, das Hinzufügen der generierten Root- und Intermediate-Zertifikate zum Zertifikatsspeicher des Hosts sowie das Starten von Traefik und Nginx, um einen einfachen „Hello World!“-Webservice als Proxy bereitzustellen.
Dabei gibt es einige Punkte zu beachten:
Beim Starten des CA-Containers wird dieser im Entrypoint initialisiert, und die Root- sowie Intermediate-Zertifikate werden generiert.
Die CA von Smallstep unterstützt mehrere Arten von Provisionern, wobei JWK der Standardtyp ist. Der Entrypoint fügt jedoch einen ACME-Provisioner hinzu, da wir diesen verwenden möchten.
Sowohl das Traefik- als auch das Nginx-Image enthalten die CLI von Smallstep integriert. Die CA verarbeitet Datenverkehr über HTTPS. Daher müssen die Client-Container die Root- und Intermediate-Zertifikate in ihrem Zertifikatsspeicher haben. Die CLI übernimmt dies im Entrypoint des Containers.
Ich verwende die CLI von Smallstep lokal, um die Zertifikate zum Zertifikatsspeicher meines Computers hinzuzufügen. Sie packt sie für mich in eine .pem-Datei, sodass ich das nicht manuell erledigen muss.
Die Container verwenden Umgebungsvariablen für die Konfiguration. Das ist nicht wirklich
sicher, und für alles außer einer Demo sollte ein dateibasierter Ansatz verwendet werden.
Zusammenfassung
Die Demo zeigt, dass sich die Verwaltung von SSL-Zertifikaten automatisieren lässt, wenn Let’s Encrypt aufgrund von Firewall-Einschränkungen nicht genutzt werden kann.
In der Praxis sollte das Operations-Team die Certificate Authority (CA) verantworten und verwalten. Es ist ohnehin dafür zuständig, die Root- und Zwischenzertifikate an die benötigten Hosts im Netzwerk zu verteilen.
Dieser Blog befasst sich ebenfalls nicht mit der Verwaltung der CA selbst, sondern damit, wie man sie nutzt, um Entwicklungsteams ein Let’s-Encrypt-ähnliches Erlebnis zu bieten.
Ich möchte Operations-Teams ermutigen, mit den Experten von Smallstep darüber zu sprechen, was sich noch mit der CA umsetzen lässt, und sich eingehender mit deren Verwaltung zu befassen. Eine solche Lösung unterstützt den DevOps-Ansatz, Barrieren zwischen Entwicklung und Operations abzubauen – und, darf ich es sagen, sogar DevSecOps?
Die Vorteile aus Sicht von Entwicklung, Operations und Sicherheit liegen auf der Hand:
Standardmäßig verschlüsselter Datenverkehr für Webservices. Die Sicherheit freut sich :-)
Automatisierte Verwaltung von SSL-Zertifikaten und keine manuellen Prozesse mehr für die Zertifikatverwaltung. Operations freut sich :-)
Stabilere Umgebungen, die der Produktion ähnlicher sind und mit dem Tempo der Entwicklung Schritt halten. Die Entwicklung freut sich :-)
- DevOps
- Cloud
Subscribe to our newsletter
Related blogs
