So sichern Sie Consul mit TLS-Verschlüsselung unter Ubuntu 14.04

Consul ist ein Diensterkennungstool, mit dem Sie auf einfache Weise den Zustand verschiedener Dienste in Ihrer gesamten Infrastruktur erkennen und verfolgen können. Mit consul können Sie Ihre Dienste verwalten und ein verteiltes Überprüfungssystem verwalten, um sicherzustellen, dass Sie reagieren können, wenn Anwendungen oder Server ausfallen.

Im last guide haben wir uns darauf konzentriert, eine Produktion zu erstellen -bereite Umgebung und fertig. Dies beinhaltete das Erstellen von Konfigurationsdateien, die beim Booten gelesen wurden, und das Starten von Skripts, um die Dienste tatsächlich zu initiieren.

Dies führte uns zum größten Teil zu unserer endgültigen Basiskonfiguration, aber wir haben unsere Konfiguration noch nicht vollständig gesichert. Wir haben eine einfache gemeinsame geheime Lösung implementiert, die unser Klatschprotokoll sehr einfach verschlüsselt.

Die RPC-Kommunikation ist zu diesem Zeitpunkt jedoch noch vollständig unverschlüsselt. Um dieses Problem zu lösen, unterstützt Consul native TLS-Verschlüsselung, auf die wir uns in diesem Handbuch konzentrieren werden. Um dies zu implementieren, müssen wir eine Zertifizierungsstelle erstellen und Schlüssel signieren und an unsere Knoten verteilen.

Bevor Sie dieses Handbuch fertigstellen, sollten Sie ein System von Consul-Servern einrichten, wie wir es in unserem letzten Handbuch unter https://www.digitalocean.com/community/tutorials/how-to-configure-consul-in-a angegeben haben -production-environment-on-ubuntu-14-04 [einrichtung einer produktionsfertigen consul-infrastruktur].

Die Server, die wir für dieses Handbuch hatten, hatten die folgenden Eigenschaften:

Dies sind 64-Bit-Ubuntu 14.04-Server. Bitte beachten Sie, dass sich jeder dieser Server in derselben Domain befindet. Dies ist wichtig für die Konfiguration, die wir in diesem Handbuch implementieren, da wir ein Platzhalterzertifikat verwenden, das für jeden der Hosts in der Domäne geeignet ist.

In diesem Handbuch konzentrieren wir uns auf die Erstellung einer TLS-Zertifizierungsstelle, um Zertifikate für jeden unserer Server zu signieren. Auf diese Weise können die Konsul-Komponenten Identitäten überprüfen und den Datenverkehr verschlüsseln. Wir werden dann die Konfigurationsdateien leicht modifizieren, um unsere Knoten zu zwingen, den Datenverkehr zu verschlüsseln.

Zunächst richten wir einige grundlegende Dateien und Verzeichnisse ein, mit denen wir unsere Schlüssel verwalten.

Auch hier werden wir alle Verfahren in diesem Handbuch in einer Root-Shell ausführen. Melden Sie sich entweder als root an oder verwenden Sie "+ sudo -i +" als Benutzer mit sudo-Berechtigungen.

Erstellen Sie auf jedem Ihrer Konsul-Mitglieder ein Verzeichnis "+ ssl " im Verzeichnis " / etc / consul.d +". Hier speichern wir die erforderlichen Dateien für die Verschlüsselung des RPC-Verkehrs:

Auf dem Server, den Sie als Zertifizierungsstelle verwenden möchten, erstellen wir ein Unterverzeichnis in diesem Verzeichnis, in dem alle zum Erstellen und Signieren der Zertifikate erforderlichen Dateien gespeichert werden. Wir können jeden unserer Server auswählen, auf dem sich die Zertifizierungsstelle befindet. Für unsere Zwecke verwenden wir jedoch "+ server1 +", auf dem sich auch die Bootstrap-Konfiguration befindet.

Erstellen Sie auf diesem Server ein Unterverzeichnis mit dem Namen "+ CA +" unter dem soeben erstellten Verzeichnis:

Dies wird einige vertrauliche Daten enthalten, auf die andere Personen wahrscheinlich nicht zugreifen sollen. Lassen Sie uns also die Berechtigungen sperren:

Verschieben Sie in dieses Verzeichnis auf dem CA-Server.

Hier erstellen wir einige grundlegende Dateien, die für unsere Zertifikatsignierung vorhanden sein müssen. Zuerst müssen wir eine Datei erstellen, die mit der nächsten verfügbaren Seriennummer für Zertifikate inkrementiert wird. Wir müssen dies mit einem Wert voreinstellen.

Geben Sie dazu den Wert "+ 000a +" in die serielle Datei ein:

Wir müssen auch eine Datei bereitstellen, in der unsere Zertifizierungsstelle die von ihr signierten Zertifikate aufzeichnen kann. Wir werden diese Datei "+ certindex +" nennen:

Um mit unserer Zertifizierungsstelle zu beginnen, müssen wir zunächst ein selbstsigniertes Stammzertifikat erstellen. Wir können das mit dem Befehl + openssl + machen, der standardmäßig auf Ubuntu-Rechnern installiert ist.

Der Befehl, den wir zum Erstellen des Zertifikats verwenden, lautet:

Lassen Sie uns noch einmal überlegen, was dies bedeutet:

Während der Zertifikaterstellung werden Sie aufgefordert, Informationen zu dem Host einzugeben, den Sie zertifizieren. Sie können dies mit allen relevanten Informationen ausfüllen, die Sie über den Server wünschen:

Für den "+ Common Name +", der in unserem anderen Zertifikat wichtig sein wird, können Sie angeben, was Sie möchten.

Wenn Sie fertig sind, sollten Sie eine "+ ca.cert " - Zertifikatsdatei sowie einen zugehörigen Schlüssel mit dem Namen " privkey.pem +" haben.

Nachdem wir das Stammzertifizierungsstellenzertifikat haben, können wir eine Zertifikatsignierungsanforderung für unsere Clientcomputer generieren.

In diesem Fall sind alle unsere Konsul-Mitglieder Kunden, einschließlich des Servers, auf dem wir gerade arbeiten. Anstatt für jeden Server ein eindeutiges Zertifikat zu generieren und es bei unserer Zertifizierungsstelle zu signieren, erstellen wir ein Platzhalterzertifikat, das für jeden der Hosts in unserer Domäne gültig ist.

Das allgemeine Format des Befehls ist mit ein paar kleinen Unterschieden identisch:

Der Unterschied zwischen der selbstsignierten Zertifikatanforderung der Stammzertifizierungsstelle, die wir erstellt haben, und der neuen Zertifikatsignierungsanforderung, die wir gerade generieren, ist folgender:

Auch hier werden wir zur Beantwortung der Certificate Signing Request (CSR) aufgefordert. Dies ist wichtiger als die Antworten, die wir für das selbstsignierte Stammzertifizierungsstellenzertifikat angegeben haben. Hier müssen wir einen Platzhalter "+ Common Name" verwenden, damit Ihr Zertifikat für jeden unserer Hosts als gültig gilt:

Wie Sie hier sehen können, haben wir unsere Domain mit einem Stern als Host verwendet, um anzuzeigen, dass das Zertifikat für jeden Host innerhalb der Domain als gültig angesehen werden soll. Sie können das Abfragekennwort und die optionalen Eingabeaufforderungen für Firmennamen, die am Ende hinzugefügt werden, problemlos überspringen.

Jetzt haben wir unsere selbstsignierte Stammzertifizierungsstellendatei und eine Platzhalterzertifizierungsanforderung, die allen Hosts in unserer Domain entspricht. Bevor wir die Signaturanforderung mit unserem CA-Zertifikat signieren können, müssen wir eine Konfigurationsdatei erstellen, die steuert, wie dies geschieht.

Wir rufen die Datei auf, die wir erstellen: "+ myca.conf +", die unsere CA-Informationen enthält. Öffnen Sie diese Datei jetzt:

Diese Datei verwendet ein INI-Format, das in Abschnitte unterteilt ist. Der erste Abschnitt, den wir definieren werden, ist der Abschnitt "+ ca +". Das einzige, was wir hier tun werden, ist auf unseren benutzerdefinierten Abschnitt mit den tatsächlichen CA-Informationen zu verweisen:

Als Nächstes erstellen wir den Abschnitt, auf den wir gerade verwiesen haben. Dies enthält den Großteil der CA-Konfigurationsdetails.

Wir werden angeben, dass die in die Sicherheitsabfragen eingegebenen Informationen nicht eindeutig sein müssen. Anschließend geben wir den Speicherort aller von uns erstellten Dateien an, die für den Signaturprozess benötigt werden. Wir werden + openssl + anweisen, neue Zertifikate im aktuellen Verzeichnis abzulegen.

Wir möchten auch einige Standardeinstellungen auswählen, die verwendet werden sollen, wenn in der Befehlszeile keine Alternativen angegeben sind. Wir werden die signierten Zertifikate 10 Jahre lang als gültig auswählen und den Algorithmus + sha1 + verwenden. Abschließend verweisen wir auf einige zusätzliche Abschnitte, die wir erstellen, um zusätzliche Informationen zu definieren:

Konzentrieren wir uns nun auf den ersten benutzerdefinierten Abschnitt, auf den wir gerade verwiesen haben, in dem entschieden wird, welche Informationen bereitgestellt werden müssen, damit der CSR akzeptiert wird. Einige Felder werden als erforderlich und andere als optional gekennzeichnet. Wir werden einige ziemlich standardmäßige Entscheidungen für die üblichen Eingabeaufforderungen treffen:

Im letzten Abschnitt werden die x509-Erweiterungen definiert, die beim Signieren von Zertifikaten verwendet werden sollen.

Zunächst müssen wir darauf hinweisen, dass es sich bei dem zu signierenden Zertifikat nicht um ein CA-Zertifikat handelt. Wir werden den Standardwert von "Hash" für die Subjektschlüsselkennung verwenden, da hexadezimale Zeichenfolgen (die Alternative) dringend davon abgeraten werden.

Wir setzen die Kennung des Berechtigungsschlüssels auf "keyid", um die Kennung des Betreffschlüssels aus dem übergeordneten Zertifikat zu kopieren. Wir werden auch festlegen, dass die Schlüssel als Signatur oder mit einem Protokoll zum Verschlüsseln von Schlüsseln verwendet werden können. Wir werden angeben, dass die erweiterte Verwendung der Schlüssel für die Server- und Clientauthentifizierung erfolgen kann:

Insgesamt sieht die Datei ungefähr so ​​aus:

Speichern und schließen Sie die Datei, wenn Sie fertig sind. Wir haben jetzt eine umfangreiche Konfigurationsdatei, die zum Signieren der zuvor generierten Zertifikatsignierungsanforderung verwendet werden kann.

Jetzt verfügen wir über alle Komponenten, die zum Signieren der CSR und zum Generieren eines Zertifikats erforderlich sind. Wir müssen nur auf die Konfigurationsdatei verweisen, die wir gerade erstellt haben, und die CSR übergeben, die wir generiert haben.

Der Befehl, den wir verwenden werden, ist:

Wir verwenden folgende Optionen:

Die restlichen Optionen geben die Eingabe- und Ausgabedateien an.

Dadurch wird eine Datei mit dem Namen "+ consul.cert " im aktuellen Verzeichnis erstellt. Außerdem werden neue Versionen der Dateien " serial " und " certindex " erstellt, wobei die alten Versionen in Sicherungsdateien verschoben werden. Eine ` .pem ` Datei wird ebenfalls basierend auf der Seriennummer in der ` serial +` Datei erstellt.

Jetzt haben wir alle benötigten Komponenten im Verzeichnis "+ / etc / consul.d / ssl / CA ". Wir wollen die drei benötigten Dateien in das Verzeichnis " / etc / consul.d / ssl +" kopieren, wo wir sie referenzieren:

Unser "+ server1 +" - Rechner, auf dem sich die Zertifizierungsstelle befindet, verfügt nun über die erforderlichen Zertifikats- und Schlüsseldateien am richtigen Speicherort.

Um sie auf die anderen Computer in Ihrer Infrastruktur zu übertragen, ist "+ scp " eine gute Wahl. Aus dem Verzeichnis " / etc / consul.d / ssl " auf " server1 +" können Sie die erforderlichen Dateien auf die anderen Server übertragen, indem Sie Folgendes eingeben:

Ändern Sie die IP-Adressen, um auf alle Computer in Ihrer Infrastruktur zu verweisen.

Nachdem wir nun unsere Stammzertifikatsdatei und ein Zertifikat / Schlüssel-Paar für unsere Konsul-Mitglieder haben, können wir unsere Konsul-Konfigurationsdateien so ändern, dass sie auf diese Dateien verweisen.

Öffnen Sie jede der consul-Konfigurationsdateien auf Ihren Servern. Für unsere + server1 + Maschine beginnen wir mit der Bootstrap-Konfigurationsdatei:

Die Datei sollte momentan so aussehen:

Als erstes sollten wir die consul-Parameter verwenden, um jede unserer neuen Dateien zu identifizieren. Der Parameter "+ ca_file " verweist auf den Speicherort der CA-Zertifikatdatei. Die Parameter " cert_file " und " key_file +" verweisen auf die Zertifikats- bzw. Schlüsseldateien des Clients.

Da dies auch mit der Verschlüsselung zu tun hat, werden wir sie aus Gründen der Übersichtlichkeit unter dem Parameter "+ encrypt +" einfügen:

Jetzt haben wir die Speicherorte dieser Dateien definiert, aber wir haben consul nicht mitgeteilt, dass wir die Authentizität jedes Hosts anhand dieser Dateien überprüfen möchten. Wir können das jetzt tun, indem wir den Konsul auffordern, sowohl eingehende als auch ausgehende Verbindungen zu überprüfen:

Speichern und schließen Sie die Datei, wenn Sie fertig sind.

Nehmen Sie die gleichen Änderungen an allen Konfigurationsdateien vor, die Ihre Konsul-Mitglieder verwenden.

Auf "+ server1 " müssen Sie diese Änderungen an " /etc/consul.d/bootstrap/config.json" und "+ /etc/consul.d/server/config.json +" vornehmen.

Auf Ihren anderen Servern müssen Sie lediglich "+ / etc / consul.d / server / config.json " ändern. Auf Ihren Client-Rechnern müssten Sie ` / etc / consul.d / client / config.json +` ändern.

Um unseren verschlüsselten Datenverkehr zu implementieren, müssen Sie die Konsulsitzung für jedes Ihrer Konsul-Mitglieder neu starten.

Halten Sie auf jedem Computer in Ihrer Infrastruktur kurz an und starten Sie consul erneut:

Dies stoppt den Prozess und startet ihn vorübergehend neu.

Wenn Sie dies bei jedem Ihrer Konsul-Mitglieder nacheinander tun, verwenden diese SSL, um den RPC-Verkehr zwischen ihnen zu verschlüsseln. Wenn nur einige von ihnen umgeschaltet werden, können kurzzeitig Kommunikationsprobleme auftreten, da ein Teil des Datenverkehrs als nicht verschlüsselt zurückgewiesen wird.

Wenn alle Mitglieder neu gestartet werden, sollte der RPC-Verkehr vollständig verschlüsselt sein.

Zu diesem Zeitpunkt sollten Sie ein ziemlich sicheres Service-Discovery-System für Ihre Infrastruktur eingerichtet haben. Wir haben alle systemeigenen Sicherheitssysteme genutzt, die mit consul verfügbar sind, um den Zugriff zu sperren und das Fälschen unserer verschiedenen Maschinen zu verhindern.