One place for hosting & domains

      Einrichten

      Einrichten und Konfigurieren einer Certificate Authority (CA) unter Debian 10


      Einführung

      Eine Zertifizierungsstelle (Certificate Authority, CA) ist eine Stelle, die für die Ausstellung digitaler Zertifikate zur Überprüfung von Identitäten im Internet verantwortlich ist. Obwohl öffentliche CAs eine beliebte Wahl für die Überprüfung der Identität von Websites und anderen Diensten sind, die der allgemeinen Öffentlichkeit zur Verfügung gestellt werden, werden private CAs normalerweise für geschlossene Gruppen und private Dienste verwendet.

      Die Erstellung einer privaten Zertifizierungsstelle ermöglicht es Ihnen, Programme zu konfigurieren, zu testen und auszuführen, die verschlüsselte Verbindungen zwischen einem Client und einem Server erfordern. Mit einer privaten CA können Sie Zertifikate für Benutzer, Server oder einzelne Programme und Dienste innerhalb Ihrer Infrastruktur ausstellen.

      Einige Beispiele für Programme unter Linux, die ihre eigene private CA verwenden, sind OpenVPN und Puppet. Sie können Ihren Webserver auch so konfigurieren, dass er Zertifikate verwendet, die von einer privaten CA ausgestellt wurden, um Entwicklungs- und Staging-Umgebungen an Produktionsserver anzupassen, die TLS zur Verschlüsselung von Verbindungen verwenden.

      In diesem Leitfaden lernen wir, wie eine private Zertifizierungsstelle auf einem Debian 10-Server eingerichtet wird und wie mit einer neuen CA ein Testzertifikat erzeugt und signiert wird. Außerdem erfahren Sie, wie Sie das öffentliche Zertifikat des CA-Servers in den Zertifikatsspeicher Ihres Betriebssystems importieren, damit Sie die Vertrauenskette zwischen der CA und entfernten Servern oder Benutzern überprüfen können. Schließlich werden Sie lernen, wie Sie Zertifikate widerrufen und eine Zertifikatswiderrufsliste verteilen, um sicherzustellen, dass nur autorisierte Benutzer und Systeme Dienste nutzen können, die auf Ihrer CA beruhen.

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie Zugriff auf einen Debian 10-Server, der Ihren OpenVPN-Dienst hosten kann. Sie müssen einen non-root user mit sudo-Rechten konfigurieren, bevor Sie diesen Leitfaden starten können. Sie können unserem Leitfaden zur Ersteinrichtung eines Debian-10-Servers folgen, um einen Benutzer mit entsprechenden Berechtigungen einzurichten. Das verknüpfte Tutorial richtet auch eine Firewall ein, und in diesem Leitfaden wird davon ausgegangen, dass sie vorhanden ist.

      Dieser Server wird in diesem Tutorial als CA-Server bezeichnet.

      Stellen Sie sicher, dass der CA-Server ein eigenständiges System ist. Er wird nur zum Importieren, Signieren und Widerrufen von Zertifikatanforderungen verwendet. Auf ihm sollten keine anderen Dienste ausgeführt werden, und idealerweise ist er offline oder wird vollständig heruntergefahren, wenn Sie nicht aktiv mit Ihrer CA arbeiten.

      Anmerkung: Der letzte Abschnitt dieses Tutorials ist optional, wenn Sie über das Signieren und Widerrufen von Zertifikaten lernen möchten. Wenn Sie sich entscheiden, diese Übungsschritte durchzuführen, benötigen Sie einen zweiten Debian-10-Server oder Sie können Ihren eigenen lokalen Linux-Computer verwenden, auf dem Debian oder Ubuntu oder davon abgeleitete Distributionen ausgeführt werden.

      Schritt 1 — Installieren von Easy-RSA

      Die erste Aufgabe in diesem Tutorial besteht darin, den Skriptsatz easy-rsa auf Ihrem CA-Server zu installieren. easy-rsa ist ein Verwaltungswerkzeug für Zertifizierungsstellen, mit dem Sie einen privaten Schlüssel und ein öffentliches Stammzertifikat erzeugen, die Sie dann zum Signieren von Anfragen von Clients und Servern verwenden, die auf Ihre CA angewiesen sind.

      Melden Sie sich bei Ihrem CA-Server als der non-root sudo user an, den Sie während der anfänglichen Einrichtungsschritte erstellt haben, und führen Sie Folgendes aus:

      • sudo apt update
      • sudo apt install easy-rsa

      Sie werden aufgefordert, das Paket herunterzuladen und zu installieren. Drücken Sie y, um zu bestätigen, dass Sie das Paket installieren möchten.

      An dieser Stelle haben Sie alles Nötige eingerichtet und sind bereit, Easy-RSA zu verwenden. Im nächsten Schritt werden Sie eine Public-Key-Infrastruktur erstellen und dann mit dem Erstellen Ihrer Zertifizierungsstelle beginnen.

      Schritt 2 – Vorbereiten eines Public-Key-Infrastrukturverzeichnisses

      Nachdem Sie nun easy-rsa installiert haben, ist es an der Zeit, eine grundlegende Public-Key-Infrastruktur (PKI) auf dem CA-Server zu erstellen. Stellen Sie sicher, dass Sie immer noch als non-root user angemeldet sind und erstellen Sie ein easy-rsa-Verzeichnis. Stellen Sie sicher, dass Sie sudo nicht verwenden, um einen der folgenden Befehle auszuführen, da Ihr normaler Benutzer die CA ohne erhöhte Berechtigungen verwalten und mit ihr interagieren sollte.

      Dadurch wird ein neues Verzeichnis namens easy-rsa in Ihrem Home-Ordner erstellt. Wir werden dieses Verzeichnis verwenden, um symbolische Links zu erstellen, die auf die easy-rsa-Paketdateien verweisen, die wir im vorigen Schritt installiert haben. Diese Dateien befinden sich im Ordner /usr/share/easy-rsa auf dem CA-Server.

      Erstellen Sie die Symlinks mit dem Befehl ln:

      • ln -s /usr/share/easy-rsa/* ~/easy-rsa/

      Anmerkung: Während andere Leitfäden Sie möglicherweise anweisen, die Dateien des easy-rsa-Pakets in Ihr PKI-Verzeichnis zu kopieren, verfolgt dieses Tutorial einen Symlink-Ansatz. Infolgedessen werden alle Aktualisierungen des easy-rsa-Pakets automatisch in den Skripten Ihrer PKI wiedergegeben.

      Um den Zugriff auf Ihr neues PKI-Verzeichnis einzuschränken, stellen Sie sicher, dass nur der Eigentümer mit dem Befehl chmod darauf zugreifen kann:

      • chmod 700 /home/sammy/easy-rsa

      Anschließend initialisieren Sie die PKI innerhalb des easy-rsa-Verzeichnisses:

      • cd ~/easy-rsa
      • ./easyrsa init-pki

      Output

      init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /home/sammy/easy-rsa/pki

      Nachdem Sie diesen Abschnitt abgeschlossen haben, haben Sie ein Verzeichnis, das alle Dateien enthält, die zur Erstellung einer Zertifizierungsstelle benötigt werden. Im nächsten Abschnitt werden Sie den privaten Schlüssel und das öffentliche Zertifikat für Ihre CA erstellen.

      Schritt 3 – Erstellen einer Zertifizierungsstelle

      Bevor Sie den privaten Schlüssel und das Zertifikat Ihrer CA erstellen können, müssen Sie eine Datei namens vars erstellen und mit einigen Standardwerten füllen. Zuerst werden Sie cd in das Verzeichnis easy-rsa, dann werden Sie die Datei vars mit nano oder Ihrem bevorzugten Texteditor erstellen und bearbeiten:

      Sobald die Datei geöffnet ist, fügen Sie die folgenden Zeilen ein und bearbeiten Sie jeden hervorgehobenen Wert so, dass er Ihre eigenen Organisationsinformationen widerspiegelt. Wichtig dabei ist, dass Sie keinen der Werte leer lassen:

      ~/easy-rsa/vars

      set_var EASYRSA_REQ_COUNTRY "US" set_var EASYRSA_REQ_PROVINCE "NewYork" set_var EASYRSA_REQ_CITY "New York City" set_var EASYRSA_REQ_ORG "DigitalOcean" set_var EASYRSA_REQ_EMAIL "[email protected]" set_var EASYRSA_REQ_OU "Community"

      Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, können Sie dies durch Drücken von STRG+X, dann Y und ENTER zur Bestätigung tun. Sie sind nun bereit, Ihre CA zu erstellen.

      Um das öffentliche und private Stammschlüsselpaar für Ihre Zertifizierungsstelle zu erstellen, führen Sie den Befehl ./easy-rsa erneut aus, diesmal mit der Option build-ca:

      In der Ausgabe sehen Sie einige Zeilen über die OpenSSL-Version und werden dazu aufgefordert, eine Passphrase für Ihr Schlüsselpaar einzugeben. Achten Sie darauf, eine starke Passphrase zu wählen, und notieren Sie sie an einem sicheren Ort. Sie müssen die Passphrase jedes Mal eingeben, wenn Sie mit Ihrer CA interagieren müssen, zum Beispiel zum Signieren oder Widerrufen eines Zertifikats.

      Sie werden auch gebeten, den Common Name (CN) für Ihre CA zu bestätigen. Der CN ist der Name, der verwendet wird, um im Kontext der Zertifizierungsstelle auf diesen Computer zu verweisen. Sie können eine beliebige Zeichenfolge für den Common Name der CA eingeben, aber drücken Sie der Einfachheit halber ENTER, um den Standardnamen zu akzeptieren.

      Output

      . . . Enter New CA Key Passphrase: Re-Enter New CA Key Passphrase: . . . Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /home/sammy/easy-rsa/pki/ca.crt

      Anmerkung: Wenn Sie nicht bei jeder Interaktion mit Ihrer CA zur Eingabe eines Passworts aufgefordert werden möchten, können Sie den Befehl build-ca mit der Option nopass wie folgt ausführen:

      • ./easyrsa build-ca nopass

      Sie haben nun zwei wichtige Dateien – ~/easy-rsa/pki/ca.crt und ~/easy-rsa/pki/private/ca.key – die die öffentlichen und privaten Komponenten einer Zertifizierungsstelle bilden.

      • ca.crt ist die öffentliche Zertifikatsdatei der CA. Benutzer, Server und Clients verwenden dieses Zertifikat, um zu überprüfen, ob sie Teil desselben vertrauenswürdigen Webs sind. Jeder Benutzer und Server, der Ihre CA verwendet, muss eine Kopie dieser Datei haben. Alle Parteien verlassen sich auf das öffentliche Zertifikat, um sicherzustellen, dass sich nicht jemand als System ausgibt und einen Man-in-the-middle-Angriff durchführt.

      • ca.key ist der private Schlüssel, den die CA zum Signieren von Zertifikaten für Server und Clients verwendet. Wenn ein Angreifer Zugriff auf Ihre CA und damit auf Ihre ca.key-Datei erhält, müssen Sie Ihre CA vernichten. Deshalb sollte sich Ihre Datei ca.key nur auf Ihrem CA-Computer befinden und Ihr CA-Computer im Idealfall als zusätzliche Sicherheitsmaßnahme offline bleiben, wenn keine Zertifikatanforderungen signiert werden.

      Damit ist Ihre CA vorhanden und bereit, zum Signieren von Zertifikatanforderungen und zum Widerrufen von Zertifikaten verwendet zu werden.

      Schritt 4 – Verteilen des öffentlichen Zertifikats Ihrer Zertifizierungsstelle

      Nun ist Ihre CA konfiguriert und bereit, als Vertrauensgrundlage für alle Systeme zu fungieren, die Sie für ihre Verwendung konfigurieren möchten. Sie können das Zertifikat der CA zu Ihren OpenVPN-Servern, Webservern, Mail-Servern usw. hinzufügen. Jeder Benutzer oder Server, der die Identität eines anderen Benutzers oder Servers in Ihrem Netzwerk überprüfen muss, sollte eine Kopie der Datei ca.crt haben, die in den Zertifikatsspeicher ihres Betriebssystems importiert ist.

      Um das öffentliche Zertifikat der CA in ein zweites Linux-System wie einen anderen Server oder einen lokalen Computer zu importieren, besorgen Sie sich zunächst eine Kopie der ca.crt-Datei von Ihrem CA-Server. Sie können den Befehl cat verwenden, um sie in einem Terminal auszugeben, und sie dann kopieren und in eine Datei auf dem zweiten Computer, der das Zertifikat importiert, einfügen. Sie können auch Tools wie scp, rsync verwenden, um die Datei zwischen Systemen zu übertragen. Wir werden in diesem Schritt jedoch Kopieren und Einfügen mit nano verwenden, da dies auf allen Systemen funktioniert.

      Führen Sie als non-root user auf dem CA-Server den folgenden Befehl aus:

      • cat ~/easy-rsa/pki/ca.crt

      Es wird eine Ausgabe in Ihrem Terminal geben, die der folgenden ähnelt:

      Output

      -----BEGIN CERTIFICATE----- MIIDSzCCAjOgAwIBAgIUcR9Crsv3FBEujrPZnZnU4nSb5TMwDQYJKoZIhvcNAQEL BQAwFjEUMBIGA1UEAwwLRWFzeS1SU0EgQ0EwHhcNMjAwMzE4MDMxNjI2WhcNMzAw . . . . . . -----END CERTIFICATE-----

      Kopieren Sie alles, einschließlich der Zeilen -----BEGIN CERTIFICATE----- und -----END CERTIFICATE----- und der Bindestriche.

      Verwenden Sie auf Ihrem zweiten Linux-System nano oder Ihren bevorzugten Texteditor, um eine Datei namens /tmp/ca.crt zu öffnen:

      Fügen Sie den Inhalt, den Sie gerade vom CA-Server kopiert haben, in den Editor ein. Wenn Sie dies abgeschlossen haben, speichern und schließen Sie die Datei. Wenn Sie nano verwenden, können Sie dies durch Drücken von STRG+X, dann Y und ENTER zur Bestätigung tun.

      Nachdem Sie nun eine Kopie der Datei ca.crt auf Ihrem zweiten Linux-System haben, ist es an der Zeit, das Zertifikat in den Zertifikatsspeicher des Betriebssystems zu importieren.

      Führen Sie auf Debian- und Ubuntu-basierten Systemen die folgenden Befehle aus, um das Zertifikat zu importieren:

      Debian and Ubuntu derived distributions

      • cp /tmp/ca.crt /usr/local/share/ca-certificates/
      • update-ca-certificates

      Um das Zertifikat des CA-Servers auf einem CentOS-, Fedora- oder RedHat-basierten System zu importieren, kopieren Sie den Inhalt der Datei und fügen Sie ihn wie im vorherigen Beispiel in das System in eine Datei namens /tmp/ca.crt ein. Kopieren Sie als Nächstes das Zertifikat nach /etc/pki/ca-trust/source/anchors/ und führen Sie dann den Befehl update-ca-trust aus.

      CentOS, Fedora, RedHat distributions

      • sudo cp /tmp/ca.crt /etc/pki/ca-trust/source/anchors/
      • update-ca-trust

      Nun wird Ihr zweites Linux-System auf jedes Zertifikat vertrauen, das vom CA-Server signiert wurde.

      Anmerkung: Wenn Sie Ihre CA mit Web-Servern verwenden und Firefox als Browser verwenden, müssen Sie das öffentliche Zertifikat ca.crt direkt in Firefox importieren. Firefox verwendet nicht den Zertifikatsspeicher des lokalen Betriebssystems. Einzelheiten dazu, wie Sie das Zertifikat Ihrer CA in Firefox hinzufügen können, finden Sie in diesem Support-Artikel von Mozilla über das Einrichten von Zertifizierungsstellen (CAs) in Firefox.

      Wenn Sie Ihre CA zur Integration in eine Windows-Umgebung oder in Desktop-Computer verwenden, lesen Sie bitte die Dokumentation über die Verwendung von certutil.exe zur Installation eines CA-Zertifikats.

      Wenn Sie dieses Tutorial als Voraussetzung für ein anderes Tutorial verwenden oder mit dem Signieren und Widerrufen von Zertifikaten vertraut sind, können Sie hier aufhören. Wenn Sie mehr zum Thema Signieren und Widerrufen von Zertifikaten erfahren möchten, dann wird im folgenden optionalen Abschnitt jeder Vorgang im Detail erklärt.

      (Optional) – Erstellen von Zertifikatsignieranforderungen und Widerrufen von Zertifikaten

      Die folgenden Abschnitte des Tutorials sind optional. Wenn Sie alle vorherigen Schritte abgeschlossen haben, verfügen Sie über eine vollständig konfigurierte und funktionierende Zertifizierungsstelle, die Sie als Voraussetzung für andere Tutorials verwenden können. Sie können die Datei ca.crt Ihrer CA importieren und Zertifikate in Ihrem Netzwerk überprüfen, die von Ihrer CA signiert wurde.

      Wenn Sie üben und mehr über das Signieren von Zertifikatanforderungen und das Widerrufen von Zertifikaten erfahren möchten, dann werden diese optionalen Abschnitte erklären, wie beide Prozesse funktionieren.

      (Optional) – Erstellen und Signieren einer Übungs-Zertifikatanforderung

      Nachdem Sie nun eine einsatzbereite CA haben, können Sie das Erzeugen eines privaten Schlüssels und einer Zertifikatanforderung üben, um sich mit dem Signier- und Verteilungsprozess vertraut zu machen.

      Eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) besteht aus drei Teilen: einem öffentlichen Schlüssel, dem Identifizieren von Informationen über das anfordernde System und einer Signatur der Anforderung selbst, die mit dem privaten Schlüssel der anfragenden Partei erstellt wird. Der private Schlüssel wird geheim gehalten und wird zum Verschlüsseln von Informationen verwendet, die jeder mit dem signierten öffentlichen Zertifikat dann entschlüsseln kann.

      Die folgenden Schritte werden auf Ihrem zweiten Linux-System Debian, Ubuntu oder einer Distribution, die von einem dieser Systeme abgeleitet ist, ausgeführt. Es kann sich um einen anderen Remote-Server oder einen lokalen Linux-Rechner wie einen Laptop oder einen Desktop-Rechner handeln. Da easy-rsa nicht standardmäßig auf allen Systemen verfügbar ist, verwenden wir das Tool openssl zum Erstellen eines privaten Übungsschlüssels und -zertifikats.

      openssl ist normalerweise standardmäßig auf den meisten Linux-Distributionen installiert, aber um sicherzugehen, führen Sie die folgenden Schritte auf Ihrem System aus:

      • sudo apt update
      • sudo apt install openssl

      Wenn Sie zur Installation von openssl aufgefordert werden, geben Sie y ein, um mit den Installationsschritten fortzufahren. Nun sind Sie bereit, eine Übungs-CSR mit openssl zu erstellen.

      Der erste Schritt, den Sie zum Erstellen einer CSR ausführen müssen, ist die Erzeugung eines privaten Schlüssels. Um einen privaten Schlüssel mit openssl zu erstellen, erstellen Sie ein Verzeichnis practice-csr und erzeugen Sie darin einen Schlüssel. Wir werden diese Anfrage für einen fiktiven Server namens sammy-server stellen, im Gegensatz zur Erstellung eines Zertifikats, das zur Identifizierung eines Benutzers oder einer anderen CA verwendet wird.

      • mkdir ~/practice-csr
      • cd ~/practice-csr
      • openssl genrsa -out sammy-server.key

      Output

      Generating RSA private key, 2048 bit long modulus (2 primes) . . . . . . e is 65537 (0x010001)

      Da Sie nun über einen privaten Schlüssel verfügen, können Sie eine entsprechende CSR erstellen, wiederum mit dem Dienstprogramm openssl. Sie werden aufgefordert, eine Reihe von Feldern wie Land, Bundesland und Stadt auszufüllen. Wenn Sie ein Feld leer lassen möchten, können Sie einen . eingeben. Beachten Sie jedoch, dass es am besten ist, die richtigen Werte für Ihren Standort und Ihre Organisation zu verwenden, wenn es sich um eine reale CSR handelt:

      • openssl req -new -key sammy-server.key -out sammy-server.req

      Output

      . . . ----- Country Name (2 letter code) [XX]:US State or Province Name (full name) []:New York Locality Name (eg, city) [Default City]:New York City Organization Name (eg, company) [Default Company Ltd]:DigitalOcean Organizational Unit Name (eg, section) []:Community Common Name (eg, your name or your server's hostname) []:sammy-server Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:

      Wenn Sie diese Werte automatisch als Teil des openssl-Aufrufs statt über die interaktive Eingabeaufforderung hinzufügen möchten, können Sie das Argument -subj an OpenSSL übergeben. Achten Sie darauf, die hervorgehobenen Werte so zu bearbeiten, dass sie mit dem Standort, der Organisation und dem Servernamen für die Übung übereinstimmen:

      • openssl req -new -key sammy-server.key -out server.req -subj
      • /C=US/ST=New York/L=New York City/O=DigitalOcean/OU=Community/CN=sammy-server

      Zur Überprüfung des Inhalts einer CSR können Sie eine Anforderungsdatei mit openssl einlesen und die darin enthaltenen Felder untersuchen:

      • openssl req -in sammy-server.req -noout -subject

      Output

      subject=C = US, ST = New York, L = New York City, O = DigitalOcean, OU = Community, CN = sammy-server

      Wenn Sie mit dem Thema Ihrer Übungs-Zertifikatanforderung zufrieden sind, kopieren Sie die Datei sammy-server.req mit scp auf Ihren CA-Server:

      • scp sammy-server.req sammy@your_ca_server_ip:/tmp/sammy-server.req

      In diesem Schritt haben Sie eine Zertifikatsignieranforderung für einen fiktiven Server namens sammy-server erzeugt. In einem realen Szenario könnte die Anfrage z. B. von einem Staging- oder Entwicklungs-Webserver kommen, der ein TLS-Zertifikat zum Testen benötigt; oder sie könnte von einem OpenVPN-Server kommen, der ein Zertifikat anfordert, damit sich Benutzer mit einem VPN verbinden können. Im nächsten Schritt fahren wir mit dem Signieren der Zertifikatsignieranforderung unter Verwendung des privaten Schlüssels des CA-Servers fort.

      (Optional) – Signieren einer CSR

      Im vorherigen Schritt haben Sie eine Übungs-Zertifikatanforderung und einen Übungsschlüssel für einen fiktiven Server erstellt. Sie kopierten sie in das Verzeichnis /tmp auf Ihrem CA-Server und emulierten damit das Verfahren, das Sie verwenden würden, wenn Sie echte Clients oder Server hätten, die Ihnen CSR-Anfragen senden würden, die signiert werden müssen.

      Um mit dem fiktiven Szenario fortzufahren, muss der CA-Server nun das Übungszertifikat importieren und signieren. Sobald eine Zertifikatanforderung von der CA validiert und an einen Server zurückgesendet wird, können Clients, die der Zertifizierungsstelle vertrauen, auch dem neu ausgestellten Zertifikat vertrauen.

      Da wir innerhalb der PKI der CA arbeiten werden, in der das Dienstprogramm easy-rsa verfügbar ist, werden die Signierungsschritte das Dienstprogramm easy-rsa verwenden. Dies vereinfacht die Dinge im Gegensatz zur direkten Verwendung von openssl, wie wir es im vorherigen Beispiel getan haben.

      Der erste Schritt zum Signieren der fiktiven CSR besteht darin, die Zertifikatanforderung mithilfe des Skripts easy-rsa zu importieren:

      • cd ~/easy-rsa
      • ./easyrsa import-req /tmp/sammy-server.req sammy-server

      Output

      . . . The request has been successfully imported with a short name of: sammy-server You may now use this name to perform signing operations on this request.

      Jetzt können Sie die Anfrage signieren, indem Sie das Skript easyrsa mit der Option sign-req ausführen, gefolgt vom Anfragetyp und dem Common Name, der in der CSR enthalten ist. Der Anfragetyp kann entweder Client, Server oder ca sein. Da wir mit einem Zertifikat für einen fiktiven Server üben, stellen Sie sicher, dass Sie den Anfragetyp Server verwenden:

      • ./easyrsa sign-req server sammy-server

      In der Ausgabe werden Sie zur Überprüfung aufgefordert, ob die Anfrage von einer vertrauenswürdigen Quelle stammt. Geben Sie yes ein, und drücken Sie dann zur Bestätigung ENTER:

      Output

      You are about to sign the following certificate. Please check over the details shown below for accuracy. Note that this request has not been cryptographically verified. Please be sure it came from a trusted source or that you have verified the request checksum with the sender. Request subject, to be signed as a server certificate for 3650 days: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Confirm request details: yes . . . Certificate created at: /home/sammy/easy-rsa/pki/issued/sammy-server.crt

      Wenn Sie Ihren CA-Schlüssel verschlüsselt haben, werden Sie an dieser Stelle zur Eingabe Ihres Passworts aufgefordert.

      Nach Abschluss dieser Schritte haben Sie die CSR sammy-server.req mit dem privaten Schlüssel des CA-Servers in /home/sammy/easy-rsa/pki/private/ca.key signiert. Die resultierende Datei sammy-server.crt enthält den öffentlichen Verschlüsselungsschlüssel des Übungsservers sowie eine neue Signatur des CA-Servers. Der Sinn der Signatur besteht darin, jedem, der der CA vertraut, mitzuteilen, dass auch dem sammy-server-Zertifikat vertraut werden kann.

      Wenn es sich bei dieser Anfrage um einen echten Server wie einen Web- oder VPN-Server handelt, würde der letzte Schritt auf dem CA-Server darin bestehen, die neuen Dateien sammy-server.crt und ca.crt vom CA-Server an den Remote-Server zu verteilen, der die CSR-Anfrage gestellt hat:

      • scp pki/issued/sammy-server.crt sammy@your_server_ip:/tmp
      • scp pki/ca.crt sammy@your_server_ip:/tmp

      Zu diesem Zeitpunkt könnten Sie das ausgestellte Zertifikat mit beispielsweise einem Webserver, einem VPN, einem Konfigurationsmanagement-Tool, einem Datenbanksystem oder für die Client-Authentifizierung verwenden.

      (Optional) – Widerrufen eines Zertifikats

      Gelegentlich kann es erforderlich sein, ein Zertifikat zu widerrufen, um zu verhindern, dass ein Benutzer oder Server es verwendet. Vielleicht wurde ein Laptop gestohlen, ein Webserver kompromittiert, oder ein Mitarbeiter oder ein Auftragnehmer hat Ihr Unternehmen verlassen.

      Zum Widerrufen eines Zertifikats folgt der allgemeine Vorgang diesen Schritten:

      1. Widerrufen Sie das Zertifikat mit dem Befehl ./easyrsa revoke client_name.
      2. Erzeugen Sie eine neue CRL mit dem Befehl ./easyrsa gen-crl.
      3. Übertragen Sie die aktualisierte Datei crl.pem auf den oder die Server, die sich auf Ihre CA verlassen, und kopieren Sie sie auf diesen Systemen in das oder die erforderlichen Verzeichnisse für Programme, die auf sie verweisen.
      4. Starten Sie alle Dienste, die Ihre CA und die CRL-Datei verwenden, neu.

      Mit diesem Vorgang können Sie alle Zertifikate, die Sie zuvor ausgestellt haben, jederzeit widerrufen. In den folgenden Abschnitten gehen wir jeden Schritt im Detail durch, beginnend mit dem Befehl revoke.

      Widerrufen eines Zertifikats

      Um ein Zertifikat zu widerrufen, navigieren Sie zum Verzeichnis easy-rsa auf Ihrem CA-Server:

      Führen Sie als Nächstes das Skript easyrsa mit der Option revoke aus, gefolgt von dem Client-Namen, den Sie widerrufen möchten. Dem obigen Übungsbeispiel folgend lautet der Common Name des Zertifikats sammy-server:

      • ./easyrsa revoke sammy-server

      Sie werden dazu aufgefordert, das Sperren durch Eingabe von yes zu bestätigen:

      Output

      Please confirm you wish to revoke the certificate with the following subject: subject= commonName = sammy-server Type the word 'yes' to continue, or any other input to abort. Continue with revocation: yes . . . Revoking Certificate 8348B3F146A765581946040D5C4D590A . . .

      Beachten Sie den hervorgehobenen Wert in der Zeile Revoking Certificate. Dieser Wert ist die eindeutige Seriennummer des Zertifikats, das widerrufen wird. Sie benötigen diesen Wert, wenn Sie die Widerrufsliste im letzten Schritt dieses Abschnitts prüfen möchten, um zu verifizieren, dass das Zertifikat darin enthalten ist.

      Nach der Bestätigung der Aktion wird die CA das Zertifikat widerrufen. Entfernte Systeme, die sich auf die CA verlassen, haben jedoch keine Möglichkeit zur Überprüfung, ob Zertifikate widerrufen wurden. Benutzer und Server können das Zertifikat weiterhin verwenden, bis die Zertifikatswiderrufsliste (Certificate Revocation List, CRL) der CA an alle Systeme verteilt wird, die sich auf die CA verlassen.

      Im nächsten Schritt erzeugen Sie eine CRL oder aktualisieren eine bestehende crl.pem-Datei.

      Erzeugen einer Zertifikatswiderrufsliste

      Nachdem Sie ein Zertifikat widerrufen haben, ist es jetzt wichtig, die Liste der widerrufenen Zertifikate auf Ihrem CA-Server zu aktualisieren. Sobald Sie über eine aktualisierte Widerrufsliste verfügen, können Sie feststellen, welche Benutzer und Systeme in Ihrer CA über gültige Zertifikate verfügen.

      Um eine CRL zu erzeugen, führen Sie den Befehl easy-rsa mit der Option gen-crl aus, während Sie sich noch im Verzeichnis ~/easy-rsa befinden:

      Wenn Sie bei der Erstellung Ihrer Datei ca.key eine Passphrase verwendet haben, werden Sie aufgefordert, diese einzugeben. Der Befehl gen-crl erzeugt eine Datei namens crl.pem, die die aktualisierte Liste der widerrufenen Zertifikate für diese CA enthält.

      Als Nächstes müssen Sie jedes Mal, wenn Sie den Befehl gen-crl ausführen, die aktualisierte Datei crl.pem an alle Server und Clients übertragen, die auf diese CA angewiesen sind. Andernfalls können die Clients und Systeme weiterhin auf Dienste und Systeme zugreifen, die Ihre CA verwenden, da diese Dienste über den widerrufenen Status des Zertifikats informiert sein müssen.

      Übertragen einer Zertifikatswiderrufsliste

      Nachdem Sie nun eine CRL auf Ihrem CA-Server erzeugt haben, müssen Sie sie an Remote-Systeme übertragen, die sich auf Ihre CA verlassen. Um diese Datei auf Ihre Server zu übertragen, können Sie den Befehl scp verwenden.

      Anmerkung: In diesem Tutorial wird erklärt, wie eine CRL manuell erzeugt und verteilt wird. Es gibt zwar robustere und automatisierte Methoden zur Verteilung und Überprüfung von Widerrufslisten wie OCSP-Stapling, aber die Konfiguration dieser Methoden sprengt den Rahmen dieses Artikels.

      Stellen Sie sicher, dass Sie bei Ihrem CA-Server als non-root user angemeldet sind, und führen Sie die folgenden Schritte aus, wobei Sie an Stelle von your_server_ip Ihre eigene Server-IP oder Ihren eigenen DNS-Namen eingeben:

      • scp ~/easy-rsa/pki/crl.pem sammy@your_server_ip:/tmp

      Da sich die Datei nun auf dem Remote-System befindet, besteht der letzte Schritt darin, alle Dienste mit der neuen Kopie der Widerrufsliste zu aktualisieren.

      Aktualisierung von Diensten, die eine CRL unterstützen

      Die Liste der Schritte, die Sie zur Aktualisierung von Diensten verwenden müssen, die die Datei crl.pem verwenden, geht über den Umfang dieses Tutorials hinaus. Im Allgemeinen müssen Sie die Datei crl.pem an den Speicherort kopieren, den der Dienst erwartet, und sie dann mit systemctl neu starten.

      Sobald Sie Ihre Dienste mit der neuen crl.pem-Datei aktualisiert haben, sind Ihre Dienste in der Lage, Verbindungen von Clients oder Servern abzulehnen, die ein widerrufenes Zertifikat verwenden.

      Überprüfen und Verifizieren der Inhalte einer CRL

      Wenn Sie eine CRL-Datei überprüfen möchten, z. B. um eine Liste widerrufener Zertifikate zu bestätigen, verwenden Sie den folgenden openssl-Befehl aus Ihrem easy-rsa-Verzeichnis auf Ihrem CA-Server:

      • cd ~/easy-rsa
      • openssl crl -in pki/crl.pem -noout -text

      Sie können diesen Befehl auch auf jedem Server oder System ausführen, auf dem das openssl-Tool mit einer Kopie der Datei crl.pem installiert ist. Wenn Sie beispielsweise die Datei crl.pem auf Ihr zweites System übertragen haben und überprüfen möchten, ob das Zertifikat sammy-server widerrufen wurde, können Sie einen openssl-Befehl wie den folgenden verwenden, wobei Sie die Seriennummer, die Sie zuvor beim Widerruf des Zertifikats notiert haben, an Stelle der hier markierten verwenden:

      • openssl crl -in /tmp/crl.pem -noout -text |grep -A 1 8348B3F146A765581946040D5C4D590A

      Output

      Serial Number: 8348B3F146A765581946040D5C4D590A Revocation Date: Apr 1 20:48:02 2020 GMT

      Beachten Sie, wie der Befehl grep verwendet wird, um die eindeutige Seriennummer zu überprüfen, die Sie im Widerrufsschritt notiert haben. Jetzt können Sie den Inhalt Ihrer Zertifikatswiderrufsliste auf jedem System überprüfen, das darauf angewiesen ist, den Zugriff auf Benutzer und Dienste einzuschränken.

      Zusammenfassung

      In diesem Tutorial haben Sie eine private Zertifizierungsstelle mit dem Easy-RSA-Paket auf einem eigenständigen Debian 10-Server erstellt. Sie haben gelernt, wie das Vertrauensmodell zwischen Parteien funktioniert, die sich auf die CA verlassen. Sie haben auch eine Zertifikatsignieranforderung (Certificate Signing Request, CSR) für einen Übungsserver erstellt und signiert und dann gelernt, wie man ein Zertifikat widerruft. Abschließend haben Sie erfahren, wie Sie eine Zertifikatwiderrufsliste (Certificate Revocation List, CRL) für jedes System erstellen und verteilen, das auf Ihre CA angewiesen ist, um sicherzustellen, dass Benutzer oder Server, die nicht auf Dienste zugreifen sollen, daran gehindert werden.

      Jetzt können Sie Zertifikate für Benutzer ausgeben und sie mit Diensten wie OpenVPN verwenden. Sie können Ihre CA auch verwenden, um Entwicklungs- und Staging-Webserver mit Zertifikaten zu konfigurieren, um Ihre Nicht-Produktionsumgebungen zu sichern. Die Verwendung einer CA mit TLS-Zertifikaten während der Entwicklung kann dazu beitragen, sicherzustellen, dass Ihr Code und Ihre Umgebungen so gut wie möglich zu Ihrer Produktionsumgebung passen.

      Wenn Sie mehr über die Verwendung von OpenSSL erfahren möchten, bietet unser Tutorial OpenSSL-Grundlagen: Arbeiten mit SSL-Zertifikaten, privaten Schlüsseln und CSRs viele zusätzliche Informationen, die Ihnen helfen, sich mit den OpenSSL-Grundlagen vertraut zu machen.



      Source link

      Einrichten eines Objektspeicherservers mit Minio unter Ubuntu 18.04


      Der Autor hat den Open Internet/Free Speech Fund dazu ausgewählt, eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Von cloudbasierten Backup-Lösungen bis zu Content Delivery Networks (CDNs) mit Hochverfügbarkeit ist die Möglichkeit, unstrukturierte Blobs von Objektdaten zu speichern und über HTTP-APIs zugänglich zu machen (auch als Objektspeicher bezeichnet), zu einem integralen Bestandteil der modernen Technologielandschaft geworden.

      Minio ist ein beliebter Open-Source-basierter Objektspeicherserver, der mit dem Amazon S3-Cloud-Speicherdienst kompatibel ist. Anwendungen, die so konfiguriert sind, dass sie mit Amazon S3 kommunizieren können, lassen sich auch so konfigurieren, dass Minio eine tragfähige Alternative zu S3 ist, wenn Sie mehr Kontrolle über Ihren Objektspeicherserver wünschen. Der Dienst speichert unstrukturierte Daten wie Fotos, Videos, Protokolldateien, Backups sowie Container/VM-Images und kann sogar einen einzelnen Objektspeicherserver bereitstellen, der mehrere, auf verschiedene Server verteilte Laufwerke in Pools zusammenfasst.

      Minio ist in Go geschrieben, bietet einen Befehlszeilenclient sowie eine Browseroberfläche und unterstützt einen einfachen Queuing-Dienst für Advanced Message Queuing Protocol (AMQP)-, Elasticsearch-, Redis-, NATS- und PostgreSQL-Ziele. Aus allen diesen Gründen kann das Erlernen der Einrichtung eines Minio-Objektspeicherservers die Flexibilität und Nützlichkeit Ihres Projekts deutlich erhöhen.

      In diesem Tutorial werden Sie folgende Aufgaben erledigen:

      • Installieren des Minio-Servers auf Ihrem Ubuntu 18.04-Server und Konfigurieren des Servers als systemd-Dienst

      • Einrichten eines SSL/TLS-Zertifikats mit Let’s Encrypt, um die Kommunikation zwischen Server und Client zu schützen

      • Zugreifen auf die Browseroberfläche von Minio über HTTPS zum Verwenden und Verwalten des Servers

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie:

      • Einen Ubuntu 18.04-Server, der gemäß unseres Tutorials zur Ersteinrichtung des Ubuntu 18.04-Servers eingerichtet wurde, einschließlich eines sudo non-root users und einer Firewall.

      • Ein vollständig registrierter Domänenamen. Sie können einen Domänennamen bei Namecheap kaufen bzw. kostenlos bei Freenom erhalten. In diesem Tutorial wird Ihre Domäne als your_domain dargestellt.

      • Richten Sie die folgenden DNS-Einträge für Ihren Minio-Server ein. Informationen zum Hinzufügen von DNS-Einträgen für ein DigitalOcean-Droplet finden Sie in unserer Dokumentation zu DNS-Einträgen.

        • Einen A-Eintrag mit Ihrem Servernamen (z. B. minio-server.your_domain), der auf die IPv4-Adresse Ihres Objektservers verweist.
        • (Optional) Wenn Sie möchten, dass Ihr Server über IPv6 erreichbar ist, benötigen Sie einen AAAA-Eintrag, wobei Ihr Servername auf die IPv6-Adresse Ihres Objektservers verweist.

      Schritt 1 – Installieren und Konfigurieren des Minio-Servers

      Sie können den Minio-Server installieren, indem Sie den Quellcode kompilieren oder eine Binärdatei verwenden. Um den Server von der Quelle zu installieren, müssen Sie in Ihrem System mindestens Go 1.12 installiert haben.

      In diesem Schritt installieren Sie den Server über die vorkompilierte Binärdatei und konfigurieren dann den Minio-Server.

      Melden Sie sich zunächst bei Ihrem Server an, indem Sie sammy durch Ihren Benutzernamen und your_server_ip durch die IP-Adresse Ihres Ubuntu 18.04-Servers ersetzen:

      Wenn Sie die Paketdatenbank in letzter Zeit nicht aktualisiert haben, tun Sie es nun:

      Laden Sie als Nächstes die Binärdatei des Minio-Servers von der offiziellen Website herunter:

      • wget https://dl.min.io/server/minio/release/linux-amd64/minio

      Sie werden eine Ausgabe sehen, die etwa folgendermaßen aussieht:

      Output

      --2019-08-27 15:08:49-- https://dl.min.io/server/minio/release/linux-amd64/minio Resolving dl.min.io (dl.min.io)... 178.128.69.202 Connecting to dl.min.io (dl.min.io)|178.128.69.202|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 44511616 (42M) [application/octet-stream] Saving to: ‘minio’ minio 100%[===================>] 42.45M 21.9MB/s in 1.9s 2019-08-27 15:08:51 (21.9 MB/s) - ‘minio’ saved [44511616/44511616]

      Nach Abschluss des Downloads befindet sich in Ihrem Arbeitsverzeichnis eine Datei namens minio. Verwenden Sie folgenden Befehl, um sie ausführbar zu machen:

      Verschieben Sie die Datei nun in das Verzeichnis /usr/local/bin, in dem das Startskript systemd von Minio sie erwartet:

      • sudo mv minio /usr/local/bin

      Das erlaubt es uns später in dem Tutorial, eine Diensteinheitdatei zu schreiben, damit Minio beim Start automatisch ausgeführt wird.

      Aus Sicherheitsgründen ist es besser, den Minio-Server als root auszuführen. So lassen sich Schäden, die bei einer Kompromittierung Ihres Systems entstehen können, begrenzen. Da das in Schritt 2 verwendete Skript systemd nach einem Benutzerkonto und einer Gruppe namens minio-user sucht, erstellen Sie einen neuen Benutzer mit diesem Namen:

      • sudo useradd -r minio-user -s /sbin/nologin

      In diesem Befehl haben Sie das Flag -s verwendet, um /sbin/nologin als Shell für minio-user festzulegen. Dies ist ein Shell, das keine Benutzeranmeldung erlaubt, was für minio-user auch nicht benötigt wird.

      Ändern Sie als Nächstes den Besitz an der Minio-Binärdatei in minio-user:

      • sudo chown minio-user:minio-user /usr/local/bin/minio

      Als Nächstes erstellen Sie ein Verzeichnis, in dem Minio Dateien speichert. Dies ist der Speicherort für die Buckets, die Sie später zum Organisieren von Objekten, die Sie auf Ihrem Minio-Server speichern, nutzen werden. In diesem Tutorial heißt das Verzeichnis minio:

      • sudo mkdir /usr/local/share/minio

      Vergeben Sie den Besitz dieses Verzeichnisses an minio-user:

      • sudo chown minio-user:minio-user /usr/local/share/minio

      Die meisten Serverkonfigurationsdateien werden im Verzeichnis /etc gespeichert. Erstellen Sie also dort Ihre Minio-Konfigurationsdatei.

      Übergeben Sie den Besitz dieses Verzeichnisses ebenfalls an minio-user:

      • sudo chown minio-user:minio-user /etc/minio

      Verwenden Sie Nano oder Ihren bevorzugten Texteditor, um die Umgebungsdatei zu erstellen, die zum Ändern der Standardkonfiguration benötigt wird:

      • sudo nano /etc/default/minio

      Wenn die Datei geöffnet ist, fügen Sie die folgenden Zeilen hinzu, um in Ihrer Umgebungsdatei einige wichtige Umgebungsvariablen festzulegen:

      /etc/default/minio

      MINIO_ACCESS_KEY="minio"
      MINIO_VOLUMES="/usr/local/share/minio/"
      MINIO_OPTS="-C /etc/minio --address your_server_ip:9000"
      MINIO_SECRET_KEY="miniostorage"
      

      Sehen wir uns diese Variablen sowie die Werte an, die Sie festlegen:

      • MINIO_ACCESS_KEY: Dadurch wird der Zugriffsschlüssel festgelegt, den Sie für den Zugriff auf die Benutzeroberfläche des Minio-Browsers nutzen werden.
      • MINIO_SECRET_KEY: Damit wird der private Schlüssel festgelegt, den Sie zum Vervollständigen Ihrer Anmeldeinformationen in der Minio-Oberfläche verwenden werden. In diesem Tutorial ist der Wert auf miniostorage festgelegt; wir empfehlen jedoch die Auswahl eines anderen, komplexeren Passworts zum Schutz Ihres Servers.
      • MINIO_VOLUMES: Damit wird das Speicherverzeichnis angegeben, das Sie für Ihre Buckets erstellt haben.
      • MINIO_OPTS: Damit lässt sich ändern, wo und wie der Server Daten bereitstellt. Das Flag -C verweist auf das zu verwendende Konfigurationsverzeichnis, während das Flag --address Minio über die IP-Adresse und den Port für die Bindung informiert. Wenn keine IP-Adresse angegeben ist, bindet sich Minio an jede auf dem Server konfigurierte Adresse, einschließlich localhost und mit Docker verknüpfter IP-Adressen; daher wird empfohlen, die IP-Adresse hier anzugeben. Der Standardport 9000 kann bei Bedarf geändert werden.

      Speichern und schließen Sie abschließend die Umgebungsdatei, nachdem Sie alle Änderungen vorgenommen haben.

      Sie haben Minio jetzt installiert und einige wichtige Umgebungsvariablen festgelegt. Als Nächstes konfigurieren Sie den Server so, dass er als Systemdienst ausgeführt wird.

      Schritt 2 – Installieren des Minio Systemd-Startskripts

      In diesem Schritt konfigurieren Sie den Minio-Server so, dass er als systemd-Dienst verwaltet wird.

      Laden Sie zunächst mit folgendem Befehl die offizielle Deskriptordatei für den Minio-Dienst herunter:

      • curl -O https://raw.githubusercontent.com/minio/minio-service/master/linux-systemd/minio.service

      Sie werden eine Ausgabe sehen, die etwa folgendermaßen aussieht:

      Output

      % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 835 100 835 0 0 6139 0 --:--:-- --:--:-- --:--:-- 6139

      Nach Abschluss des Downloads befindet sich in Ihrem Arbeitsverzeichnis eine Datei namens minio.service.

      Um den Inhalt von minio.service vor der Anwendung zu überprüfen, öffnen Sie ihn in einem Texteditor:

      Dadurch wird Folgendes angezeigt:

      /etc/systemd/system/minio.service

      [Unit]
      Description=MinIO
      Documentation=https://docs.min.io
      Wants=network-online.target
      After=network-online.target
      AssertFileIsExecutable=/usr/local/bin/minio
      
      [Service]
      WorkingDirectory=/usr/local/
      
      User=minio-user
      Group=minio-user
      
      EnvironmentFile=/etc/default/minio
      ExecStartPre=/bin/bash -c "if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi"
      
      ExecStart=/usr/local/bin/minio server $MINIO_OPTS $MINIO_VOLUMES
      
      # Let systemd restart this service always
      Restart=always
      
      # Specifies the maximum file descriptor number that can be opened by this process
      LimitNOFILE=65536
      
      # Disable timeout logic and wait until process is stopped
      TimeoutStopSec=infinity
      SendSIGKILL=no
      
      [Install]
      WantedBy=multi-user.target
      
      # Built for ${project.name}-${project.version} (${project.name})
      

      Diese Diensteinheitdatei startet den Minio-Server mit dem Benutzer minio-user, den Sie zuvor erstellt haben. Sie implementiert außerdem die im letzten Schritt festgelegten Umgebungsvariablen und sorgt dafür, dass der Server beim Start automatisch ausgeführt wird. Weitere Informationen zu systemd-Unit-Dateien finden Sie in unserem Leitfaden Informationen zu systemd-Units und Unit-Dateien.

      Nach Prüfung der Inhalte des Skripts schließen Sie den Texteditor.

      Systemd setzt voraus, dass Unit-Dateien im Konfigurationsverzeichnis systemd gespeichert werden. Verschieben Sie minio.service also dort hin:

      • sudo mv minio.service /etc/systemd/system

      Führen Sie dann den folgenden Befehl zum Neuladen aller systemd-Units aus:

      • sudo systemctl daemon-reload

      Aktivieren Sie zum Schluss das Starten von Minio beim Booten:

      • sudo systemctl enable minio

      Dadurch erhalten Sie folgende Ausgabe:

      Output

      Created symlink from /etc/systemd/system/multi-user.target.wants/minio.service to /etc/systemd/system/minio.service.

      Nachdem Sie das Skript systemd nun installiert und konfiguriert haben, ist es Zeit zum Starten des Servers.

      Schritt 3 – Starten des Minio-Servers

      In diesem Schritt starten Sie den Server und ändern die Firewall, um Zugriff über die Browseroberfläche zuzulassen.

      Starten Sie zunächst den Minio-Server:

      • sudo systemctl start minio

      Überprüfen Sie als Nächstes den Status des Minio-Servers, die IP-Adresse, an die er gebunden ist, die Arbeitsspeichernutzung und mehr, indem Sie folgenden Befehl ausführen:

      • sudo systemctl status minio

      Sie erhalten folgende Ausgabe:

      Output

      ● minio.service - MinIO Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2019-12-09 21:54:02 UTC; 46s ago Docs: https://docs.min.io Process: 3405 ExecStartPre=/bin/bash -c if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi (code=exited, status=0/SUCCES Main PID: 3407 (minio) Tasks: 7 (limit: 1152) CGroup: /system.slice/minio.service └─3407 /usr/local/bin/minio server -C /etc/minio --address your_server_IP:9000 /usr/local/share/minio/ Dec 09 21:54:02 cart-Minion-Object-1804-1 systemd[1]: Started MinIO. Dec 09 21:54:03 cart-Minion-Object-1804-1 minio[3407]: Endpoint: http://your_server_IP:9000 Dec 09 21:54:03 cart-Minion-Object-1804-1 minio[3407]: Browser Access: Dec 09 21:54:03 cart-Minion-Object-1804-1 minio[3407]: http://your_server_IP:9000 ...

      Aktivieren Sie als Nächstes den Zugriff auf den Minio-Server über die Firewall am konfigurierten Port. In diesem Tutorial ist das der Port 9000.

      Fügen Sie zunächst die Regel hinzu:

      Aktivieren Sie dann die Firewall:

      Sie erhalten folgende Eingabeaufforderung:

      Output

      Command may disrupt existing ssh connections. Proceed with operation (y|n)?

      Drücken Sie auf y und bestätigen Sie mit der Eingabetaste: Sie erhalten dann folgende Ausgabe:

      Output

      Firewall is active and enabled on system startup

      Minio ist jetzt bereit dazu, Datenverkehr zu akzeptieren. Bevor Sie aber eine Verbindung mit dem Server herstellen, sichern Sie die Kommunikation durch Installation eines SSL/TLS-Zertifikats.

      Schritt 4 – Sichern des Zugriffs auf Ihren Minio-Server mit einem TLS-Zertifikat

      In diesem Schritt sichern Sie den Zugriff auf Ihren Minio-Server mit einem privaten Schlüssel und einem öffentlichen Zertifikat, das von einer Zertifizierungsstelle (CA) empfangen wurde – in diesem Fall von Let’s Encrypt. Um ein kostenloses SSL-Zertifikat zu erhalten, verwenden Sie Certbot.

      Lassen Sie zunächst HTTP- und HTTPS-Zugriff über Ihre Firewall zu. Öffnen Sie dazu Port 80, was der Port für HTTP ist:

      Öffnen Sie als Nächstes Port 443 für HTTPS:

      Überprüfen Sie nach dem Hinzufügen dieser Regeln den Status Ihrer Firewall mit folgendem Befehl:

      Sie werden eine Ausgabe sehen, die etwa folgendermaßen aussieht:

      Output

      Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp (OpenSSH) ALLOW IN Anywhere 9000 ALLOW IN Anywhere 443 ALLOW IN Anywhere 80 ALLOW IN Anywhere 22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6) 9000 (v6) ALLOW IN Anywhere (v6) 443 (v6) ALLOW IN Anywhere (v6) 80 (v6) ALLOW IN Anywhere (v6)

      Dadurch wird bestätigt, dass Ports 80 und 443 geöffnet sind, was bedeutet, dass Ihr Server Anfragen aus dem Internet akzeptiert.

      Als Nächstes installieren Sie Certbot. Da Certbot ein separates PPA-Repository unterhält, müssen Sie es zunächst zu Ihrer Liste von Repositorys hinzufügen, bevor Sie Certbot wie dargestellt installieren:

      Um das Hinzufügen des PPA-Repository vorzubereiten, installieren Sie zunächst software-properties-common, ein Paket zum Verwalten von PPAs:

      • sudo apt install software-properties-common

      Dieses Paket bietet einige nützliche Skripts zum Hinzufügen und Entfernen von PPAs, damit Sie es nicht manuell tun müssen.

      Fügen Sie jetzt das Repository Universe hinzu:

      • sudo add-apt-repository universe

      Dieses Repository enthält kostenlose Open-Source-Software, die von der Ubuntu-Community gepflegt wird, jedoch nicht offiziell von Canonical, den Entwicklern von Ubuntu. Hier finden wir das Repository for Certbot.

      Fügen Sie als Nächstes das Certbot-Repository hinzu:

      • sudo add-apt-repository ppa:certbot/certbot

      Sie erhalten die folgende Ausgabe:

      Output

      This is the PPA for packages prepared by Debian Let's Encrypt Team and backported for Ubuntu(s). More info: https://launchpad.net/~certbot/+archive/ubuntu/certbot Press [ENTER] to continue or ctrl-c to cancel adding it

      Drücken Sie die Eingabetaste, um fortzufahren.

      Aktualisieren Sie dann die Paketliste:

      Installieren Sie zum Schluss certbot:

      Als Nächstes verwenden Sie certbot zum Erstellen eines neuen SSL-Zertifikats.

      Da Ubuntu 18.04 noch keine automatische Installation unterstützt, verwenden Sie den Befehl certonly und --standalone, um das Zertifikat abzurufen:

      • sudo certbot certonly --standalone -d minio-server.your_domain

      --standalone bedeutet, dass dies ein Zertifikat für einen integrierten Standalone-Webserver ist. Weitere Informationen dazu finden Sie in unserem Tutorial Verwenden von Certbot im Standalone-Modus zum Abrufen von Let’s Encrypt-SSL-Zertifikaten unter Ubuntu 18.04.

      Sie erhalten die folgende Ausgabe:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel):

      Fügen Sie Ihre E-Mail-Adresse hinzu und drücken Sie die Eingabetaste.

      Certbot fordert Sie dann dazu auf, sich bei Let’s Encrypt zu registrieren:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Please read the Terms of Service at https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must agree in order to register with the ACME server at https://acme-v02.api.letsencrypt.org/directory - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (A)gree/(C)ancel:

      Geben Sie A ein und drücken Sie die Eingabetaste, um zu akzeptieren.

      Als Nächstes werden Sie gefragt, ob Sie damit einverstanden sind, Ihre E-Mail-Adresse mit der Electronic Frontier Foundation zu teilen:

      Output

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Would you be willing to share your email address with the Electronic Frontier Foundation, a founding partner of the Let's Encrypt project and the non-profit organization that develops Certbot? We'd like to send you email about our work encrypting the web, EFF news, campaigns, and ways to support digital freedom. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - (Y)es/(N)o:

      Nachdem Sie mit Y oder N geantwortet haben, werden Ihre öffentlichen und privaten Schlüssel generiert und im Verzeichnis /etc/letsencrypt/live/minio-server.your_domain_name gespeichert.

      Kopieren Sie als Nächstes diese beiden Dateien (privkey.pem und fullchain.pem) in das Verzeichnis certs unter dem Konfigurationsverzeichnis des Minio-Servers, das in diesem Tutorial /etc/minio lautet. Verwenden Sie folgenden Befehl zum Kopieren von privkey.pem und zum Umbenennen der Datei private.key:

      • sudo cp /etc/letsencrypt/live/minio-server.your_domain_name/privkey.pem /etc/minio/certs/private.key

      Tun Sie dann das Gleiche für fullchain.pem und nennen Sie das Ergebnis public.crt:

      • sudo cp /etc/letsencrypt/live/minio-server.your_domain_name/fullchain.pem /etc/minio/certs/public.crt

      Ändern Sie jetzt den Besitz an den Dateien in minio-user. Erledigen Sie diese Aufgabe zunächst für private.key:

      • sudo chown minio-user:minio-user /etc/minio/certs/private.key

      Dann für public.crt:

      • sudo chown minio-user:minio-user /etc/minio/certs/public.crt

      Starten Sie den Minio-Server neu, damit er sich des Zertifikats bewusst wird und mit HTTPS startet:

      • sudo systemctl restart minio

      Zertifikate von Let’s Encrypt sind nur für neunzig Tage gültig. Das soll Benutzer dazu ermutigen, die Erneuerung ihrer Zertifikate zu automatisieren. Das Certbot-Paket, das Sie automatisch installiert haben, fügt /etc/cron.d ein Erneuerungsskript hinzu. Dieses Skript wird zweimal pro Tag ausgeführt und erneuert automatisch alle Zertifikate, die innerhalb von dreißig Tagen ablaufen.

      Damit ist die Verbindung von Minio jetzt sicher und das SSL/TLS-Zertifikat wird automatisch für Sie erneuert. Im nächsten Schritt stellen Sie über den Browser eine Verbindung mit Minio her, um den Server zu verwenden.

      Schritt 5 – Sicheres Herstellen einer Verbindung mit der Weboberfläche von Minio über HTTPS

      In diesem Schritt stellen Sie eine sichere Verbindung mit der Minio-Weboberfläche über HTTPS her und erstellen dann Buckets, in die Sie Objekte hochladen.

      Greifen Sie auf die Weboberfläche zu, indem Sie in Ihrem Browser https://minio-server.your_domain:9000 aufrufen.

      Sie sehen den Anmeldebildschirm des Minio-Servers:

      Minio-Anmeldebildschirm

      Melden Sie sich jetzt bei der Hauptoberfläche an, indem Sie Ihre Anmeldeinformationen eingeben. Geben Sie für Access Key (Zugriffsschlüssel) den MINIO_ACCESS_KEY ein, den Sie in der Umgebungsdatei /etc/default/minio in Schritt 1 festgelegt haben. Geben Sie für Secret Key (Geheimer Schlüssel) den MINIO_SECRET_KEY ein, den Sie in derselben Datei festgelegt haben. Klicken Sie nach Eingabe der Anmeldeinformationen auf die runde Schaltfläche mit dem Pfeil direkt unterhalb der Eingabefelder.

      Nun wird die Benutzeroberfläche von Minio angezeigt. Um einen neuen Bucket zu erstellen, in dem Sie Objekte speichern können, klicken Sie auf die hellrote Schaltfläche + unten rechts in der Hauptoberfläche; nun werden zwei zusätzliche gelbe Schaltflächen angezeigt.

      Hauptoberfläche von Minio

      Klicken Sie auf die mittlere gelbe Schaltfläche und geben Sie in der Eingabeaufforderung einen Namen für Ihren neuen Bucket ein, bevor Sie die Eingabetaste drücken, um Ihre Antwort zu speichern. Ihr neuer Bucket kann jetzt als Speicher verwendet werden.

      Anmerkung: Stellen Sie bei der Benennung Ihres Minio-Buckets sicher, dass der Name nur Kleinbuchstaben, Zahlen und Bindestriche enthält. Minio begrenzt die Namenskonventionen für Buckets, um mit AWS S3-Standards vereinbar zu sein.

      Wenn Sie Objekte in Ihren Bucket hinzufügen möchten, klicken Sie auf dieselbe hellrote Schaltfläche wie zuvor und klicken Sie dann auf die obere gelbe Schaltfläche, um eine Eingabeaufforderung für den Datei-Upload zu öffnen.

      Jetzt haben Sie mit dem Erstellen von Buckets und Hochladen von Objekten alle grundlegenden Funktionen der Weboberfläche verwendet.

      Zusammenfassung

      Sie verfügen jetzt über einen eigenen Minio-Server, mit dem Sie über die Weboberfläche unter Verwendung eines Let’s Encrypt-SSL/TLS-Zertifikats eine sichere Verbindung herstellen können. Optional können Sie sich die Minio-Desktopclients für FreeBSD, Linux, Mac und Windows als Alternative für das Verwenden und Verwalten Ihres Objektspeicherservers ansehen.

      Wenn Sie außerdem die Speicherkapazität Ihrer Minio-Installation über die Datenträgergröße Ihres Servers hinaus erhöhen möchten, können Sie den Blockspeicherdienst von DigitalOcean nutzen, um ein Volume mit Ihrem Server zu verbinden und die Speicherkapazität um bis zu 80 TB zu erweitern.

      Weitere Informationen zu Minio finden Sie auf der Dokumentationswebsite des Projekts. Wenn Sie mehr über Objektspeicher erfahren möchten, sehen Sie sich unsere Tutorials zu Objektspeicher an.



      Source link

      Einrichten der Eclipse Theia Cloud IDE-Plattform unter DigitalOcean Kubernetes


      Der Autor hat den Free and Open Source Fund dazu ausgewählt, eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Die Erstellung und Einführung von Cloud-IDE-Plattformen (IDE: Integrated Development Environment) nimmt zu, da Entwickler-Tools immer häufiger cloudbasiert sind. Cloud-IDEs sind per Webbrowser über beliebige moderne Geräte zugänglich und bieten zahlreiche Vorteile für echtzeitbasierte Zusammenarbeit. Eine Cloud-IDE bietet Ihnen und Ihrem Team eine einheitliche Entwicklungs- und Testumgebung und minimiert gleichzeitig Plattform-Inkompatibilitäten. Da die Plattformen nativ auf Cloud-Technologien basieren, können sie unter Verwendung des Clusters Aufgaben erledigen, die deutlich über die Leistung und Zuverlässigkeit einzelner Entwicklungscomputer hinausgehen.

      Eclipse Theia ist eine erweiterbare Cloud IDE, die auf einem Remote-Server läuft und von einem Web-Browser aus zugänglich Aussehen und Verhalten ähneln Microsoft Visual Studio-Code​​​, was heißt, dass viele Programmiersprachen unterstützt werden und es ein flexibles Layout sowie ein integriertes Terminal gibt. Was Eclipse Theia von einer anderen Cloud IDE-Software unterscheidet, ist die Erweiterbarkeit; sie kann mit benutzerdefinierten Erweiterungen modifiziert werden, damit Sie eine Cloud IDE für Ihre Bedürfnisse erstellen können.

      In diesem Tutorial richten Sie die Standardversion der Eclipse Theia Cloud IDE-Plattform in Ihrem DigitalOcean Kubernetes-Cluster ein und machen sie in Ihrer Domäne verfügbar, gesichert mit Let’s Encrypt-Zertifikaten und mit vorgeschriebener Authentifizierung des Benutzers. Zum Schluss wird Eclipse Theia in Ihrem Kubernetes-Cluster ausgeführt, der über HTTPS verfügbar ist; dabei muss sich der Benutzer anmelden.

      Voraussetzungen

      • Ein DigitalOcean Kubernetes-Cluster, bei dem Ihre Verbindung standardmäßig als kubectl konfiguriert ist. Eine Anleitung zur Konfiguration von kubectl finden Sie unter dem Schritt Verbinden mit Ihrem Cluster, wenn Sie Ihren Cluster erstellen. Um einen Kubernetes-Cluster in DigitalOcean zu erstellen, lesen Sie unser Dokument Kubernetes Schnellstart.

      • Der auf Ihrem lokalen Rechner installierte Helm-Paketmanager und das in Ihrem Cluster installierte Tiller. Führen Sie dazu die Schritte 1 und 2 des Tutorials Installieren von Software in Kubernetes-Clustern mit dem Helm-Paketmanager aus.

      • Der Nginx Ingress Controller und Cert Manager, in Ihrem Cluster mit Helm installiert, um Eclipse Theia mit Ingress Resources verfügbar zu machen. Folgen Sie dazu den Anweisungen unter Einrichten eines Nginx Ingress unter DigitalOcean Kubernetes mit Helm.

      • Ein vollständig registrierter Domänenname zum Hosten von Eclipse Theia. Dieses Tutorial verwendet in allen Bereichen theia.your_domain. Sie können einen Domänennamen unter Namecheap günstig erwerben oder einen kostenlosen von Freenom herunterladen,. oder einfach die Domänenregistrierngsstelle Ihrer Wahl verwenden.

      Schritt 1 — Installieren und Verfügbarmachen von Eclipse Theia

      Installieren Sie zunächst Eclipse Theia in Ihrem DigitalOcean Kubernetes-Cluster. Dann machen Sie die Plattform in Ihrer gewünschten Domäne mit einem Nginx Ingress verfügbar.

      Da Sie im Rahmen der Voraussetzungen zwei Beispielumgebungen und eine Ressource erstellt haben, können Sie diese durch Ausführung folgender Befehle bei Bedarf löschen:

      • kubectl delete -f hello-kubernetes-ingress.yaml
      • kubectl delete -f hello-kubernetes-first.yaml
      • kubectl delete -f hello-kubernetes-second.yaml

      In diesem Tutorial speichern Sie die Bereitstellungskonfiguration auf Ihrem lokalen Rechner, in einer Datei namens eclipse-theia.yaml. Erstellen Sie diese mit dem folgenden Befehl:

      Fügen Sie der Datei folgende Zeilen hinzu:

      eclipse-theia.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: theia
      ---
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: theia-next
        namespace: theia
        annotations:
          kubernetes.io/ingress.class: nginx
      spec:
        rules:
        - host: theia.your_domain
          http:
            paths:
            - backend:
                serviceName: theia-next
                servicePort: 80
      ---
      apiVersion: v1
      kind: Service
      metadata:
       name: theia-next
       namespace: theia
      spec:
       ports:
       - port: 80
         targetPort: 3000
       selector:
         app: theia-next
      ---
      apiVersion: apps/v1
      kind: Deployment
      metadata:
        labels:
          app: theia-next
        name: theia-next
        namespace: theia
      spec:
        selector:
          matchLabels:
            app: theia-next
        replicas: 1
        template:
          metadata:
            labels:
              app: theia-next
          spec:
            containers:
            - image: theiaide/theia:next
              imagePullPolicy: Always
              name: theia-next
              ports:
              - containerPort: 3000
      

      Diese Konfiguration definiert einen Namespace, eine Bereitstellung, einen Dienst und einen Ingress. Der Namespace heißt theia und enthält alle Kubernetes-Objekte, die mit Eclipse Theia verbunden sind, getrennt vom Rest des Clusters. Die Bereitstellung besteht aus einer Instanz des theiaide/theia:next-Docker-Image, wobei Port 3000 für den Container verfügbar ist. Der Dienst sucht nach der Bereitstellung und ordnet den Container-Port dem üblichen HTTP-Port 80 zu, um Zugriff im Cluster auf Eclipse Theia zu ermöglichen.

      Der Ingress enthält eine Regel, um den Dienst bei Port 80 an Ihrer gewünschten Domäne extern bereitzustellen. In den Anmerkungen geben Sie an, dass zur Bearbeitung von Anfragen der Nginx Ingress Controller verwendet werden soll. Vergessen Sie nicht, theia.your_domain durch Ihre gewünschte Domäne zu ersetzen, die Sie auf den Load Balancer Ihres Clusters verwiesen haben. Speichern und schließen Sie dann die Datei.

      Speichern und schließen Sie die Datei.

      Erstellen Sie anschließend die Konfiguration in Kubernetes, indem Sie folgenden Befehl ausführen:

      • kubectl create -f eclipse-theia.yaml

      Sie sehen die folgende Ausgabe:

      Output

      namespace/theia created ingress.networking.k8s.io/theia-next created service/theia-next created deployment.apps/theia-next created

      Sie können die Erstellung des Eclipse Theia-Pods überprüfen, indem Sie folgenden Befehl ausführen:

      • kubectl get pods -w -n theia

      Die Ausgabe sieht in etwa folgendermaßen aus:

      Output

      NAME READY STATUS RESTARTS AGE theia-next-847d8c8b49-jt9bc 0/1 ContainerCreating 0 22s

      Nach einer gewissen Zeit ändert sich der Status in RUNNING, was bedeutet, dass Sie Eclipse Theia erfolgreich in Ihrem Cluster installiert haben.

      Navigieren Sie im Browser zu Ihrer Domäne. Sie sehen die Standardoberfläche des Eclipse Theia-Editors.

      Die Standardoberfläche des Eclipse Theia-Editors

      Sie haben Eclipse Theia in Ihrem DigitalOcean Kubernetes-Cluster bereitgestellt und in Ihrer gewünschten Domäne mit einem Ingress verfügbar gemacht. Als Nächstes sichern Sie den Zugriff auf Ihre Eclipse Theia-Bereitstellung, indem Sie die Anmeldeauthentifizierung aktivieren.

      Schritt 2 — Aktivieren der Anmeldeauthentifizierung für Ihre Domäne

      In diesem Schritt aktivieren Sie für Ihre Eclipse Theia-Umgebung die Authentifizierung mit Benutzername und Passwort. Sie erreichen dies, indem Sie zunächst mit dem Dienstprogramm htpasswd eine Liste mit gültigen Anmeldekombinationen zusammenstellen. Dann erstellen Sie ein Kubernetes-Geheimnis, das diese Liste enthält, und konfigurieren den Ingress, um eine entsprechende Authentifizierung von Besuchern vorzunehmen. Am Ende wird Ihre Domäne nur zugänglich sein, wenn der Besucher eine gültige Kombination aus Benutzername und Passwort eingibt. Dadurch werden Gäste und andere unerwünschte Besucher daran gehindert, auf Eclipse Theia zuzugreifen.

      Das Dienstprogramm htpasswd stammt vom Apache-Webserver und dient zum Erstellen von Dateien, in denen Listen von Anmeldekombinationen gespeichert werden. Das Format von htpasswd ist eine username:hashed_password-Kombination pro Zeile, was das Format ist, das der Nginx Ingress Controller von der Liste erwartet.

      Installieren Sie zunächst htpasswd in Ihrem System, indem Sie folgenden Befehl ausführen:

      • sudo apt install apache2-utils -y

      Speichern Sie die Liste in einer Datei namens auth. Erstellen Sie sie, indem Sie folgenden Befehl ausführen:

      Die Datei muss auth heißen, da der Nginx Ingress Controller davon ausgeht, dass das Geheimnis einen Schlüssel namens data.auth enthält. Wenn der Schlüssel fehlt, gibt der Controller den HTTP 503-Status Dienst nicht verfügbar zurück.

      Fügen Sie auth eine Kombination aus Benutzername und Passwort hinzu, indem Sie folgenden Befehl ausführen:

      Denken Sie daran, username durch Ihren gewünschten Benutzernamen zu ersetzen. Sie werden nach einem begleitenden Passwort gefragt, bevor die Kombination dann der Datei auth hinzugefügt wird. Sie können diesen Befehl für so viele Benutzer wiederholen, wie Sie hinzufügen möchten.

      Anmerkung: Wenn im System, mit dem Sie arbeiten, htpasswd nicht installiert ist, können Sie stattdessen eine dockerisierte Version verwenden.

      Dafür muss Docker auf Ihrem Rechner installiert sein. Eine Anleitung dazu finden Sie in der offiziellen Dokumentation.

      Führen Sie folgenden Befehl aus, um eine dockerisierte Version auszuführen:

      • docker run --rm -it httpd htpasswd -n <username>

      Denken Sie daran, <username> durch den gewünschten Benutzernamen zu ersetzen. Sie werden nach einem Passwort gefragt. Die Anmeldekombination mit Hash wird in der Konsole ausgeschrieben; Sie müssen sie am Ende der Datei auth manuell hinzufügen. Wiederholen Sie diesen Vorgang für so viele Anmeldungen, wie Sie hinzufügen möchten.

      Wenn Sie damit fertig sind, erstellen Sie in Kubernetes ein neues Geheimnis mit dem Inhalt der Datei, indem Sie folgenden Befehl ausführen:

      • kubectl create secret generic theia-basic-auth --from-file=auth -n theia

      Sie können das Geheimnis anzeigen mit:

      • kubectl get secret theia-basic-auth -o yaml -n theia

      Die Ausgabe sieht ungefähr so aus:

      Output

      apiVersion: v1 data: auth: c2FtbXk6JGFwcjEkVFMuSDdyRWwkaFNSNWxPbkc0OEhncmpGZVFyMzEyLgo= kind: Secret metadata: creationTimestamp: "..." name: theia-basic-auth namespace: default resourceVersion: "10900" selfLink: /api/v1/namespaces/default/secrets/theia-basic-auth uid: 050767b9-8823-4fd3-b498-5f11074f768b type: Opaque

      Als Nächstes müssen Sie den Ingress so bearbeiten, dass er das Geheimnis verwendet. Öffnen Sie die Bereitstellungskonfiguration zum Bearbeiten:

      Fügen Sie in Ihrer Datei die hervorgehobenen Zeilen hinzu:

      eclipse-theia.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: theia
      ---
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: theia-next
        namespace: theia
        annotations:
          kubernetes.io/ingress.class: nginx
          nginx.ingress.kubernetes.io/auth-type: basic
          nginx.ingress.kubernetes.io/auth-secret: theia-basic-auth
          nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - Eclipse Theia'
      spec:
        rules:
        - host: theia.your_domain
          http:
            paths:
            - backend:
                serviceName: theia-next
                servicePort: 80
      ...
      

      Geben Sie zuerst in der Anmerkung auth-type an, dass der Authentifizierungstyp basic ist. Das bedeutet, dass Nginx vom Benutzer verlangt, einen Benutzernamen und ein Passwort einzugeben. Dann geben Sie in auth-secret an, dass das Geheimnis, das die Liste mit gültigen Kombinationen enthält, theia-basic-auth lautet. Dieses Geheimnis haben Sie gerade erstellt. Die verbleibende Anmerkung auth-realm gibt eine Nachricht an, die dem Benutzer als Erklärung zur vorgeschriebenen Authentifizierung angezeigt wird. Sie können die in diesem Feld enthaltene Nachricht nach Belieben ändern.

      Speichern und schließen Sie die Datei.

      Um die Änderungen in Ihrem Cluster zu verteilen, führen Sie folgenden Befehl aus:

      • kubectl apply -f eclipse-theia.yaml

      Sie sehen die folgende Ausgabe:

      Output

      namespace/theia unchanged ingress.networking.k8s.io/theia-next configured service/theia-next unchanged deployment.apps/theia-next unchanged

      Navigieren Sie im Browser zu Ihrer Domäne, wo Sie sich anmelden müssen.

      Sie haben für Ihren Ingress die grundlegende Anmeldeauthentifizierung aktiviert, indem Sie ihn so konfiguriert haben, dass das Geheimnis mit der Hash-Kombination aus Benutzername und Passwort verwendet wird. Im nächsten Schritt sichern Sie den Zugriff durch Hinzufügen von TLS-Zertifikaten, sodass der Datenverkehr zwischen Ihnen und Ihrer Eclipse Theia-Umgebung verschlüsselt bleibt.

      Schritt 3 — Anwenden von Let’s Encrypt-HTTPS-Zertifikaten

      Als Nächstes sichern Sie Ihre Eclipse Theia-Installation, indem Sie auf Ihren Ingress Let’s Encrypt-Zertifikate anwenden, die von Cert-Manager automatisch bereitgestellt werden. Nach Abschluss dieses Schritts ist Ihre Eclipse Theia-Installation über HTTPS aufrufbar.

      Öffnen Sie eclipse-theia.yaml, um die Datei zu bearbeiten:

      Fügen Sie die hervorgehobenen Zeilen Ihrer Datei hinzu und ersetzen Sie dabei die Platzhalterdomäne durch Ihre eigene Domäne:

      eclipse-theia.yaml

      apiVersion: v1
      kind: Namespace
      metadata:
        name: theia
      ---
      apiVersion: networking.k8s.io/v1beta1
      kind: Ingress
      metadata:
        name: theia-next
        namespace: theia
        annotations:
          kubernetes.io/ingress.class: nginx
          nginx.ingress.kubernetes.io/auth-type: basic
          nginx.ingress.kubernetes.io/auth-secret: theia-basic-auth
          nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required - Eclipse Theia'
          cert-manager.io/cluster-issuer: letsencrypt-prod
      spec:
        tls:
        - hosts:
          - theia.your_domain
          secretName: theia-prod
        rules:
        - host: theia.your_domain
          http:
            paths:
            - backend:
                serviceName: theia-next
                servicePort: 80
      ...
      

      Geben Sie zunächst den letsencrypt-prod-ClusterIssuer an, den Sie im Rahmen der Voraussetzungen erstellt haben, da dieser Aussteller der Bereitstellung von Zertifikaten für diesen Ingress dient. Dann geben Sie im Abschnitt tls die genaue Domäne, die gesichert werden soll, sowie einen Namen für ein Geheimnis an, das diese Zertifikate enthalten wird.

      Speichern und schließen Sie die Datei.

      Wenden Sie die Änderungen in Ihrem Cluster an, indem Sie folgenden Befehl ausführen:

      • kubectl apply -f eclipse-theia.yaml

      Die Ausgabe sieht ungefähr so aus:

      Output

      namespace/theia unchanged ingress.networking.k8s.io/theia-next configured service/theia-next unchanged deployment.apps/theia-next unchanged

      Es dauert einige Minuten, bis die Zertifikate bereitgestellt und vollständig angewendet werden. Sie können den Fortschritt verfolgen, indem Sie die Ausgabe des folgenden Befehls überprüfen:

      • kubectl describe certificate theia-prod -n theia

      Wenn der Befehl abgeschlossen ist, sieht das Ende der Ausgabe ungefähr so aus:

      Output

      ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal GeneratedKey 42m cert-manager Generated a new private key Normal Requested 42m cert-manager Created new CertificateRequest resource "theia-prod-3785736528" Normal Issued 42m cert-manager Certificate issued successfully

      Aktualisieren Sie Ihre Domäne in Ihrem Browser. Sie sehen auf der linken Seite der Adressleiste ein grünes Schloss, was darauf hinweist, dass die Verbindung gesichert ist.

      Sie haben den Ingress so konfiguriert, dass Let’s Encrypt-Zertifikate verwendet werden, um Ihre Eclipse Theia-Installation sicherer zu machen. Jetzt können Sie die Standardbenutzeroberfläche von Eclipse Theia überprüfen.

      Schritt 3 — Benutzen der Eclipse Theia-Benutzeroberfläche

      In diesem Abschnitt werden Sie einige Funktionen von Eclipse Theia erkunden.

      Auf der linken Seite der IDE befindet sich eine vertikale Reihe von vier Schaltflächen, welche die am häufigsten verwendeten Funktionen in einem Seitenbereich öffnen.

      Eclipse-Theia-GUI – Seitenbereich

      Diese Leiste ist anpassbar: Sie können diese Ansichten in eine andere Reihenfolge bringen oder aus der Leiste entfernen. Standardmäßig öffnet die erste Ansicht das Explorer-Feld, das eine baumartige Navigation der Struktur des Projekts bereitstellt. Hier können Sie Ihre Ordner und Dateien verwalten – erstellen, löschen, verschieben und umbenennen je nach Bedarf.

      Sobald Sie über das Menü Datei eine neue Datei erstellt haben, öffnet sich eine leere Datei in einer neuen Registerkarte. Sobald sie gespeichert wurde, können Sie den Namen der Datei im Seitenfeld des Explorers sehen. Erstellen Sie Ordner durch Rechtsklick auf die Explorer-Seitenleiste und klicken Sie auf Neuer Ordner. Sie können einen Ordner erweitern, indem Sie auf seinen Namen klicken sowie Dateien und Ordner in obere Teile der Hierarchie ziehen und ablegen, um sie an einen neuen Ort zu verschieben.

      Eclipse Theia-GUI – Neuer Ordner

      Die beiden nächsten Optionen bieten Zugriff auf die Funktion zum Suchen und Ersetzen. Die darauffolgende Option bietet eine Ansicht von Versionsverwaltungssystemen, die Sie möglicherweise verwenden, wie z. B. Git.

      Die letzte Ansicht ist die Debugger-Option, die alle gängigen Aktionen zum Debuggen in dem Feld bereitstellt. Debugging-Konfigurationen können Sie in der Datei launch.json speichern.

      Debugger-Ansicht mit launch.json geöffnet

      Der zentrale Teil der GUI ist Ihr Editor, den Sie für die Codebearbeitung durch Tabs trennen können. Sie können in der Bearbeitungsansicht zwischen einem Rastersystem oder Dateien nebeneinander wechseln. Eclipse Theia unterstützt, wie alle modernen IDEs, Syntaxhervorhebung für Ihren Code.

      Rasteransicht des Editors

      Sie können sich Zugriff auf ein Terminal verschaffen, indem Sie Strg+Umschalt+` eingeben oder im oberen Menü auf Terminal klicken und Neues Terminal auswählen. Das Terminal öffnet sich in einem unteren Feld und sein Arbeitsverzeichnis wird auf den Arbeitsbereich des Projekts festgelegt, der die im Explorer-Seitenbereich angezeigten Dateien und Ordner erhält.

      Terminal geöffnet

      Sie haben sich nun einen Überblick über die Eclipse Theia-Benutzeroberfläche und einige der am häufigsten verwendeten Funktionen verschafft.

      Zusammenfassung

      Sie haben nun Eclipse Theia, eine vielseitige Cloud-IDE, in Ihrem DigitalOcean Kubernetes-Cluster installiert. Sie haben sie mit einem kostenlosen Let’s Encrypt-TLS-Zertifikat gesichert und die Instanz so eingerichtet, dass eine Anmeldung des Benutzers vorgeschrieben ist. Sie können damit an Ihrem Quellcode und Dokumenten einzeln arbeiten oder im Team zusammenarbeiten. Sie können auch versuchen, Ihre eigene Version von Eclipse Theia zu erstellen, wenn Sie zusätzliche Funktionen benötigen. Weitere Informationen dazu finden Sie unter Theia Docs.



      Source link