Citrix ADC Ingress Controller

Stellen Sie die HTTPS-Webanwendung auf Kubernetes mit dem Citrix Ingress Controller bereit und lassen Sie uns mit cert-manager verschlüsseln

Let’s Encrypt und das ACME-Protokoll (Automatic Certificate Management Environment) ermöglicht es Ihnen, einen HTTPS-Server einzurichten und automatisch ein vom Browser vertrauenswürdiges Zertifikat zu erhalten. Um ein Zertifikat für die Domain Ihrer Website von Let’s Encrypt zu erhalten, müssen Sie die Kontrolle über die Domain nachweisen, indem Sie bestimmte Herausforderungen meistern. Eine Herausforderung gehört zu einer Liste bestimmter Aufgaben, die nur jemand ausführen kann, der die Domäne kontrolliert.

Derzeit gibt es zwei Arten von Herausforderungen:

  • HTTP-01-Herausforderung: HTTP-01-Herausforderungen werden abgeschlossen, indem eine bestimmte Datei an einem bestimmten Ort auf einer Website veröffentlicht wird. Let’s Encrypt CA überprüft die Datei, indem es eine HTTP-Anforderung an den HTTP-URI stellt, um die Herausforderung zu erfüllen.

  • DNS-01-Herausforderung: DNS01-Herausforderungen werden abgeschlossen, indem ein berechneter Schlüssel bereitgestellt wird, der in einem DNS-TXT-Datensatz vorhanden ist. Sobald dieser TXT-Eintrag über das Internet verbreitet wurde, kann der ACME-Server diesen Schlüssel erfolgreich über eine DNS-Suche abrufen. Der ACME-Server kann überprüfen, ob der Client die Domäne für das angeforderte Zertifikat besitzt. Mit den richtigen Berechtigungen präsentiert cert-manager diesen TXT-Eintrag automatisch für Ihren angegebenen DNS-Anbieter.

Bei erfolgreicher Validierung der Herausforderung wird ein Zertifikat für die Domäne erteilt.

Dieses Thema enthält Informationen zum sicheren Bereitstellen einer HTTPS-Webanwendung auf einem Kubernetes-Cluster mithilfe von:

Voraussetzungen

Stellen Sie sicher, dass Sie

  • Die Domäne, für die das Zertifikat angefordert wird, ist öffentlich zugänglich.
  • RBAC auf Ihrem Kubernetes-Cluster aktiviert.
  • Citrix ADC MPX, VPX oder CPX wurde im Bereitstellungsmodell der Stufe 1 oder Stufe 2 bereitgestellt.

    Im Tier-1-Bereitstellungsmodell wird Citrix ADC MPX oder VPX als Application Delivery Controller (ADC) verwendet. Der Citrix Ingress Controller, der im Kubernetes-Cluster ausgeführt wird, konfiguriert die virtuellen Dienste für Dienste, die auf dem Kubernetes-Cluster ausgeführt werden. Citrix ADC führt den virtuellen Dienst auf der öffentlich routbaren IP-Adresse aus und lagert SSL für den Clientverkehr mithilfe des generierten Zertifikats von Let’s Encrypt aus.

    Im Tier-2-Bereitstellungsmodell wird ein TCP-Dienst auf dem Citrix ADC (VPX/MPX) konfiguriert, der außerhalb des Kubernetes-Clusters ausgeführt wird. Dieser Dienst wurde erstellt, um den Datenverkehr an Citrix ADC CPX-Instanzen weiterzuleiten, die im Kubernetes-Cluster ausgeführt werden. Citrix ADC CPX beendet die SSL-Sitzung und gleicht den Datenverkehr auf die tatsächlichen Service-Pods aus.

  • Citrix Ingress Controller bereitgestellt. Klicken Sie hier für verschiedene Bereitstellungsszenarien.

  • Port 80 für die virtuelle IP-Adresse auf der Firewall für die Let’s Encrypt CA geöffnet, um die Domäne für die HTTP01-Herausforderung zu validieren.

  • Eine DNS-Domäne, die Sie steuern und in der Sie Ihre Webanwendung für die ACME DNS01-Herausforderung hosten.

  • Administratorberechtigungen für alle Bereitstellungsschritte. Wenn Sie aufgrund von Berechtigungen auf Fehler stoßen, stellen Sie sicher, dass Sie über Administratorberechtigungen verfügen.

Installieren Sie den cert-manager

Informationen zur Installation von cert-manager finden Sie in der Cert-Manager-Installationsdokumentation.

Sie können den cert-manager entweder mithilfe von Manifestdateien oder Helm-Diagramm installieren.

Stellen Sie nach der Installation des Cert-Managers sicher, dass der cert-manager wie beschrieben ausgeführt wird, um die Installation zu überprüfen.

Bereitstellen einer Beispielwebanwendung

Führen Sie die folgenden Schritte aus, um eine Beispielwebanwendung bereitzustellen:

Hinweis:

Kuard, eine Kubernetes-Demo-Anwendung, wird in diesem Thema als Referenz verwendet.

  1. Erstellen Sie eine YAML-Bereitstellungsdatei (kuard-deployment.yaml) für Kuard mit der folgenden Konfiguration:

    
            apiVersion: apps/v1
            kind: Deployment
            metadata:
              labels:
                app: kuard
              name: kuard
            spec:
              replicas: 1
              selector:
                matchLabels:
                  app: kuard
              template:
                metadata:
                  labels:
                    app: kuard
                spec:
                  containers:
                  - image: gcr.io/kuar-demo/kuard-amd64:1
                    imagePullPolicy: Always
                    name: kuard
                    ports:
                    - containerPort: 8080
                      protocol: TCP
    <!--NeedCopy-->
    
  2. Stellen Sie die Kuard-Bereitstellungsdatei (kuard-deployment.yaml) mithilfe der folgenden Befehle in Ihrem Cluster bereit:

    % kubectl create -f kuard-deployment.yaml

    deployment.extensions/kuard created
    

    % kubectl Pod holen -l app=kuard

    NAME                     READY   STATUS    RESTARTS   AGE
            
    kuard-6fc4d89bfb-djljt   1/1     Running   0          24s
    
  3. Erstellen Sie einen Dienst für die Bereitstellung. Erstellen Sie eine Datei mit dem Namen service.yaml mit der folgenden Konfiguration:

              apiVersion: v1
              kind: Service
              metadata:
                name: kuard
              spec:
                ports:
                - port: 80
                  targetPort: 8080
                  protocol: TCP
                selector:
                  app: kuard
      <!--NeedCopy-->
    
  4. Stellen Sie den Dienst mithilfe der folgenden Befehle bereit und überprüfen Sie ihn:

    % kubectl create -f service.yaml
    
    service/kuard created
    % kubectl get svc kuard
    NAME    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
    kuard   ClusterIP   10.103.49.171   <none>        80/TCP    13s
    
  5. Stellen Sie diesen Dienst der Außenwelt zur Verfügung, indem Sie einen Ingress erstellen, der auf Citrix ADC CPX oder VPX als virtueller Content Switching-Server bereitgestellt wird.

    Hinweis:

    Stellt sicher, dass Sie den Wert von kubernetes.io/ingress.class in Ihre Eingangsklasse ändern, auf der der Citrix Ingress Controller gestartet wird.

        apiVersion: networking.k8s.io/v1
        kind: Ingress
        metadata:
          annotations:
            kubernetes.io/ingress.class: citrix
          name: kuard
        spec:
          rules:
          - host: kuard.example.com
            http:
              paths:
              - backend:
                  service:
                    name: kuard
                    port:
                      number: 80
                path: /
                pathType: Prefix
    

Hinweis:

Sie müssen den Wert von spec.rules.host in der Domäne ändern, die Sie steuern. Stellen Sie sicher, dass ein DNS-Eintrag vorhanden ist, um den Datenverkehr an Citrix ADC CPX oder VPX weiterzuleiten.

  1. Stellen Sie den Ingress mit dem folgenden Befehl bereit:

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    root@ubuntu-:~/cert-manager# kubectl get ingress
    NAME    HOSTS               ADDRESS   PORTS   AGE
    kuard   kuard.example.com             80      7s
    
  2. Stellen Sie mithilfe des folgenden Befehls sicher, dass der Ingress auf Citrix ADC CPX oder VPX konfiguriert ist:

    $ kubectl exec -it cpx-ingress-5b85d7c69d-ngd72 /bin/bash
    
    root@cpx-ingress-55c88788fd-qd4rg:/# cli_script.sh 'show cs vserver'
    exec: show cs vserver
    1)  k8s-192.168.8.178_80_http (192.168.8.178:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Sat Jan  4 13:36:14 2020
      Time since last state change: 0 days, 00:18:01.950
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=MPPL57E3AFY6NMNDGDKN2VT57HEZVOV53Z7DWKH44X2SGLIH4ZWQ====
      Appflow logging: ENABLED
      Port Rewrite : DISABLED
      State Update: DISABLED
      Default:  Content Precedence: RULE
      Vserver IP and Port insertion: OFF
      L2Conn: OFF Case Sensitivity: ON
      Authentication: OFF
      401 Based Authentication: OFF
      Push: DISABLED  Push VServer:
      Push Label Rule: none
      Persistence: NONE
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    
    root@cpx-ingress-55c88788fd-qd4rg/# exit
    exit
    
  3. Stellen Sie sicher, dass die Webseite korrekt bedient wird, wenn Sie mit dem Befehl curl angefordert werden.

    % curl -sS -D - kuard.example.com -o /dev/null
    HTTP/1.1 200 OK
    Content-Length: 1458
    Content-Type: text/html
    Date: Thu, 21 Feb 2019 09:09:05 GMT
    

Konfigurieren des ausstellenden ACME-Zertifikats mit HTTP Challenge

In diesem Abschnitt wird beschrieben, wie das ACME-Zertifikat mithilfe der HTTP-Validierung ausgestellt werden kann. Wenn Sie die DNS-Validierung verwenden möchten, überspringen Sie diesen Abschnitt und fahren Sie mit dem nächsten Abschnittfort.

Die HTTP-Validierung mit dem cert-manager ist eine einfache Möglichkeit, ein Zertifikat von Let’s Encrypt für Ihre Domain zu erhalten. Bei dieser Methode weisen Sie den Besitz einer Domäne nach, indem Sie sicherstellen, dass eine bestimmte Datei in der Domäne vorhanden ist. Es wird davon ausgegangen, dass Sie die Domäne steuern, wenn Sie die angegebene Datei unter einem bestimmten Pfad veröffentlichen können.

Stellen Sie den Let’s Encrypt ClusterIssuer mit dem HTTP01-Challenge-Anbieter bereit

Der cert-manager unterstützt zwei verschiedene CRDs für die Konfiguration, eine Issuer, die auf einen einzelnen Namespace beschränkt ist, und eine ClusterIssuer, mit clusterweitem Geltungsbereich.

Damit der Citrix Ingress Controller den Ingress von einem beliebigen Namespace aus verwenden kann, verwenden Sie ClusterIssuer. Alternativ können Sie auch für jeden Namespace, auf dem Sie eine Ingress-Ressource erstellen, einen Issuer erstellen.

Weitere Informationen finden Sie in der Cert-Manager-Dokumentation für die HTTP-Validierung.

  1. Erstellen Sie eine Datei mit dem Namen issuer-letsencrypt-staging.yaml mit der folgenden Konfiguration:

    apiVersion: cert-manager.io/v1alpha2
    kind: ClusterIssuer
    metadata:
      name: letsencrypt-staging
    spec:
      acme:
        # You must replace this email address with your own.
        # Let's Encrypt will use this to contact you about expiring
        # certificates, and issues related to your account.
        email: user@example.com
        server: https://acme-staging-v02.api.letsencrypt.org/directory
        privateKeySecretRef:
          # Secret resource used to store the account's private key.
          name: example-issuer-account-key
        # Add a single challenge solver, HTTP01 using citrix
        solvers:
        - http01:
            ingress:
              class: citrix
    

    spec.acme.solvers[].http01.ingress.class bezieht sich auf die Ingress-Klasse des Citrix Ingress Controller. Wenn der Citrix Ingress Controller keine Ingress-Klasse hat, müssen Sie dieses Feld nicht angeben. Hinweis: Dies ist ein Beispiel Clusterissuer für die Ressource cert-manager.io/v1alpha2. Weitere Informationen finden Sie in der Dokumentation zu cert-manager http01.

    Der Staging-Server Let’s Encrypt gibt ein gefälschtes Zertifikat aus, das jedoch nicht an die API-Ratenbeschränkungen des Produktionsserversgebunden ist. Mit diesem Ansatz können Sie Ihre Umgebung einrichten und testen, ohne sich Gedanken über Tarifbegrenzungen machen zu müssen. Sie können denselben Schritt für den Let’s Encrypt-Produktionsserver wiederholen.

  2. Nachdem Sie die Datei bearbeitet und gespeichert haben, stellen Sie die Datei mit dem folgenden Befehl bereit:

    % kubectl apply -f issuer-letsencrypt-staging.yaml
    clusterissuer "letsencrypt-staging" created
    
  3. Stellen Sie sicher, dass der Aussteller erstellt und auf dem ACME-Server registriert ist.

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  4. Stellen Sie mit dem Befehl kubectl describe issuer letsencrypt-staging sicher, dass ClusterIssuer ordnungsgemäß registriert ist:

    % kubectl describe issuer letsencrypt-staging
    
    Status:
      Acme:
        Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/8200869
      Conditions:
        Last Transition Time:  2019-02-11T12:06:31Z
        Message:               The ACME account was registered with the ACME server
        Reason:                ACMEAccountRegistered
        Status:                True
        Type:                  Ready
    

Zertifikat für das Ingress-Objekt ausstellen

Sobald ClusterIssuer erfolgreich registriert wurde, können Sie ein Zertifikat für die Ingress-Domain “kuard.example.com” erhalten.

Sie können ein Zertifikat für die angegebene Ingress-Ressource mit den folgenden Methoden anfordern:

  • Hinzufügen von Ingress-shim Anmerkungen zum Eingangsobjekt.

  • Erstellen eines certificate CRD-Objekts.

Die erste Methode ist schnell und einfach, aber wenn Sie mehr Anpassung und Granularität in Bezug auf die Zertifikatserneuerung benötigen, können Sie die zweite Methode wählen. Sie können die Methode nach Ihren Bedürfnissen wählen.

Hinzufügen von Ingress-shim Anmerkungen zum Ingress-Objekt

Bei diesem Ansatz fügen Sie dem Ingress-Objekt, für das Sie ein Zertifikat vom ACME-Server anfordern, die folgenden zwei Anmerkungen hinzu.

certmanager.io/cluster-issuer: "letsencrypt-staging"

Hinweis:

Sie finden alle unterstützten Anmerkungen von cert-manager für Ingress-shimunter supported-annotations.

Ändern Sie außerdem die, ingress.yaml um TLS zu verwenden, indem Sie ein Geheimnis angeben.

  apiVersion: networking.k8s.io/v1
  kind: Ingress
  metadata:
    annotations:
      certmanager.io/cluster-issuer: letsencrypt-staging
      kubernetes.io/ingress.class: citrix
    name: kuard
  spec:
    rules:
    - host: kuard.example.com
      http:
        paths:
        - backend:
            service:
              name: kuard
              port:
                number: 80
          pathType: Prefix
          path: /
    tls:
    - hosts:
      - kuard.example.com
      secretName: kuard-example-tls

Die cert-manager.io/cluster-issuer: "letsencrypt-staging" Anmerkung weist den cert-manager an, den letsencrypt-staging clusterweiten Aussteller zu verwenden, um ein Zertifikat von den Staging-Servern von Let’s Encrypt anzufordern. CERT-Manager erstellt ein certificate Objekt, mit dem der Lebenszyklus des Zertifikats für verwaltet wird kuard.example.com. Der Wert für den Domänennamen und die Abforderungsmethode für das Zertifikatsobjekt wird vom Eingangsobjekt abgeleitet. CERT-Manager verwaltet den Inhalt des Secrets, solange der Ingress in Ihrem Cluster vorhanden ist.

Stellen Sie die Datei ingress.yaml mit dem folgenden Befehl bereit:

% kubectl apply -f ingress.yml

ingress.extensions/kuard configured
% kubectl get ingress kuard
NAME    HOSTS               ADDRESS   PORTS     AGE
kuard   kuard.example.com             80, 443   4h39m

Erstellen einer Zertifikat-CRD-Ressource

Alternativ können Sie ein CRD-Zertifikatsobjekt unabhängig vom Ingress-Objekt bereitstellen. Die Dokumentation der CRD “Zertifikat” finden Sie unter der HTTP-Validierung.

  1. Erstellen Sie die Datei certificate.yaml mit der folgenden Konfiguration:
        apiVersion: cert-manager.io/v1alpha2
        kind: Certificate
        metadata:
          name: example-com
          namespace: default
        spec:
          secretName: kuard-example-tls
          issuerRef:
            name: letsencrypt-staging
          commonName: kuard.example.com
          dnsNames:
          - www.kuard.example.com
   <!--NeedCopy-->

Der spec.secretName Schlüssel ist der Name des Geheimnisses, in dem das Zertifikat bei erfolgreicher Ausstellung des Zertifikats gespeichert wird.

  1. Stellen Sie die certificate.yaml Datei auf dem Kubernetes-Cluster bereit:

    kubectl create -f certificate.yaml
    certificate.cert-manager.io/example-com created
    
  2. Stellen Sie sicher, dass die benutzerdefinierte Zertifikatsressource vom Cert-Manager erstellt wurde, der das im Ingress angegebene Zertifikat darstellt. Wenn die ACME-Validierung nach einigen Minuten erfolgreich ist, wird der Status des Zertifikats “READY” auf “true” gesetzt.

    % kubectl get certificates.cert-manager.io kuard-example-tls
    NAME                READY   SECRET              AGE
    kuard-example-tls   True    kuard-example-tls   3m44s
    
    
    % kubectl get certificates.cert-manager.io kuard-example-tls
    Name:         kuard-example-tls
    Namespace:    default
    Labels:       <none>
    Annotations:  <none>
    API Version:  cert-manager.io/v1alpha2
    Kind:         Certificate
    Metadata:
      Creation Timestamp:  2020-01-04T17:36:26Z
      Generation:          1
      Owner References:
        API Version:           extensions/v1beta1
        Block Owner Deletion:  true
        Controller:            true
        Kind:                  Ingress
        Name:                  kuard
        UID:                   2cafa1b4-2ef7-11ea-8ba9-06bea3f4b04a
      Resource Version:        81263
      Self Link:               /apis/cert-manager.io/v1alpha2/namespaces/default/certificates/kuard-example-tls
      UID:                     bbfa5e51-2f18-11ea-8ba9-06bea3f4b04a
    Spec:
      Dns Names:
        acme.cloudpst.net
      Issuer Ref:
        Group:      cert-manager.io
        Kind:       ClusterIssuer
        Name:       letsencrypt-staging
      Secret Name:  kuard-example-tls
    Status:
      Conditions:
        Last Transition Time:  2020-01-04T17:36:28Z
        Message:               Certificate is up to date and has not expired
        Reason:                Ready
        Status:                True
        Type:                  Ready
      Not After:               2020-04-03T16:36:27Z
    Events:
      Type    Reason        Age   From          Message
      ----    ------        ----  ----          -------
      Normal  GeneratedKey  24m   cert-manager  Generated a new private key
      Normal  Requested     24m   cert-manager  Created new CertificateRequest resource "kuard-example-tls-3030465986"
      Normal  Issued        24m   cert-manager  Certificate issued successfully
    
  3. Stellen Sie sicher, dass die geheime Ressource erstellt wurde.

    % kubectl get secret  kuard-example-tls
      NAME                TYPE                DATA   AGE
      kuard-example-tls   kubernetes.io/tls   3      3m13s
    

Ausstellen eines ACME-Zertifikats mithilfe der DNS-Herausforderung

In diesem Abschnitt wird beschrieben, wie Sie die DNS-Validierung verwenden können, um das ACME-Zertifikat von Let’sencrypt CA abzurufen. Mit einer DNS-01-Herausforderung weisen Sie den Besitz einer Domain nach, indem Sie nachweisen, dass Sie deren DNS-Datensätze kontrollieren. Dies erfolgt durch Erstellen eines TXT-Eintrags mit bestimmten Inhalten, der nachweist, dass Sie die Kontrolle über die DNS-Einträge der Domain haben. Eine ausführliche Erläuterung der DNS-Herausforderung und der besten Sicherheitsmethoden bei der Bereitstellung der DNS-Herausforderung finden Sie unter Technical Deep Dive: Sichern der Automatisierung der ACME-DNS-Challenge-Validierung.

Hinweis:

In diesem Verfahren route53 wird als DNS-Anbieter verwendet. Weitere Anbieter finden Sie in der Cert-Manager-Dokumentation der DNS-Validierung.

Stellen Sie den Let’s Encrypt ClusterIssuer mit dem DNS01-Challenge-Anbieter bereit

Führen Sie die folgenden Schritte aus, um Let’s Encrypt ClusterIssuer with the DNS01 Challenge Provider bereitzustellen:

  1. Erstellen Sie ein AWS IAM-Benutzerkonto und laden Sie die geheime Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel herunter.
  2. Erteilen Sie Ihrem Benutzer die folgende IAM-Richtlinie:

    Route53-Zugriffsrichtlinie

  3. Erstellen Sie ein Kubernetes-Secret acme-route53 im kube-system Namespace.

    % kubectl create secret generic acme-route53 --from-literal secret-access-key=<secret_access_key>
    
  4. Erstellen Sie ein Issuer oder ClusterIssuer mit dem DNS01-Challenge-Anbieter.

    Sie können unter DNS01 mehrere Anbieter bereitstellen und angeben, welcher Anbieter zum Zeitpunkt der Zertifikatserstellung verwendet werden soll. Sie müssen Zugriff auf den DNS-Anbieter haben, damit cert-manager einen TXT-Eintrag erstellen kann. Anmeldeinformationen werden im Kubernetes-Geheimnis gespeichert, das in angegeben ist spec.dns01.secretAccessKeySecretRef. Ausführliche Anweisungen zum Abrufen von Anmeldeinformationen finden Sie in der Dokumentation des DNS-Anbieters.

          apiVersion: cert-manager.io/v1alpha2
          kind: ClusterIssuer
          metadata:
            name: letsencrypt-staging
            spec:
              acme:
              # You must replace this email address with your own.
              # Let's Encrypt will use this to contact you about expiring
              # certificates, and issues related to your account.
                email: user@example.com
                server: https://acme-staging-v02.api.letsencrypt.org/directory
                privateKeySecretRef:
                  name: example-issuer-account-key
                solvers:
                - dns01:
                    route53:
                      region: us-west-2
                      accessKeyID: <IAMKEY>
                      secretAccessKeySecretRef:
                        name: acme-route53
                        key: secret-access-key
    <!--NeedCopy-->
    

    Hinweis:

    Ersetzen Sie user@example.com durch die E-Mail-Adresse. Für jede in einer DNS01-Strophe erwähnte Domäne verwendet cert-manager die Anmeldeinformationen des Anbieters aus dem referenzierten Aussteller, um einen TXT-Datensatz mit dem Namen zu erstellen _acme-challenge. Dieser Datensatz wird dann vom ACME-Server für die Ausstellung des Zertifikats überprüft. Weitere Informationen zur DNS-Anbieterkonfiguration und zur Liste der unterstützten Anbieter finden Sie im DNS01-Referenzdokument.

  5. Nachdem Sie die Datei bearbeitet und gespeichert haben, stellen Sie die Datei mit dem folgenden Befehl bereit:

    % kubectl apply -f acme_clusterissuer_dns.yaml
    clusterissuer "letsencrypt-staging" created
    
  6. Überprüfen Sie mit dem folgenden Befehl, ob der Aussteller erstellt und auf dem ACME-Server registriert ist:

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  7. Überprüfen Sie mit dem Befehl, ob der ordnungsgemäß registriert ClusterIssuer ist kubectl describe issuer letsencrypt-staging:

    Status:
      Acme:
        Uri:  https://acme-staging-v02.api.letsencrypt.org/acme/acct/8200869
      Conditions:
        Last Transition Time:  2019-02-11T12:06:31Z
        Message:               The ACME account was registered with the ACME server
        Reason:                ACMEAccountRegistered
        Status:                True
        Type:                  Ready
    

Zertifikat für die Ingress-Ressource ausstellen

Sobald der Aussteller erfolgreich registriert wurde, können Sie ein Zertifikat für die Eingangsdomäne erhalten kuard.example.com. Ähnlich wie bei der HTTP01-Herausforderung gibt es zwei Möglichkeiten, das Zertifikat für eine angegebene Ingress-Ressource anzufordern:

Hinzufügen von Ingress-shim Anmerkungen zum Eingangsobjekt

Fügen Sie dem Ingress-Objekt zusammen mit dem spec.tls Abschnitt die folgende Anmerkung hinzu:

certmanager.io/cluster-issuer: "letsencrypt-staging"
<!--NeedCopy-->
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-staging
    kubernetes.io/ingress.class: citrix
  name: kuard
spec:
  rules:
  - host: kuard.example.com
    http:
      paths:
      - backend:
          service:
            name: kuard
            port:
              number: 80
        pathType: Prefix
        path: /
  tls:
  - hosts:
    - kuard.example.com
    secretName: kuard-example-tls
<!--NeedCopy-->

Der Cert-Manager erstellt eine Certificate CRD-Ressource mit der DNS01-Herausforderung. Es verwendet die in angegebenen Anmeldeinformationen, ClusterIssuer um auf dem DNS-Server einen TXT-Eintrag für die Domäne zu erstellen, die Sie besitzen. Anschließend validiert Let’s Encrypt CA den Inhalt des TXT-Datensatzes, um die Herausforderung abzuschließen.

Hinzufügen einer Certificate CRD-Ressource**

Alternativ können Sie explizit eine Definitionsressource für benutzerdefinierte Zertifikatsressourcen erstellen, um die automatische Generierung von Zertifikaten auszulösen

  1. Erstellen Sie die Datei certificate.yaml mit der folgenden Konfiguration:

            apiVersion: cert-manager.io/v1alpha2
            kind: Certificate
            metadata:
              name: example-com
              namespace: default
            spec:
              secretName: kuard-example-tls
              issuerRef:
                name: letsencrypt-staging
              commonName: kuard.example.com
              dnsNames:
              - www.kuard.example.com
    <!--NeedCopy-->
    

    Nach erfolgreicher Validierung des Domainnamens wird der Status des Zertifikats READY auf True festgelegt.

  2. Stellen Sie sicher, dass das Zertifikat ausgestellt wurde.

    % kubectl get certificate kuard-example-tls
    
       NAME           READY   SECRET              AGE
       -example-tls   True    kuard-example-tls   10m
    

    Sie können den Status des Zertifikats während der Ausstellung mit dem folgenden Befehl verfolgen:

    % kubectl describe certificates kuard-example-tls | tail -n 6

       Not After:               2020-04-04T13:34:23Z
       Events:
       Type    Reason     Age    From          Message
       ----    ------     ----   ----          -------
       Normal  Requested  11m    cert-manager  Created new CertificateRequest resource "kuard-example-tls-3030465986"
       Normal  Issued     7m21s  cert-manager  Certificate issued successfully
    

Zertifikat in Citrix ADC überprüfen

Letsencrypt CA hat die Domäne erfolgreich validiert und ein neues Zertifikat für die Domäne ausgestellt. Ein kubernetes.io/tls Secret wird mit dem im tls: Feld des Ingress secretName angegebenen Wert erstellt. Außerdem leitet cert-manager automatisch eine Verlängerung ein, 30 Tage vor Ablauf.

Für die HTTP-Herausforderung erstellt cert-manager eine temporäre Ingress-Ressource, um den von Let’s Encrypt CA generierten Datenverkehr an cert-Manager-Pods weiterzuleiten. Bei erfolgreicher Validierung der Domain wird dieser temporäre Ingress gelöscht.

  1. Stellen Sie mit dem folgenden Befehl sicher, dass das Secret erstellt wurde:

    % kubectl get secret kuard-example-tls
    
    NAME                TYPE                DATA   AGE
    kuard-example-tls   kubernetes.io/tls   3      30m
    

    Der Citrix Ingress Controller nimmt das Geheimnis auf und bindet das Zertifikat an den virtuellen Content Switching-Server auf dem Citrix ADC CPX. Wenn Zwischenzertifikate der Zertifizierungsstelle vorhanden sind, werden diese automatisch mit dem Serverzertifikat verknüpft und dem Client während der SSL-Aushandlung vorgelegt.

  2. Melden Sie sich bei Citrix ADC CPX an und überprüfen Sie, ob das Zertifikat an den virtuellen SSL-Server gebunden ist.

    % kubectl exec -it cpx-ingress-55c88788fd-n2x9r bash -c cpx-ingress
    Defaulting container name to cpx-ingress.
    Use 'kubectl describe pod/cpx-ingress-55c88788fd-n2x9r -n default' to see all of the containers in this pod.
    
    % cli_script.sh 'sh ssl vs k8s-192.168.8.178_443_ssl'
    exec: sh ssl vs k8s-192.168.8.178_443_ssl
    
      Advanced SSL configuration for VServer k8s-192.168.8.178_443_ssl:
      DH: DISABLED
      DH Private-Key Exponent Size Limit: DISABLED Ephemeral RSA: ENABLED  Refresh Count: 0
      Session Reuse: ENABLED  Timeout: 120 seconds
      Cipher Redirect: DISABLED
      ClearText Port: 0
      Client Auth: DISABLED
      SSL Redirect: DISABLED
      Non FIPS Ciphers: DISABLED
      SNI: ENABLED
      OCSP Stapling: DISABLED
      HSTS: DISABLED
      HSTS IncludeSubDomains: NO
      HSTS Max-Age: 0
      HSTS Preload: NO
      SSLv3: ENABLED  TLSv1.0: ENABLED  TLSv1.1: ENABLED  TLSv1.2: ENABLED  TLSv1.3: DISABLED
      Push Encryption Trigger: Always
      Send Close-Notify: YES
      Strict Sig-Digest Check: DISABLED
      Zero RTT Early Data: DISABLED
      DHE Key Exchange With PSK: NO
      Tickets Per Authentication Context: 1
    , P_256, P_384, P_224, P_5216) CertKey Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS Server Certificate for SNI
    
    7) Cipher Name: DEFAULT
      Description: Default cipher list with encryption strength >= 128bit
    Done
    
    % cli_script.sh 'sh certkey'
    1) Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS
      Cert Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.crt
      Key Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.key
      Format: PEM
      Status: Valid,   Days to expiration:89
      Certificate Expiry Monitor: ENABLED
      Expiry Notification period: 30 days
      Certificate Type: "Client Certificate" "Server Certificate"
      Version: 3
      Serial Number: 03B2B57EA9E61A93F1D05EA3272FA95203C2
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
      Validity
        Not Before: Jan  5 13:34:23 2020 GMT
        Not After : Apr  4 13:34:23 2020 GMT
      Subject:  CN=acme.cloudpst.net
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
    2) Name: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS_ic1
      Cert Path: k8s-GVWNYGVZKKRHKF7MZVTLOAEZYBS.crt_ic1
      Format: PEM
      Status: Valid,   Days to expiration:437
      Certificate Expiry Monitor: ENABLED
      Expiry Notification period: 30 days
      Certificate Type: "Intermediate CA"
      Version: 3
      Serial Number: 0A0141420000015385736A0B85ECA708
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  O=Digital Signature Trust Co.,CN=DST Root CA X3
      Validity
        Not Before: Mar 17 16:40:46 2016 GMT
        Not After : Mar 17 16:40:46 2021 GMT
      Subject:  C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
    Done
    

Der HTTPS-Webserver ist jetzt mit einem gefälschten LE-signierten Zertifikat ausgestattet. Der nächste Schritt besteht darin, mit den eigentlichen Let’s Encrypt-Zertifikaten in Produktion zu gehen.

Zur Produktion übergehen

Nachdem Sie erfolgreich mit Let’s Encrypt-Staging getestet haben, können Sie das eigentliche Let’s Encrypt-Zertifikat abrufen.

Sie müssen den Endpunkt von Let’s Encrypt von https:acme-staging-v02.api.letsencrypt.org/directory auf ändern https:acme-v02.api.letsencrypt.org/directory

Ändern Sie dann den Namen des ClusterIssuer von letsencrypt-staging in letsencrypt-production


apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    # You must replace this email address with your own.
    # Let's Encrypt will use this to contact you about expiring
    # certificates, and issues related to your account.
    email: user@example.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      # Secret resource used to store the account's private key.
      name: example-issuer-account-key
    # Add a single challenge solver, HTTP01 using citrix
    solvers:
    - http01:
        ingress:
          class: citrix
<!--NeedCopy-->

Hinweis:

Ersetzen Sie user@example.com durch die E-Mail-Adresse.

Stellen Sie die Datei mit dem folgenden Befehl bereit:

% kubectl apply -f letsencrypt-prod.yaml

 clusterissuer "letsencrypt-prod" created

Wiederholen Sie nun das Ändern der Anmerkung in Ingress oder Erstellen eines CRD-Zertifikats, das die Generierung eines neuen Zertifikats auslöst.

Hinweis

Stellen Sie sicher, dass Sie das alte Geheimnis löschen, damit der cert-manager eine neue Herausforderung mit der Produktionszertifizierungsstelle startet.

% kubectl delete secret kuard-example-tls

 secret "kuard-example-tls" deleted

Sobald die HTTP-Website aktiv ist, können Sie den Datenverkehr mithilfe der Anmerkung ingress.citrix.com/insecure-termination: redirect im Ingress-Objekt von HTTP zu HTTPS umleiten.

Problembehandlung

Da die Zertifikatsgenerierung mehrere Komponenten umfasst, fasst dieser Abschnitt die Techniken zur Problembehandlung zusammen, die Sie bei Fehlern verwenden können.

Überprüfen des Status der Zertifikatsgenerierung

Das CRD-Objekt des Zertifikats definiert das Lebenszyklusmanagement der Generierung und Erneuerung von Zertifikaten. Sie können den Status des Zertifikats mit dem kubectl describe Befehl wie folgt anzeigen.

% kubectl get certificate

NAME                READY   SECRET              AGE
kuard-example-tls   False   kuard-example-tls   9s

%  kubectl describe certificate kuard-example-tls

Status:
  Conditions:
    Last Transition Time:  2019-03-05T09:50:29Z
    Message:               Certificate does not exist
    Reason:                NotFound
    Status:                False
    Type:                  Ready
Events:
  Type    Reason        Age   From          Message
  ----    ------        ----  ----          -------
  Normal  OrderCreated  22s   cert-manager  Created Order resource "kuard-example-tls-1754626579"

Sie können die wichtigsten Zertifikatsereignisse auch mit dem kubectl events Befehl anzeigen:

kubectl get events

LAST SEEN   TYPE     REASON              KIND          MESSAGE
36s         Normal   Started             Challenge     Challenge scheduled for processing
36s         Normal   Created             Order         Created Challenge resource "kuard-example-tls-1754626579-0" for domain "acme.cloudpst.net"
38s         Normal   OrderCreated        Certificate   Created Order resource "kuard-example-tls-1754626579"
38s         Normal   CreateCertificate   Ingress       Successfully created Certificate "kuard-example-tls"

Analysieren von Protokollen von cert-manager

Wenn es einen Fehler gibt, besteht der erste Schritt darin, Protokolle von der Cert-Manager-Komponente zu analysieren. Identifizieren Sie den Cert-Manager-Pod mit dem folgenden Befehl:

% kubectl get po -n cert-manager

NAME                                    READY   STATUS      RESTARTS   AGE
cert-manager-76d48d47bf-5w4vx           1/1     Running     0          23h
cert-manager-webhook-67cfb86d56-6qtxr   1/1     Running     0          23h
cert-manager-webhook-ca-sync-x4q6f      0/1     Completed   4          23h

Hier cert-manager-76d48d47bf-5w4vx ist der Haupt-Cert-Manager-Pod, und die beiden anderen Pods sind Cert-Manager-Webhook-Pods.

Rufen Sie die Protokolle des Cert-Managers mit dem folgenden Befehl ab:

% kubectl logs -f cert-manager-76d48d47bf-5w4vx -n cert-manager

Wenn das Zertifikat nicht abgerufen werden kann, enthalten die ERROR-Protokolle Details zum Fehler.

Prüfen Sie das Kubernetes-Geheimnis

Verwenden Sie den kubectl describe Befehl, um zu überprüfen, ob sowohl Zertifikate als auch Schlüssel in Kubernetes-Schlüssel eingetragen sind.

% kubectl describe secret kuard-example-tls

Name:         kuard-example-tls
Namespace:    default
Labels:       certmanager.k8s.io/certificate-name=kuard-example-tls
Annotations:  certmanager.k8s.io/alt-names: acme.cloudpst.net
              certmanager.k8s.io/common-name: acme.cloudpst.net
              certmanager.k8s.io/issuer-kind: ClusterIssuer
              certmanager.k8s.io/issuer-name: letsencrypt-staging

Type:  kubernetes.io/tls

Data
====
tls.crt:  3553 bytes
tls.key:  1679 bytes
ca.crt:   0 bytes

Wenn beide tls.crt und im Kubernetes-Schlüssel eingetragen tls.key sind, ist die Zertifikatsgenerierung abgeschlossen. Wenn nur vorhanden tls.key ist, ist die Zertifikatsgenerierung unvollständig. Analysieren Sie die Cert-Manager-Protokolle, um weitere Informationen zum Problem zu erhalten.

Analysieren von Protokollen vom Citrix Ingress Controller

Wenn ein Kubernetes-Geheimnis generiert und vollständig ist, aber nicht in den Citrix ADC hochgeladen wird, können Sie die Protokolle vom Citrix Ingress Controller mit dem folgenden Befehl analysieren.

% kubectl logs -f cpx-ingress-685c8bc976-zgz8q
Stellen Sie die HTTPS-Webanwendung auf Kubernetes mit dem Citrix Ingress Controller bereit und lassen Sie uns mit cert-manager verschlüsseln