Automatisierung der Zertifikatsverwaltung in einer Kubernetes-Umgebung

NGINX | 05. Oktober 2022

Gültige SSL/TLS-Zertifikate sind eine Grundvoraussetzung für moderne Anwendungslandschaften. Leider wird die Verwaltung von Zertifikatsverlängerungen bei der Bereitstellung einer Anwendung häufig erst nachträglich bedacht. Zertifikate haben eine begrenzte Gültigkeitsdauer, die von etwa 13 Monaten für Zertifikate von DigiCert bis zu 90 Tagen für Zertifikate von Let’s Encrypt reicht. Um einen sicheren Zugriff aufrechtzuerhalten, müssen diese Zertifikate vor Ablauf ihrer Gültigkeit verlängert bzw. neu ausgestellt werden. Angesichts der hohen Arbeitsbelastung der meisten Betriebsteams wird die Zertifikatsverlängerung mitunter übersehen, sodass hektisch reagiert werden muss, wenn das Ablaufdatum näher rückt oder – schlimmer noch – bereits überschritten ist.

Das muss nicht so sein. Mit etwas Planung und Vorbereitung lässt sich die Zertifikatsverwaltung automatisieren und optimieren. Im Folgenden betrachten wir eine Lösung für Kubernetes, die drei Technologien nutzt:

In diesem Blog erfahren Sie, wie Sie die Zertifikatsverwaltung vereinfachen, indem Sie Ihren Endpunkten individuelle Zertifikate bereitstellen, die automatisch verlängert und aktualisiert werden.

Zertifikate in einer Kubernetes-Umgebung

Bevor wir auf die technischen Details eingehen, müssen wir einige Begriffe definieren. Der Begriff „TLS-Zertifikat“ bezeichnet zwei Komponenten, die erforderlich sind, um HTTPS-Verbindungen auf unserem Ingress-Controller zu ermöglichen:

Das Zertifikat
Der private Schlüssel

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

In Kubernetes werden diese beiden Komponenten als „Secrets“ gespeichert. Kubernetes-Workloads – wie der NGINX Ingress Controller und cert-manager – können diese Secrets schreiben und lesen. Sie können außerdem von Benutzern verwaltet werden, die Zugriff auf die Kubernetes-Installation haben.

Einführung in cert-manager

Das Projekt cert-manager ist ein Zertifikatscontroller, der mit Kubernetes und OpenShift funktioniert. Bei der Bereitstellung in Kubernetes stellt cert-manager automatisch die von Ingress-Controllern benötigten Zertifikate aus und sorgt dafür, dass sie gültig und auf dem neuesten Stand sind. Darüber hinaus überwacht er die Ablaufdaten der Zertifikate und versucht, sie in einem konfigurierten Zeitintervall zu erneuern. Obwohl er mit zahlreichen öffentlichen und privaten Ausstellern funktioniert, zeigen wir hier seine Integration mit Let’s Encrypt.

Zwei Challenge-Typen

Bei der Verwendung von Let’s Encrypt wird die gesamte Zertifikatsverwaltung automatisch durchgeführt. Das ist zwar sehr komfortabel, wirft aber auch eine Frage auf: Wie stellt der Dienst sicher, dass Sie der Inhaber des betreffenden vollqualifizierten Domainnamens (FQDN) sind?

Dieses Problem wird mithilfe einer Challenge gelöst. Dabei müssen Sie eine Verifizierungsanfrage beantworten, die nur jemand mit Zugriff auf die DNS-Einträge der betreffenden Domain beantworten kann. Challenges gibt es in zwei Formen:

HTTP-01: Diese Challenge kann beantwortet werden, indem ein DNS-Eintrag für den FQDN vorhanden ist, für den Sie ein Zertifikat ausstellen. Wenn Ihr Server beispielsweise unter der IP-Adresse www.xxx.yyy.zzz erreichbar ist und Ihr FQDN cert.example.com lautet, stellt der Challenge-Mechanismus auf dem Server unter www.xxx.yyy.zzz ein Token bereit, und die Server von Let’s Encrypt versuchen, über cert.example.com darauf zuzugreifen. Bei Erfolg gilt die Challenge als bestanden und das Zertifikat wird ausgestellt. HTTP-01 ist die einfachste Methode zum Erstellen eines Zertifikats, da kein direkter Zugriff auf den DNS-Anbieter erforderlich ist. Diese Art von Challenge wird immer über Port 80 (HTTP) durchgeführt. Beachten Sie, dass cert-manager bei HTTP-01-Challenges den Ingress-Controller verwendet, um das Challenge-Token bereitzustellen.

DNS-01: Bei dieser Challenge wird ein DNS-TXT-Eintrag mit einem Token erstellt, das anschließend vom Aussteller überprüft wird. Wird das Token erkannt, haben Sie nachgewiesen, dass Sie Eigentümer dieser Domain sind, und können nun Zertifikate für deren Einträge ausstellen. Anders als bei der HTTP-01-Challenge muss der FQDN bei Verwendung der DNS-01-Challenge nicht zur IP-Adresse Ihres Servers aufgelöst werden (und nicht einmal existieren). Darüber hinaus kann DNS-01 verwendet werden, wenn Port 80 blockiert ist. Der Nachteil dieser einfachen Handhabung besteht darin, dass der cert-manager-Installation über ein API-Token Zugriff auf Ihre DNS-Infrastruktur gewährt werden muss.

Ingress-Controller

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

Weitere Informationen zu Ingress-Controllern finden Sie in den folgenden Blogbeiträgen:

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

Beispiele für die Zertifikatsverwaltung

Diese Beispiele setzen voraus, dass Sie über eine funktionsfähige 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). Außerdem wird vorausgesetzt, dass Sie Datenverkehr sowohl über Port 80 als auch über Port 443 empfangen können (bei Verwendung der HTTP-01-Challenge) oder ausschließlich über Port 443 (bei Verwendung der DNS-01-Challenge). Diese Beispiele werden anhand von Mac OS X veranschaulicht, können jedoch auch unter Linux oder WSL verwendet werden.

Sie benötigen außerdem einen DNS-Anbieter und einen FQDN, für den Sie den A-Record anpassen können. Wenn Sie die HTTP-01-Challenge verwenden, müssen Sie lediglich einen A-Record hinzufügen können (oder ihn für sich 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.

NGINX Ingress Controller bereitstellen

Am einfachsten ist die Bereitstellung über Helm. Mit dieser Bereitstellung können Sie sowohl Kubernetes Ingress als auch die NGINX Virtual Server CRD verwenden.

Fügen Sie das NGINX-Repository hinzu.

$ helm repo add nginx-stable https://helm.nginx.com/stable  "nginx-stable" has been added to your repositories

Aktualisieren Sie das Repository.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  Update Complete. ⎈Happy Helming!⎈

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
  LAST DEPLOYED: Thu Sep  1 15:58:15 2022
  NAMESPACE: nginx-ingress
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The NGINX Ingress Controller has been installed.

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

$ kubectl get deployments --namespace nginx-ingress  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-kic-nginx-ingress   1/1     1            1           23s
  $ kubectl get services --namespace nginx-ingress
  NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
  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 genaue Ablauf hängt von Ihrem DNS-Anbieter ab. Dieser DNS-Name muss von den Let’s-Encrypt-Servern aufgelöst werden können. Daher müssen Sie möglicherweise warten, bis sich der Eintrag verbreitet hat, bevor er funktioniert. Weitere Informationen hierzu finden Sie im SiteGround-Artikel „Was ist DNS-Propagation und warum dauert sie so lange?“

Sobald sich der von Ihnen gewählte FQDN auflösen lässt, können Sie mit dem nächsten Schritt fortfahren.

$ host cert.example.com  cert.example.com has address www.xxx.yyy.zzz

cert-manager bereitstellen

Im nächsten Schritt wird die neueste Version von cert-manager bereitgestellt. Auch hierfür verwenden wir Helm.

Fügen Sie das Helm-Repository hinzu.

$ helm repo add jetstack https://charts.jetstack.io  "jetstack" has been added to your repositories

Aktualisieren Sie das Repository.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  ...Successfully got an update from the "jetstack" chart repository
  Update Complete. ⎈Happy Helming!⎈

cert-manager bereitstellen.

$ helm install cert-manager jetstack/cert-manager \  --namespace cert-manager --create-namespace \
  --version v1.9.1  --set installCRDs=true 
  NAME: cert-manager
  LAST DEPLOYED: Thu Sep  1 16:01:52 2022 
  NAMESPACE: cert-manager
  STATUS: deployed
  REVISION: 1 
  TEST SUITE: None
  NOTES:
  cert-manager v1.9.1 has been deployed successfully!
  In order to begin issuing certificates, you will need to set up a ClusterIssuer
  or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
  More information on the different types of issuers and how to configure them
  can be found in our documentation:
  https://cert-manager.io/docs/configuration/ For information on how to configure cert-manager to automatically provision
  Certificates for Ingress resources, take a look at the `ingress-shim`
  documentation:
  https://cert-manager.io/docs/usage/ingress/

Validieren Sie die Bereitstellung.

$ kubectl get deployments --namespace cert-manager  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  cert-manager              1/1     1            1           4m30s
  cert-manager-cainjector   1/1     1            1           4m30s
  cert-manager-webhook      1/1     1            1           4m30s

NGINX-Cafe-Beispiel bereitstellen

Wir verwenden das NGINX-Cafe-Beispiel, um unser Backend-Deployment und unsere Services bereitzustellen. Dieses Beispiel wird häufig in der von NGINX bereitgestellten Dokumentation verwendet. Ingress wird dabei nicht bereitgestellt.

Klonen Sie das NGINX-Ingress-GitHub-Projekt.

$ git clone https://github.com/nginxinc/kubernetes-ingress.git  Cloning into 'kubernetes-ingress'...
  remote: Enumerating objects: 44979, done.
  remote: Counting objects: 100% (172/172), done.
  remote: Compressing objects: 100% (108/108), done.
  remote: Total 44979 (delta 87), reused 120 (delta 63), pack-reused 44807
  Receiving objects: 100% (44979/44979), 60.27 MiB | 27.33 MiB/s, done.
  Resolving deltas: 100% (26508/26508), done.

Wechseln Sie in das Verzeichnis „examples“. Dieses Verzeichnis enthält mehrere Beispiele, die verschiedene Konfigurationen des Ingress-Controllers veranschaulichen. Wir verwenden das Beispiel aus dem Verzeichnis „complete-example“.

$ cd ./kubernetes-ingress/examples/ingress-resources/complete-example

Stellen Sie das NGINX-Cafe-Beispiel bereit.

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

Validieren Sie das Deployment und die Services mit dem Befehl kubectl get. Stellen Sie sicher, dass die Pods als READY und die Services als running angezeigt werden. Das folgende Beispiel zeigt eine repräsentative Ausgabe. Beachten Sie, dass der kubernetes-Service ein Systemdienst ist, der im selben Namespace (default) wie das NGINX-Cafe-Beispiel ausgeführt wird.

$ kubectl get deployments,services  --namespace default  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/coffee   2/2     2            2           69s
  deployment.apps/tea      3/3     3            3           68s
NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
  service/coffee-svc   ClusterIP   10.128.154.225   <none>        80/TCP    68s
  service/kubernetes   ClusterIP   10.128.0.1       <none>        443/TCP   29m
	service/tea-svc      ClusterIP   10.128.96.145    <none>        80/TCP    68s

ClusterIssuer bereitstellen

In cert-manager kann der ClusterIssuer zum Ausstellen von Zertifikaten verwendet werden. Dabei handelt es sich um ein clusterweites Objekt, auf das von jedem Namespace verwiesen werden kann und das für alle Zertifikatsanforderungen mit der definierten Zertifizierungsstelle verwendet werden kann. In diesem Beispiel können alle Anforderungen für Let’s-Encrypt-Zertifikate von diesem ClusterIssuer verarbeitet werden.

Stellen Sie den ClusterIssuer für den ausgewählten Challenge-Typ bereit. Auch wenn dies den Rahmen dieses Beitrags sprengt, gibt es erweiterte Konfigurationsoptionen, mit denen Sie in Ihrem ClusterIssuer mehrere Resolver angeben können, die anhand von Selektorfeldern ausgewählt werden.

Grundlagen der ACME-Challenge

Das Protokoll „Automated Certificate Management Environment“ (ACME) wird verwendet, um festzustellen, ob Sie Inhaber eines Domainnamens sind und Ihnen daher ein Let’s-Encrypt-Zertifikat ausgestellt werden kann. Für diese Challenge müssen die folgenden Parameter übergeben werden:

metadata.name: Der Name des ClusterIssuers, 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 bei Let’s Encrypt registrieren, um Zertifikate zu erstellen. Verwenden Sie hierfür Ihre eigene E-Mail-Adresse.
spec.acme.privateKeySecretRef: Dies ist der Name des Kubernetes-Secrets, in dem Sie Ihren privaten Schlüssel speichern.
spec.acme.solvers: Dies sollte unverändert bleiben – hier werden der verwendete Challenge-Typ (oder, wie ACME ihn bezeichnet, Solver), also HTTP-01 oder DNS-01, sowie die Ingress-Klasse angegeben, auf die er angewendet werden soll. In diesem Fall ist das nginx.

HTTP-01 verwenden

Dieses Beispiel zeigt, wie Sie einen ClusterIssuer für die Verwendung der HTTP-01-Challenge konfigurieren, um den Besitz der Domain nachzuweisen und ein Zertifikat zu erhalten.

Erstellen Sie den ClusterIssuer, der HTTP-01 für Challenges verwendet.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
      - http01:
         ingress:
           class: nginx
  EOF
  clusterissuer.cert-manager.io/prod-issuer created

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

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    34s

DNS-01 verwenden

Dieses Beispiel zeigt, wie Sie einen ClusterIssuer so konfigurieren, dass er die DNS-01-Challenge zur Bestätigung Ihrer Domaininhaberschaft verwendet. Abhängig von Ihrem DNS-Anbieter müssen Sie wahrscheinlich ein Kubernetes Secret verwenden, um Ihr Token zu speichern. In diesem Beispiel wird Cloudflare verwendet. Beachten Sie die Verwendung des Namespace. Die Anwendung cert-manager, die im Namespace cert-manager bereitgestellt wird, benötigt Zugriff auf das Secret.

Für dieses Beispiel benötigen Sie ein Cloudflare-API-Token, das Sie in Ihrem Konto erstellen können. Dieses müssen Sie unten in die Zeile <API Token> einfügen. Wenn Sie Cloudflare nicht verwenden, müssen Sie die Dokumentation Ihres Anbieters befolgen.

Erstellen Sie ein Secret für das API-Token.

$ cat << EOF | kubectl apply -f   apiVersion: v1
  kind: Secret
  metadata:
    name: cloudflare-api-token-secret
    namespace: cert-manager
  type: Opaque
  stringData:
    api-token: <API Token> 
  EOF

Erstellen Sie den Aussteller und verwenden Sie DNS-01 für die Challenges.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
        - dns01:
            cloudflare:
              apiTokenSecretRef:
                name: cloudflare-api-token-secret
                key: api-token
  EOF

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

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    31m

Ingress bereitstellen

Jetzt sind wir an dem Punkt angelangt, auf den wir hingearbeitet haben: der Bereitstellung der Ingress-Ressource für unsere Anwendung. Dadurch wird der Datenverkehr an die zuvor bereitgestellte NGINX-Cafe-Anwendung weitergeleitet.

Verwenden des Kubernetes-Ingress

Wenn Sie die standardmäßige Kubernetes-Ingress-Ressource verwenden, nutzen Sie das folgende Deployment-YAML, um den Ingress zu konfigurieren und ein Zertifikat anzufordern.

apiVersion: networking.k8s.io/v1   kind: Ingress 
  metadata: 
    name: cafe-ingress 
    annotations: 
      cert-manager.io/cluster-issuer: prod-issuer 
      acme.cert-manager.io/http01-edit-in-place: "true" 
  spec: 
    ingressClassName: nginx 
    tls: 
    - hosts: 
      - cert.example.com 
      secretName: cafe-secret 
    rules: 
    - host: cert.example.com 
      http: 
        paths: 
        - path: /tea 
          pathType: Prefix 
          backend: 
            service: 
              name: tea-svc 
              port: 
                number: 80 
        - path: /coffee 
          pathType: Prefix 
          backend: 
            service: 
              name: coffee-svc 
              port: 
number: 80

Es lohnt sich, einige wichtige Teile des Manifests genauer zu betrachten:

Die aufgerufene API ist der standardmäßige Kubernetes Ingress.
Ein wichtiger Teil dieser Konfiguration befindet sich unter „metadata.annotations“. Dort setzen wir „acme.cert-manager.io/http01-edit-in-place“ auf „true“. Dieser Wert ist erforderlich und passt die Bereitstellung der Challenge an. Weitere Informationen finden Sie im Dokument „Unterstützte Annotationen“. Dies kann auch mithilfe einer Master/Minion-Konfiguration umgesetzt werden.
Der spec.ingressClassName verweist 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. Für diesen Hostnamen hat unser ClusterIssuer das Zertifikat ausgestellt.
Der Abschnitt „spec.rules.http“ definiert die Pfade und die Backend-Services, die Anfragen auf diesen Pfaden verarbeiten. Beispielsweise wird Datenverkehr an „/tea“ an Port 80 des Services „tea-svc“ weitergeleitet.

Passen Sie das obige Manifest an Ihre Installation an. Dazu müssen Sie mindestens die Werte spec.rules.host und spec.tls.hosts ändern. Sie sollten jedoch alle Parameter in der Konfiguration überprüfen.
Wenden Sie das Manifest an.

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

Warten Sie, bis das Zertifikat ausgestellt wurde. Das Feld READY sollte den Wert „True“ aufweisen.

$ kubectl get certificates  NAME                                      READY   SECRET        AGE
  certificate.cert-manager.io/cafe-secret   True    cafe-secret   37m

Verwenden von NGINX Virtual Server / Virtual Routes

Wenn Sie die NGINX-CRDs verwenden, müssen Sie das folgende Deployment-YAML verwenden, um Ihren Ingress zu konfigurieren.

  apiVersion: k8s.nginx.org/v1 
  kind: VirtualServer 
  metadata: 
    name: cafe 
  spec: 
    host: cert.example.com 
    tls: 
      secret: cafe-secret 
      cert-manager: 
        cluster-issuer: prod-issuer 
    upstreams: 
      - name: tea 
        service: tea-svc 
        port: 80 
      - name: coffee 
        service: coffee-svc 
        port: 80 
    routes: 
      - path: /tea 
        action: 
          pass: tea 
      - path: /coffee 
        action: 
          pass: coffee

Auch hier lohnt es sich, einige wichtige Teile des Manifests genauer anzusehen:

Die aufgerufene API ist die NGINX-spezifische API 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 wird für spec.host angegeben. Dies ist der Hostname, für den unser ClusterIssuer das Zertifikat ausgestellt hat.
Die Werte unter „spec.upstreams“ verweisen auf unsere Backend-Dienste einschließlich der Ports.
Die spec.routes definiert sowohl die Route als auch die Aktion, die beim Aufruf dieser Routen ausgeführt werden soll.

Passen Sie das obige Manifest an Ihre Installation an. Dazu müssen Sie mindestens den Wert von „spec.host“ ändern. Sie sollten jedoch alle Parameter in der Konfiguration überprüfen.
Wenden Sie das Manifest an.

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

Warten Sie, bis das Zertifikat ausgestellt wurde. Der Status sollte „Gültig“ lauten.

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

Zertifikat anzeigen

Sie können das Zertifikat über die Kubernetes-API anzeigen. Dabei werden Details zum Zertifikat angezeigt, darunter seine Größe und der zugehörige private Schlüssel.

$ kubectl describe secret cafe-secret  Name:         cafe-secret
  Namespace:    default
  Labels:       <none>
  Annotations:  cert-manager.io/alt-names: cert.example.com
                cert-manager.io/certificate-name: cafe-secret
                cert-manager.io/common-name: cert.example.com
                cert-manager.io/ip-sans:
                cert-manager.io/issuer-group:
                cert-manager.io/issuer-kind: ClusterIssuer
                cert-manager.io/issuer-name: prod-issuer
                cert-manager.io/uri-sans:Type:  kubernetes.io/tlsData
  ====
  tls.crt:  5607 bytes
  tls.key:  1675 bytes

Wenn Sie das eigentliche Zertifikat und den Schlüssel anzeigen möchten, können Sie dazu den folgenden Befehl ausführen. (Hinweis: Dies verdeutlicht eine Schwachstelle von Kubernetes Secrets: Jeder mit den erforderlichen Zugriffsberechtigungen kann sie auslesen.)

$ kubectl get secret cafe-secret -o yaml

Ingress testen

Testen Sie die Zertifikate. Sie können hierfür eine beliebige Methode verwenden. Im folgenden Beispiel wird cURL verwendet. Ein erfolgreicher Test wird durch einen Block ähnlich dem zuvor gezeigten angezeigt. Dieser enthält den Servernamen, die interne Adresse des Servers, das Datum, den ausgewählten URI (die Route „coffee“ oder „tea“) und die Anfrage-ID. Bei Fehlern werden HTTP-Fehlercodes ausgegeben, höchstwahrscheinlich 400 oder 301.

$ curl https://cert.example.com/tea
  Server address: 10.2.0.6:8080
  Server name: tea-5c457db9-l4pvq
  Date: 02/Sep/2022:15:21:06 +0000
  URI: /tea
  Request ID: d736db9f696423c6212ffc70cd7ebecf
  $ curl https://cert.example.com/coffee
  Server address: 10.2.2.6:8080
  Server name: coffee-7c86d7d67c-kjddk
  Date: 02/Sep/2022:15:21:10 +0000
  URI: /coffee
Request ID: 4ea3aa1c87d2f1d80a706dde91f31d54

Zertifikatserneuerungen

Zu Beginn haben wir versprochen, dass bei diesem Ansatz Zertifikatserneuerungen nicht mehr verwaltet werden müssen. Allerdings haben wir noch nicht erklärt, wie das funktioniert. Warum? Weil dies eine zentrale, integrierte Funktion von cert-manager ist. Bei diesem automatischen Prozess wird, sobald cert-manager feststellt, dass ein Zertifikat nicht vorhanden oder abgelaufen ist, innerhalb der nächsten 15 Tage abläuft oder der Benutzer über die CLI ein neues Zertifikat anfordert, automatisch ein neues Zertifikat angefordert. Einfacher geht es kaum.

Häufig gestellte Fragen

Was ist mit NGINX Plus?

Wenn Sie NGINX Plus abonniert haben, besteht der einzige Unterschied für Sie in der Installation des NGINX Ingress Controllers. Im Abschnitt „Installation mit Helm“ der NGINX-Dokumentation erfahren Sie, wie Sie den oben angegebenen Helm-Befehl entsprechend anpassen.

Welchen Challenge-Typ sollte ich verwenden?

Das hängt weitgehend von Ihrem Anwendungsfall ab.

Die HTTP-01-Challenge-Methode setzt voraus, dass Port 80 über das Internet erreichbar ist und der DNS-A-Record ordnungsgemäß für die IP-Adresse des Ingress-Controllers konfiguriert wurde. Bei diesem Ansatz ist außer zum Erstellen des A-Records kein Zugriff auf den DNS-Anbieter erforderlich.

Die DNS-01-Challenge-Methode kann verwendet werden, wenn Sie Port 80 nicht für das Internet freigeben können. Sie setzt lediglich voraus, dass der cert-manager ausgehenden Zugriff auf den DNS-Anbieter hat. Allerdings benötigen Sie für diese Methode Zugriff auf die API Ihres DNS-Anbieters, wobei der erforderliche Umfang der Zugriffsrechte je nach Anbieter variiert.

Wie behebe ich Probleme?

Da Kubernetes sehr komplex ist, ist es schwierig, gezielte Informationen zur Fehlerbehebung bereitzustellen. Sollten Probleme auftreten, können Sie uns gerne im NGINX Community Slack fragen (Abonnenten von NGINX Plus können ihre üblichen 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 die dauerhaft kostenlose NGINX Service Mesh herunter.