Automatisierung der Zertifikatsverwaltung in einer Kubernetes-Umgebung

Gültige SSL/TLS-Zertifikate sind eine Kernanforderung der modernen Anwendungslandschaft. Leider wird die Verwaltung von Zertifikatserneuerungen (oder Zertifikatserneuerungen) bei der Bereitstellung einer Anwendung häufig vernachlässigt. Zertifikate haben eine begrenzte Lebensdauer, die von etwa 13 Monaten für Zertifikate von DigiCert bis zu 90 Tagen für Let’s Encrypt-Zertifikate reicht. Um den sicheren Zugriff aufrechtzuerhalten, müssen diese Zertifikate vor ihrem Ablauf erneuert/neu ausgestellt werden. Angesichts der erheblichen Arbeitsbelastung der meisten Ops-Teams kommt es vor, dass die Erneuerung von Zertifikaten vergessen wird. Dies führt zu Chaos, wenn das Ablaufdatum der Zertifikate näher rückt – oder, schlimmer noch, es überschritten wird.

So muss es nicht sein. Mit etwas Planung und Vorbereitung kann die Zertifikatsverwaltung automatisiert und optimiert werden. Hier sehen wir uns eine Lösung für Kubernetes an, die drei Technologien verwendet:

• Jetstacks Zertifikatsmanager
• Lass uns verschlüsseln
• NGINX Ingress Controller

In diesem Blog erfahren Sie, wie Sie die Zertifikatsverwaltung vereinfachen, indem Sie Ihren Endpunkten eindeutige, automatisch erneuerte und aktualisierte Zertifikate bereitstellen.

Zertifikate in einer Kubernetes-Umgebung

Bevor wir in die technischen Details einsteigen, müssen wir einige Begriffe definieren. Der Begriff „TLS-Zertifikat“ bezieht sich auf zwei Komponenten, die zum Aktivieren von HTTPS-Verbindungen auf unserem Ingress-Controller erforderlich sind:

• Das Zertifikat
• Der private Schlüssel

Sowohl das Zertifikat als auch der private Schlüssel werden von Let’s Encrypt ausgestellt. Eine vollständige Erklärung zur Funktionsweise von TLS-Zertifikaten finden Sie im Beitrag „So funktionieren TLS/SSL-Zertifikate“ von DigiCert.

In Kubernetes werden diese beiden Komponenten als Secrets gespeichert. Kubernetes-Workloads – wie der NGINX Ingress Controller und der Cert-Manager – können diese Secrets schreiben und lesen, die auch von Benutzern verwaltet werden können, die Zugriff auf die Kubernetes-Installation haben.

Einführung des Cert-Managers

Das Cert-Manager -Projekt ist ein Zertifikatscontroller, der mit Kubernetes und OpenShift funktioniert. Bei der Bereitstellung in Kubernetes stellt der Cert-Manager automatisch die von Ingress-Controllern benötigten Zertifikate aus und stellt sicher, dass diese gültig und aktuell sind. Darüber hinaus werden Ablaufdaten von Zertifikaten verfolgt und in konfigurierten Zeitabständen eine Erneuerung versucht. Obwohl es mit zahlreichen öffentlichen und privaten Emittenten zusammenarbeitet, zeigen wir die Integration mit Let’s Encrypt.

Zwei Arten von Herausforderungen

Bei der Verwendung von Let’s Encrypt wird die gesamte Zertifikatsverwaltung automatisch durchgeführt. Dies ist zwar sehr praktisch, bringt aber auch ein Problem mit sich: Wie stellt der Dienst sicher, dass Sie der Eigentümer des betreffenden vollqualifizierten Domänennamens (FQDN) sind?

Dieses Problem wird mithilfe einer Challenge gelöst. Dabei müssen Sie eine Bestätigungsanfrage beantworten, die nur von jemandem bereitgestellt werden kann, der Zugriff auf die DNS-Einträge der jeweiligen Domäne hat. Herausforderungen können eine von zwei Formen haben:

1. HTTP-01 : Diese Herausforderung kann bewältigt werden, indem Sie über einen DNS-Eintrag für den FQDN verfügen, für den Sie ein Zertifikat ausstellen. Wenn sich Ihr Server beispielsweise unter der IP-Adresse www.xxx.yyy.zzz befindet und Ihr FQDN cert.example.com ist, legt der Challenge-Mechanismus ein Token auf dem Server unter www.xxx.yyy.zzz frei und die Let’s Encrypt-Server versuchen, es über cert.example.com zu erreichen. Bei Erfolg ist die Challenge bestanden und das Zertifikat wird ausgestellt.

    

   HTTP-01 ist die einfachste Möglichkeit, ein Zertifikat zu generieren, da kein direkter Zugriff auf den DNS-Anbieter erforderlich ist. Diese Art der Abfrage wird immer über Port 80 (HTTP) durchgeführt. Beachten Sie, dass der Cert-Manager bei der Verwendung von HTTP-01-Challenges den Ingress-Controller nutzt, um das Challenge-Token bereitzustellen.

2. DNS-01 : Diese Challenge erstellt einen DNS-TXT-Eintrag mit einem Token, der dann vom Aussteller verifiziert wird. Wenn das Token erkannt wird, haben Sie den Besitz dieser Domäne nachgewiesen und können nun Zertifikate für ihre Datensätze ausstellen. Anders als bei der HTTP-01-Challenge muss der FQDN bei der DNS-01-Challenge nicht in die IP-Adresse Ihres Servers aufgelöst werden (und muss auch nicht existieren). Darüber hinaus kann DNS-01 verwendet werden, wenn Port 80 blockiert ist. Der Nachteil dieser Benutzerfreundlichkeit besteht darin, dass Sie der Cert-Manager-Installation über ein API-Token Zugriff auf Ihre DNS-Infrastruktur gewähren müssen.

Ingress-Controller

Ein Ingress-Controller ist ein spezialisierter Dienst für Kubernetes, der Datenverkehr von außerhalb des Clusters bringt, ihn auf interne Pods (eine Gruppe aus einem oder mehreren Containern) verteilt und den ausgehenden Datenverkehr verwaltet. Darüber hinaus wird der Ingress-Controller über die Kubernetes-API gesteuert und überwacht und aktualisiert die Lastausgleichskonfiguration, wenn Pods hinzugefügt oder entfernt werden oder ausfallen.

Weitere Informationen zu Ingress-Controllern finden Sie in den folgenden Blogs:

• Kubernetes-Netzwerk 101
• Leitfaden zur Auswahl eines Ingress-Controllers, Teil 4: Optionen für den NGINX Ingress Controller

In den folgenden Beispielen verwenden wir den NGINX Ingress Controller, der von F5 NGINX entwickelt und gepflegt wird.

Beispiele für Zertifikatsverwaltung

Diese Beispiele setzen voraus, dass Sie über eine funktionierende Kubernetes-Installation verfügen, mit der Sie Tests durchführen können, und dass die Installation eine externe IP-Adresse zuweisen kann (Kubernetes LoadBalancer-Objekt). Darüber hinaus wird davon ausgegangen, dass Sie Datenverkehr sowohl auf Port 80 als auch auf Port 443 (bei Verwendung der HTTP-01-Challenge) oder nur auf Port 443 (bei Verwendung der DNS-01-Challenge) empfangen können. Diese Beispiele werden anhand von Mac OS X veranschaulicht, können aber auch unter Linux oder WSL verwendet werden.

Sie benötigen außerdem einen DNS-Anbieter und einen FQDN, für den Sie den A-Eintrag anpassen können. Wenn Sie die HTTP-01-Challenge verwenden, müssen Sie nur einen A-Eintrag hinzufügen können (oder einen für Sie hinzufügen lassen). Wenn Sie die DNS-01-Challenge verwenden, benötigen Sie API-Zugriff auf einen unterstützten DNS-Anbieter oder einen unterstützten Webhook-Anbieter .

Bereitstellen des NGINX Ingress Controllers

Am einfachsten geht das Deployment über Helm . Diese Bereitstellung ermöglicht Ihnen die Verwendung sowohl des Kubernetes Ingress als auch des NGINX Virtual Server CRD.

1. Fügen Sie das NGINX-Repository hinzu.

$ helm repo add nginx-stable https://helm.nginx.com/stable "nginx-stable" wurde zu Ihren Repositories hinzugefügt 

2. Aktualisieren Sie das Repository.

$ helm repo update Warten Sie, während wir das Neueste aus Ihren Diagramm-Repositorys holen...
...Erfolgreich ein Update aus dem Diagramm-Repository „nginx-stable“ erhalten
Update abgeschlossen. ⎈Viel Spaß beim Helmen!⎈ 

3. Stellen Sie den Ingress-Controller bereit.

$ helm install nginx-kic nginx-stable/nginx-ingress \ --namespace nginx-ingress  --set controller.enableCustomResources=true \ 
--create-namespace  --set controller.enableCertManager=true 
NAME: nginx-kic
LETZTE BEREITSTELLUNG: Do., 1. Sep. 2022, 15:58:15

NAMESPACE: nginx-ingress

STATUS: bereitgestellt

REVISION: 1
TESTSUITE: Keine
ANMERKUNGEN:
  Der NGINX Ingress Controller wurde installiert. 

4. Überprüfen Sie die Bereitstellung und rufen Sie die IP-Adresse des Ausgangs für den Ingress-Controller ab. Beachten Sie, dass Sie ohne eine gültige IP-Adresse nicht fortfahren können.

$ kubectl get deployments --namespace nginx-ingress NAME                      BEREIT   AKTUELL   VERFÜGBAR   ALTER
nginx-kic-nginx-ingress   1/1     1            1           23s
$ kubectl get services --namespace nginx-ingress
NAME                      TYP            CLUSTER-IP      EXTERNE-IP    PORT(S)                     ALTER
nginx-kic-nginx-ingress   LoadBalancer   10.128.60.190   www.xxx.yyy.zzz   80:31526/TCP,443:32058/TCP   30s 

Fügen Sie Ihren DNS-A-Eintrag hinzu

Der Vorgang hängt hierbei von Ihrem DNS-Anbieter ab. Dieser DNS-Name muss von den Let‘s Encrypt-Servern auflösbar sein. Daher kann es erforderlich sein, dass Sie warten, bis der Datensatz verbreitet wurde, bevor es funktioniert. Weitere Informationen hierzu finden Sie im SiteGround-Artikel „Was ist DNS-Verbreitung und warum dauert sie so lange?“

Sobald Sie Ihren gewählten FQDN auflösen können, können Sie mit dem nächsten Schritt fortfahren.

$ host cert.example.com cert.example.com hat die Adresse www.xxx.yyy.zzz

Stellen Sie den Cert-Manager bereit.

Der nächste Schritt besteht darin, die neueste Version des Cert-Managers bereitzustellen. Für unsere Bereitstellung werden wir wieder Helm verwenden.

1. Fügen Sie das Helm-Repository hinzu.

$ helm repo add jetstack https://charts.jetstack.io "jetstack" wurde zu Ihren Repositories hinzugefügt 

2. Aktualisieren Sie das Repository.

$ helm repo update Warten Sie, während wir die neuesten Informationen aus Ihren Diagramm-Repositorys abrufen...
...Erfolgreich ein Update aus dem Diagramm-Repository „nginx-stable“ erhalten
...Erfolgreich ein Update aus dem Diagramm-Repository „jetstack“ erhalten
Update abgeschlossen. ⎈Viel Spaß beim Helmen!⎈ 

3. Stellen Sie den Cert-Manager bereit.

$ helm install cert-manager jetstack/cert-manager \ --namespace cert-manager --create-namespace \ --version v1.9.1 --set installCRDs=true NAME: cert-manager LETZTE BEREITSTELLUNG: Do., 1. September 2022, 16:01:52 Uhr NAMESPACE: cert-manager STATUS: bereitgestellt REVISION: 1 TESTSUITE: Keine HINWEISE: cert-manager v1.9.1 wurde erfolgreich bereitgestellt!

  Um mit der Ausstellung von Zertifikaten beginnen zu können, müssen Sie eine ClusterIssuer- oder Issuer-Ressource einrichten (beispielsweise durch Erstellen eines „Letsencrypt-Staging“-Ausstellers).

  Weitere Informationen zu den verschiedenen Arten von Herausgebern und deren Konfiguration finden Sie in unserer Dokumentation:
 https: //cert-manager.io/docs/configuration/
 Informationen zum Konfigurieren von cert-manager zur automatischen Bereitstellung von Zertifikaten für Ingress-Ressourcen finden Sie in der „ingress-shim“-Dokumentation:
 https: //cert-manager.io/docs/usage/ingress/

4. Validieren Sie die Bereitstellung.

$ kubectl get deployments --namespace cert-manager NAME                      BEREIT   AKTUELL   VERFÜGBAR   ALTER
cert-manager              1/1     1            1            4m30s
cert-manager-cainjector   1/1     1             1          4 Min. 30 Sek.
cert-manager-webhook      1/1     1             1            4 Min. 30 Sek. 

Bereitstellen des NGINX Cafe-Beispiels

Wir werden das NGINX Cafe-Beispiel verwenden, um unsere Backend-Bereitstellung und -Dienste bereitzustellen. Dies ist ein gängiges Beispiel, das in der von NGINX bereitgestellten Dokumentation verwendet wird. Wir werden Ingress in diesem Zusammenhang nicht bereitstellen.

1. Klonen Sie das NGINX Ingress GitHub-Projekt.

$ git clone https://github.com/nginxinc/kubernetes-ingress.git Klonen in „kubernetes-ingress“ …
Remote: Objekte aufzählen: 44979, erledigt.
Fernbedienung: Objekte zählen: 100 % (172/172), erledigt.
Remote: Komprimieren von Objekten: 100 % (108/108), erledigt.
Remote: Gesamt 44979 (Delta 87), wiederverwendet 120 (Delta 63), Pack-wiederverwendet 44807
Empfangene Objekte: 100 % (44979/44979), 60,27 MiB | 27,33 MiB/s, fertig.
  Auflösen von Deltas: 100 % (26508/26508), erledigt. 

2. Wechseln Sie in das Verzeichnis „Beispiele“. Dieses Verzeichnis enthält mehrere Beispiele, die verschiedene Konfigurationen des Ingress-Controllers demonstrieren. Wir verwenden das im Verzeichnis „complete-example“ bereitgestellte Beispiel.

$ cd ./kubernetes-ingress/beispiele/ingress-resources/vollständiges-beispiel 

3. Stellen Sie das NGINX Cafe-Beispiel bereit.

$ kubectl apply -f ./cafe.yaml
deployment.apps/coffee erstellt
service/coffee-svc erstellt
deployment.apps/tea erstellt
service/tea-svc erstellt

4. Validieren Sie die Bereitstellung und die Dienste mit dem Befehl „kubectl get“. Sie möchten sicherstellen, dass die Pods als BEREIT und die Dienste als ausgeführt angezeigt werden. Das folgende Beispiel zeigt eine repräsentative Auswahl dessen, was Sie suchen. Beachten Sie, dass der Kubernetes -Dienst ein Systemdienst ist, der im selben Namespace (Standard) ausgeführt wird wie das NGINX Cafe-Beispiel.

$ kubectl get deployments,services  --namespace default NAME                    BEREIT   AKTUELL   VERFÜGBAR   ALTER
deployment.apps/coffee   2/2     2            2           69s
deployment.apps/tea      3/3     3            3          68s
NAME                 TYP        CLUSTER-IP       EXTERNE-IP   PORT(S)   ALTER
service/coffee-svc   ClusterIP   10.128.154.225   <keine>        80/TCP    68s
service/kubernetes   ClusterIP   10.128.0.1       <keine>        443/TCP   29m
service/tea-svc      ClusterIP   10.128.96.145    <keine>        80/TCP    68s 

Bereitstellen des ClusterIssuer

Innerhalb des Cert-Managers kann der ClusterIssuer zum Ausstellen von Zertifikaten verwendet werden. Dies ist ein Cluster-Objekt, auf das von jedem Namespace verwiesen werden kann und das von allen Zertifikatsanforderungen mit der definierten Zertifikatsausstellenden Stelle verwendet werden kann. In diesem Beispiel können alle Zertifikatsanforderungen für Let’s Encrypt-Zertifikate von diesem ClusterIssuer bearbeitet werden.

Stellen Sie den ClusterIssuer für den von Ihnen ausgewählten Challenge-Typ bereit. Obwohl es den Rahmen dieses Beitrags sprengt, gibt es erweiterte Konfigurationsoptionen , mit denen Sie mehrere Resolver (ausgewählt basierend auf Auswahlfeldern) in Ihrem ClusterIssuer angeben können.

Grundlagen der ACME-Challenge

Mithilfe des ACME-Protokolls (Automated Certificate Management Environment) wird ermittelt, ob Sie Eigentümer eines Domänennamens sind und Ihnen daher ein Let’s Encrypt-Zertifikat ausgestellt werden kann. Für diese Herausforderung müssen folgende Parameter übergeben werden:

• Metadatenname : Der ClusterIssuer-Name, der innerhalb der Kubernetes-Installation eindeutig sein muss. Dieser Name wird später im Beispiel verwendet, wenn wir ein Zertifikat ausstellen.
• spec.acme.email : Dies ist die E-Mail-Adresse, mit der Sie sich zum Zweck der Zertifikatserstellung bei Let’s Encrypt registrieren. Dies sollte Ihre E-Mail sein.
• spec.acme.privateKeySecretRef : Dies ist der Name des Kubernetes-Geheimnisses, das Sie zum Speichern Ihres privaten Schlüssels verwenden.
• spec.acme.solvers : Dies sollte so belassen werden – es vermerkt den Typ der Herausforderung (oder, wie ACME es nennt, des Solvers), den Sie verwenden (HTTP-01 oder DNS-01), sowie die Ingress-Klasse, auf die es angewendet werden soll, in diesem Fall nginx.

Verwenden von HTTP-01

Dieses Beispiel zeigt, wie ein ClusterIssuer eingerichtet wird, um mit der HTTP-01-Challenge den Domänenbesitz nachzuweisen und ein Zertifikat zu erhalten.

1. Erstellen Sie den ClusterIssuer mit HTTP-01 für Herausforderungen.

$ cat << EOF | kubectl apply -f apiVersion: cert-manager.io/v1
Art: ClusterIssuer
Metadaten:
  Name: prod-issuer
Spezifikation:
  acme:
    E-Mail: example@example.com
    Server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      Name: prod-issuer-account-key
    Solver:
    - http01:
       Ingress:
         Klasse: nginx
EOF
clusterissuer.cert-manager.io/prod-issuer erstellt 

2. Validieren Sie den ClusterIssuer (er sollte als bereit angezeigt werden).

$ kubectl get clusterissuer NAME          BEREIT   ALTER
prod-issuer   True    34s 

Verwenden von DNS-01

Dieses Beispiel zeigt, wie Sie einen ClusterIssuer einrichten, um die DNS-01-Challenge zur Authentifizierung Ihres Domänenbesitzes zu verwenden. Abhängig von Ihrem DNS-Anbieter müssen Sie wahrscheinlich ein Kubernetes-Geheimnis verwenden, um Ihr Token zu speichern. In diesem Beispiel wird Cloudflare verwendet. Beachten Sie die Verwendung von Namespaces. Die Cert-Manager-Anwendung, die im Cert-Manager-Namespace bereitgestellt wird, muss Zugriff auf das Geheimnis haben.

Für dieses Beispiel benötigen Sie ein Cloudflare-API-Token , das Sie von Ihrem Konto aus erstellen können. Dies muss in die Zeile weiter unten eingefügt werden. Wenn Sie Cloudflare nicht verwenden, müssen Sie die Dokumentation Ihres Anbieters befolgen .

1. Erstellen Sie ein Geheimnis für das API-Token.

$ cat << EOF | kubectl apply -f apiVersion: v1
Art: Geheim
Metadaten:
  Name: cloudflare-api-token-secret
  Namespace: cert-manager
Typ: Undurchsichtig
stringData:
  api-token: <API-Token> 
EOF 

2. Erstellen Sie den Aussteller mit DNS-01 für Herausforderungen.

$ cat << EOF | kubectl apply -f apiVersion: cert-manager.io/v1
Art: ClusterIssuer
Metadaten:
  Name: Prod-Issuer
Spezifikation:
  Acme:
    E-Mail: example@example.com
    Server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      Name: Prod-Issuer-Account-Schlüssel
    Solver:
      - DNS01:
           Cloudflare:
             apiTokenSecretRef:
              Name: cloudflare-api-token-secret
              Schlüssel: API-Token
EOF 

3. Bestätigen Sie den Aussteller (er sollte als bereit angezeigt werden).

$ kubectl get clusterissuer NAME          BEREIT   ALTER
prod-issuer   True    31 m 

Bereitstellen des Ingress

Dies ist der Punkt, auf den wir hingearbeitet haben – die Bereitstellung der Ingress-Ressource für unsere Anwendung. Dadurch wird der Datenverkehr in die NGINX Cafe-Anwendung umgeleitet, die wir zuvor bereitgestellt haben.

Verwenden des Kubernetes Ingress

Wenn Sie die standardmäßige Kubernetes-Ingress-Ressource verwenden, konfigurieren Sie Ingress mit dem folgenden Bereitstellungs-YAML und fordern Sie ein Zertifikat an.

API-Version: networking.k8s.io/v1 Art: Ingress 
Metadaten: 
  Name: cafe-ingress 
  Anmerkungen: 
    cert-manager.io/cluster-issuer: prod-issuer 
    acme.cert-manager.io/http01-edit-in-place: „true“ 
Spezifikation: 
  ingressClassName: nginx 
  tls: 
  - Hosts: 
    - cert.example.com 
    secretName: cafe-secret 
  Regeln: 
  - Host: cert.example.com 
    http: 
      Pfade: 
      - Pfad: /tea 
        Pfadtyp: Präfix 
        Backend: 
          Dienst: 
            Name: tea-svc 
             Port: 
              Nummer: 80 
      - Pfad: /Kaffee 
        Pfadtyp: Präfix 
        Backend: 
          Dienst: 
            Name: coffee-svc 
            Port: 
Nummer: 80 

Es lohnt sich, einige wichtige Teile des Manifests noch einmal durchzugehen:

• Die aufgerufene API ist der Standard-Kubernetes-Ingress.
• Ein wichtiger Teil dieser Konfiguration befindet sich unter metadata.annotations , wo wir acme.cert-manager.io/http01-edit-in-place auf „true“ setzen. Dieser Wert ist erforderlich und passt die Art und Weise an, in der die Herausforderung bedient wird. Weitere Informationen finden Sie im Dokument „Unterstützte Anmerkungen“ . Dies kann auch durch die Verwendung eines Master/Minion-Setups bewältigt werden.
• Der spec.ingressClassName bezieht sich auf den NGINX-Ingress-Controller, den wir installiert haben und verwenden werden.
• Die Kubernetes Secret-Ressource spec.tls.secret speichert den Zertifikatsschlüssel, der zurückgegeben wird, wenn das Zertifikat von Let’s Encrypt ausgestellt wird.
• Unser Hostname cert.example.com ist für spec.tls.hosts und spec.rules.host angegeben. Dies ist der Hostname, für den unser ClusterIssuer das Zertifikat ausgestellt hat.
• Der Abschnitt spec.rules.http definiert die Pfade und die Backend-Dienste, die Anfragen auf diesen Pfaden verarbeiten. Beispielsweise wird der Datenverkehr zu /tea an Port 80 des tea-svc umgeleitet.

1. Ändern Sie das obige Manifest für Ihre Installation. Dies erfordert mindestens eine Änderung der Werte spec.rules.host und spec.tls.hosts , Sie sollten jedoch alle Parameter in der Konfiguration überprüfen.
2. Wenden Sie das Manifest an.

$  kubectl apply -f ./cafe-virtual-server.yaml virtualserver.k8s.nginx.org/cafe erstellt 

3. Warten Sie, bis das Zertifikat ausgestellt wurde. Sie suchen nach einem Wert von „True“ für das Feld READY.

$ kubectl get certificates NAME                                      BEREIT   GEHEIM          ALTER
certificate.cert-manager.io/cafe-secret   True    cafe-secret   37 m 

Verwenden des virtuellen NGINX-Servers / virtueller Routen

Wenn Sie die NGINX-CRDs verwenden, müssen Sie zum Konfigurieren Ihres Ingress das folgende Bereitstellungs-YAML verwenden.

  apiVersion: k8s.nginx.org/v1 
Art: VirtualServer 
Metadaten: 
  Name: Café 
Spezifikation: 
  Host: cert.example.com 
  TLS: 
    Geheimnis: Café-Geheimnis 
    Zertifikatsmanager: 
      Cluster-Aussteller: Produkt-Aussteller 
  Upstreams: 
  - Name: Tea 
    Dienst: Tea-SVC 
    Port: 80 
  - Name: Kaffee 
    Dienst: Kaffee-Service 
    Port: 80 
  Routen: 
  - Pfad: /Tee 
    Aktion: 
      Pass: Tee 
  - Pfad: /Kaffee 
    Aktion: 
Pass: Kaffee

Es lohnt sich, einige wichtige Teile des Manifests noch einmal durchzugehen:

• Die aufgerufene API ist die NGINX-spezifische k8s.nginx.org/v1 für die VirtualServer-Ressource.
• Die Kubernetes Secret-Ressource spec.tls.secret speichert den Zertifikatsschlüssel, der zurückgegeben wird, wenn das Zertifikat von Let’s Encrypt ausgestellt wird.
• Unser Hostname cert.example.com ist für spec.host angegeben. Dies ist der Hostname, für den unser ClusterIssuer das Zertifikat ausgestellt hat.
• Die spec.upstreams -Werte verweisen auf unsere Backend-Dienste, einschließlich der Ports.
• Die spec.routes definieren sowohl die Route als auch die Aktion, die ausgeführt werden soll, wenn diese Routen erreicht werden.

1. Ändern Sie das obige Manifest für Ihre Installation. Dies erfordert mindestens eine Änderung des spec.host -Werts, Sie sollten jedoch alle Parameter in der Konfiguration überprüfen.
2. Wenden Sie das Manifest an.

$  kubectl apply -f ./cafe-virtual-server.yaml virtualserver.k8s.nginx.org/cafe erstellt 

3. Warten Sie, bis das Zertifikat ausgestellt wurde. Sie sollten den Status „Gültig“ sehen.

$ kubectl get VirtualServers NAME   STATE   HOST                    IP              PORTS      ALTER
cafe   Gültig   cert.example.com   www.xxx.yyy.zzz   [80,443]   51m 

Zertifikat ansehen

Sie können das Zertifikat über die Kubernetes-API anzeigen. Dort werden Ihnen Details zum Zertifikat angezeigt, einschließlich seiner Größe und des zugehörigen privaten Schlüssels.

$ kubectl describe secret cafe-secret Name:         cafe-secret
Namespace:    Standard
Labels:       <keine>
Anmerkungen:  cert-manager.io/alt-names: cert.example.com
                cert-manager.io/certificate-name: Café-Geheimnis
                cert-manager.io/allgemeiner-name: cert.example.com
                cert-manager.io/ip-sans:
                cert-manager.io/ausstellergruppe:
                cert-manager.io/aussteller-kind: ClusterIssuer cert-manager.io/issuer-name : prod-issuer cert-manager.io/uri-sans :Typ: kubernetes.io/tls Daten ==== tls.crt:  5607 Bytes tls.key:  1675 Byte 

Wenn Sie das tatsächliche Zertifikat und den Schlüssel sehen möchten, können Sie dies tun, indem Sie den folgenden Befehl ausführen. (Notiz: Dies veranschaulicht eine Schwäche der Kubernetes Secrets. Sie können nämlich von jedem gelesen werden, der über die erforderlichen Zugriffsberechtigungen verfügt.)

$ kubectl get secret cafe-secret -o yaml

Testen des Ingress

Testen Sie die Zertifikate. Sie können hier jede gewünschte Methode verwenden. Das folgende Beispiel verwendet cURL . Der Erfolg wird durch einen Block ähnlich dem zuvor gezeigten angezeigt, der den Servernamen, die interne Adresse des Servers, das Datum, die gewählte URI (Route) (Kaffee oder Tee) und die Anforderungs-ID enthält. Fehler werden in Form von HTTP-Fehlercodes angezeigt, höchstwahrscheinlich 400 oder 301.

$ curl https://cert.example.com/tea
Serveradresse: 10.2.0.6:8080
Servername: tea-5c457db9-l4pvq
Datum: 02.09.2022:15:21:06 +0000
URI: /tea
Anfrage-ID: d736db9f696423c6212ffc70cd7ebecf
$ curl https://cert.example.com/coffee
Serveradresse: 10.2.2.6:8080
Servername: coffee-7c86d7d67c-kjddk
Datum: 02.09.2022:15:21:10 +0000
URI: /coffee
Anforderungs-ID: 4ea3aa1c87d2f1d80a706dde91f31d54 

Zertifikatserneuerungen

Wir haben zu Beginn versprochen, dass mit diesem Ansatz die Notwendigkeit entfallen würde, Zertifikatserneuerungen zu verwalten. Wir müssen jedoch noch erklären, wie das geht. Warum? Weil dies ein zentraler, integrierter Bestandteil des Cert-Managers ist. Wenn cert-manager in diesem automatischen Prozess feststellt, dass ein Zertifikat nicht vorhanden ist, abgelaufen ist, innerhalb von 15 Tagen abläuft oder wenn der Benutzer über die CLI ein neues Zertifikat anfordert, wird automatisch ein neues Zertifikat angefordert . Viel einfacher geht es nicht.

Häufig gestellte Fragen

Was ist mit NGINX Plus?

Wenn Sie ein NGINX Plus-Abonnent sind, besteht der einzige Unterschied für Sie darin, den NGINX Ingress Controller zu installieren. Anweisungen zum Ändern des oben angegebenen Helm-Befehls, um dies zu erreichen, finden Sie im Abschnitt „Installation Helm“ der NGINX-Dokumente.

Welchen Herausforderungstyp sollte ich verwenden?

Dies hängt weitgehend von Ihrem Anwendungsfall ab.

Die HTTP-01-Challenge-Methode erfordert, dass Port 80 für das Internet geöffnet ist und dass der DNS-A-Eintrag ordnungsgemäß für die IP-Adresse des Ingress-Controllers konfiguriert wurde. Dieser Ansatz erfordert außer zum Erstellen des A-Eintrags keinen Zugriff auf den DNS-Anbieter.

Die DNS-01-Challenge-Methode kann verwendet werden, wenn Sie Port 80 nicht dem Internet zugänglich machen können. Sie erfordert lediglich, dass der Zertifikatsmanager über ausgehenden Zugriff auf den DNS-Anbieter verfügt. Allerdings erfordert diese Methode, dass Sie Zugriff auf die API Ihres DNS-Anbieters haben, wobei die erforderliche Zugriffsebene je nach Anbieter unterschiedlich ist.

Wie behebe ich Probleme?

Aufgrund der enormen Komplexität von Kubernetes ist es schwierig, gezielte Informationen zur Fehlerbehebung bereitzustellen. Wenn Sie auf Probleme stoßen, laden wir Sie ein, uns im NGINX Community Slack zu fragen (NGINX Plus-Abonnenten können ihre normalen Supportoptionen nutzen).

Legen Sie noch heute los

Fordern Sie zunächst Ihre kostenlose 30-Tage-Testversion von NGINX Ingress Controller mit NGINX App Protect WAF und DoS an und laden Sie das stets kostenlose NGINX Service Mesh herunter .