Citrix ADC Ingress Controller

Bereitstellen einer HTTPS-Webanwendung auf Kubernetes mit Citrix Ingress Controller und HashiCorp Vault mit cert-manager

Für Eingangsressourcen, die mit dem Citrix Ingress Controller bereitgestellt werden, können Sie die Bereitstellung, den Widerruf und die Verlängerung von TLS-Zertifikaten mithilfe von cert-manager und HashiCorp Vault automatisieren. Dieses Thema enthält ein Beispiel für einen Workflow, der HashiCorp Vault als selbstsignierte Zertifizierungsstelle für Signaturanforderungen von Cert-Manager verwendet.

Insbesondere verwendet der Workflow die Vault PKI Secrets Engine, um eine Zertifizierungsstelle (CA) zu erstellen. In diesem Lernprogramm wird davon ausgegangen, dass Sie einen Tresor-Server installiert haben, der über den Kubernetes-Cluster erreichbar ist. Die PKI-Secrets-Engine von Vault eignet sich für interne Anwendungen. Externe Anwendungen, die Vertrauen der Öffentlichkeit erfordern, finden Sie unter Automatisieren von TLS-Zertifikaten mit Let’s Encrypt CA.

Der Workflow verwendet eine geheime Vault-Engine und Authentifizierungsmethoden. Eine vollständige Liste der Vault-Funktionen finden Sie in der folgenden Vault-Dokumentation:

In diesem Thema finden Sie Informationen zum Bereitstellen einer HTTPS-Webanwendung auf einem Kubernetes-Cluster mithilfe von:

Voraussetzungen

Stellen Sie sicher, dass Sie

  • Der Tresor-Server ist installiert, entsiegelt und kann vom Kubernetes-Cluster aus erreicht werden. Informationen zur Installation des Tresor-Servers finden Sie in der Vault-Installationsdokumentation.

  • RBAC auf Ihrem Kubernetes-Cluster aktiviert.

  • Citrix ADC MPX, VPX oder CPX 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 die 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.

    In der Tier-2-Bereitstellung wird ein TCP-Dienst auf dem Citrix ADC (VPX/MPX) konfiguriert, der außerhalb des Kubernetes-Clusters ausgeführt wird, 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 wurde bereitgestellt. Siehe Bereitstellungstopologien für verschiedene Bereitstellungsszenarien

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

Hinweis:

Das folgende Verfahren zeigt Schritte zum Konfigurieren von Vault als Zertifizierungsstelle mit Citrix ADC CPX, das als Eingangsgerät verwendet wird. Wenn ein Citrix ADC VPX oder MPX als Eingangsgerät verwendet wird, sind die Schritte dieselben, mit Ausnahme der Schritte zum Überprüfen der Eingangskonfiguration im Citrix ADC.

Cert-Manager mithilfe der Manifestdatei bereitstellen

Führen Sie die folgenden Schritte aus, um den cert-manager mithilfe der bereitgestellten YAML-Manifestdatei bereitzustellen.

  1. Installieren Sie den cert-manager. Informationen zur Installation von cert-manager finden Sie in der cert-manager-Dokumentation.

    kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/vx.x.x/cert-manager.yaml
    

    Sie können den cert-manager auch mit Helm installieren. Weitere Informationen finden Sie in der Dokumentation zum Cert-Manager.

  2. Stellen Sie mit dem folgenden Befehl sicher, dass der cert-manager aktiv ist.

    % kubectl -n cert-manager get all
    NAME                                       READY   STATUS    RESTARTS   AGE
    pod/cert-manager-77fd74fb64-d68v7          1/1     Running   0          4m41s
    pod/cert-manager-webhook-67bf86d45-k77jj   1/1     Running   0          4m41s
    
    NAME                           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    service/cert-manager-webhook   ClusterIP   10.108.161.154   <none>        443/TCP   13d
    
    NAME                                   READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/cert-manager           1/1     1            1           13d
    deployment.apps/cert-manager-webhook   1/1     1            1           13d
    
    NAME                                             DESIRED   CURRENT   READY   AGE
    replicaset.apps/cert-manager-77fd74fb64          1         1         1       13d
    replicaset.apps/cert-manager-webhook-67bf86d45   1         1         1       13d
    
    NAME                                                COMPLETIONS   DURATION   AGE
    job.batch/cert-manager-webhook-ca-sync              1/1           22s        13d
    job.batch/cert-manager-webhook-ca-sync-1549756800   1/1           21s        10d
    job.batch/cert-manager-webhook-ca-sync-1550361600   1/1           19s        3d8h
    
    NAME                                         SCHEDULE   SUSPEND   ACTIVE   LAST SCHEDULE   AGE
    cronjob.batch/cert-manager-webhook-ca-sync   @weekly    False     0        3d8h            13d
    

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:
              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
    <!--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 get pod -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 mit dem folgenden Befehl 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:

    Stellen Sie sicher, dass Sie kubernetes.io/ingress.class zu Ihrer Eingangsklasse wechseln, 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
     <!--NeedCopy-->
    

    Hinweis:

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

  6. Stellen Sie den Ingress mit dem folgenden Befehl bereit.

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    root@ubuntu-vivek-225:~/cert-manager# kubectl get ingress
    NAME    HOSTS               ADDRESS   PORTS   AGE
    kuard   kuard.example.com             80      7s
    
  7. Überprüfen Sie mit dem folgenden Befehl, ob der Ingress auf Citrix ADC CPX oder VPX konfiguriert ist.

    kubectl exec -it cpx-ingress-5b85d7c69d-ngd72 /bin/bash
    root@cpx-ingress-5b85d7c69d-ngd72:/# cli_script.sh 'sh cs vs'
    exec: sh cs vs
    1) k8s-10.244.1.50:80:http (10.244.1.50:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Thu Feb 21 09:02:14 2019
      Time since last state change: 0 days, 00:00:41.140
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=75VBGFO7NZXV7SCI4LSDJML2Q5X6FSNK6NXQPWGMDOYGBW2IMOGQ====
      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
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    root@cpx-ingress-5b85d7c69d-ngd72:/# exit
    exit
    
  8. Überprüfen Sie, ob die Seite korrekt bedient wird, wenn Sie mit dem curl Befehl 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
    

Nachdem Sie die HTTP-Beispielanwendung bereitgestellt haben, können Sie die Anwendung über HTTPS verfügbar machen. Hier signiert der Tresor-Server die vom Cert-Manager generierte CSR und es wird automatisch ein Serverzertifikat für die Anwendung generiert.

Im folgenden Verfahren verwenden Sie den konfigurierten Tresor als Zertifizierungsstelle und konfigurieren den Cert-Manager so, dass er den Tresor als Signaturautorität für die CSR verwendet.

Konfigurieren von HashiCorp Vault als Zertifizierungsstelle

In diesem Verfahren richten Sie mithilfe von HashiCorp Vault eine zwischengeschaltete CA-Zertifikatssignieranforderung ein. Dieser Vault-Endpunkt wird vom Cert-Manager verwendet, um das Zertifikat für die eingehenden Ressourcen zu signieren.

Hinweis:

Stellen Sie sicher, dass Sie das jq Dienstprogramm installiert haben, bevor Sie diese Schritte ausführen.

Erstellen einer Stammzertifizierungsstelle

Für den Beispiel-Workflow können Sie Ihre eigene Stammzertifizierungsstelle innerhalb des Tresors erstellen. In einer Produktionsumgebung sollten Sie eine externe Root-CA verwenden, um die Zwischenzertifizierungsstelle zu signieren, die Vault zum Generieren von Zertifikaten verwendet Wenn Sie an anderer Stelle eine Root-CA generiert haben, überspringen Sie diesen Schritt.

Hinweis:

PKI_ROOT ist ein Pfad, in dem Sie die Root-CA mounten, normalerweise ist dies der Fall pki. $ {DOMAIN} ist in diesem Verfahren example.com


% export DOMAIN=example.com
% export PKI_ROOT=pki

% vault secrets enable -path="${PKI_ROOT}" pki

# Set the max TTL for the root CA to 10 years
% vault secrets tune -max-lease-ttl=87600h "${PKI_ROOT}"

% vault write -format=json "${PKI_ROOT}"/root/generate/internal \
 common_name="${DOMAIN} CA root" ttl=87600h | tee \
>(jq -r .data.certificate > ca.pem) \
>(jq -r .data.issuing_ca > issuing_ca.pem) \
>(jq -r .data.private_key > ca-key.pem)

#Configure the CA and CRL URLs:

% vault write "${PKI_ROOT}"/config/urls \
       issuing_certificates="${VAULT_ADDR}/v1/${PKI_ROOT}/ca" \
       crl_distribution_points="${VAULT_ADDR}/v1/${PKI_ROOT}/crl"
<!--NeedCopy-->

Generieren einer zwischengeschalteten

Führen Sie nach dem Erstellen der Stammzertifizierungsstelle die folgenden Schritte aus, um mithilfe der Stammzertifizierungsstelle eine Zwischen-CSR zu erstellen.

  1. Aktivieren Sie normalerweise PKI von einem anderen Pfad PKI_INT als der Stammzertifizierungsstelle pki\_int. Verwenden Sie den folgenden Befehl:

        % export PKI_INT=pki_int
        % vault secrets enable -path=${PKI_INT} pki
    
        # Set the max TTL to 3 year
    
        % vault secrets tune -max-lease-ttl=26280h ${PKI_INT}
       <!--NeedCopy-->
    
  2. Generieren Sie CSR ${DOMAIN} dafür muss von der Stammzertifizierungsstelle signiert werden. Der Schlüssel wird intern im Tresor gespeichert. Verwenden Sie den folgenden Befehl:

          % vault write -format=json "${PKI_INT}"/intermediate/generate/internal \
          common_name="${DOMAIN} CA intermediate" ttl=26280h | tee \
          >(jq -r .data.csr > pki_int.csr) \
          >(jq -r .data.private_key > pki_int.pem)
    
       <!--NeedCopy-->
    
  3. Generieren und signieren Sie das ${DOMAIN} Zertifikat mit der Stamm-CA als Zwischenzertifizierungsstelle, speichern Sie es unter intermediate.cert.pem. Verwenden Sie den folgenden Befehl:

        % vault write -format=json "${PKI_ROOT}"/root/sign-intermediate csr=@pki_int.csr
                format=pem_bundle ttl=26280h \
                | jq -r '.data.certificate' > intermediate.cert.pem
      <!--NeedCopy-->
    

    Wenn Sie eine externe Stammzertifizierungsstelle verwenden, überspringen Sie den vorherigen Schritt und signieren Sie die CSR manuell mit der Stammzertifizierungsstelle.

  4. Sobald die CSR signiert ist und die Stammzertifizierungsstelle ein Zertifikat zurückgibt, muss sie mit dem folgenden Befehl wieder zum Tresor hinzugefügt werden:

        % vault write "${PKI_INT}"/intermediate/set-signed certificate=@intermediate.cert.pem
      <!--NeedCopy-->
    
  5. Stellen Sie die CA- und CRL-Position mit dem folgenden Befehl ein.

        vault write "${PKI_INT}"/config/urls issuing_certificates="${VAULT_ADDR}/v1/${PKI_INT}/ca" crl_distribution_points="${VAULT_ADDR}/v1/${PKI_INT}/crl"
      <!--NeedCopy-->
    

Eine zwischengeschaltete Zertifizierungsstelle ist eingerichtet und kann zum Signieren von Zertifikaten für eingehende Ressourcen verwendet werden.

Konfigurieren einer Rolle

Eine Rolle ist ein logischer Name, der Richtlinien zugeordnet wird. Ein Administrator kann die Zertifikatsgenerierung über die Rollen steuern.

Erstellen Sie eine Rolle für die zwischengeschaltete Zertifizierungsstelle, die eine Reihe von Richtlinien für das Ausstellen oder Signieren der Zertifikate mit dieser CA bereitstellt.

Es gibt viele Konfigurationen, die beim Erstellen von Rollen konfiguriert werden können. Weitere Informationen finden Sie in der Dokumentation zur Vault-Rolle.

Erstellen Sie für den Workflow eine Rolle kube-ingress, mit der Sie Zertifikate von ${DOMAIN} und deren Unterdomänen mit einer TTL von 90 Tagen signieren können.

    # with a Max TTL of 90 days
    vault write ${PKI_INT}/roles/kube-ingress \
              allowed_domains=${DOMAIN} \
              allow_subdomains=true \
              max_ttl="2160h" \
              require_cn=false
  <!--NeedCopy-->

Approle-basierte Authentifizierung erstellen

Nachdem Sie eine zwischengeschaltete Zertifizierungsstelle zum Signieren der Zertifikate konfiguriert haben, müssen Sie einen Authentifizierungsmechanismus bereitstellen, damit der Cert-Manager den Tresor zum Signieren der Zertifikate verwenden kann. CERT-Manager unterstützt die Approle-Authentifizierungsmethode, mit der Anwendungen auf die im Tresor definierten Rollen zugreifen können.

An AppRole steht für eine Reihe von Vault-Richtlinien und Anmeldebeschränkungen, die erfüllt sein müssen, um ein Token mit diesen Richtlinien zu erhalten. Weitere Informationen zu dieser Authentifizierungsmethode finden Sie in der Approle-Dokumentation.

Erstellen eines Approle

Erstellen Sie ein Approle namens Kube-role. Der secret_id für den Cert-Manager sollte nicht abgelaufen sein, um dieses Approle für die Authentifizierung zu verwenden. Setzen Sie daher kein TTL und setzen Sie es nicht auf 0.

% vault auth enable approle

% vault write auth/approle/role/kube-role token_ttl=0

Verknüpfen einer Richtlinie mit dem Genehmigungsberechtigten

Führen Sie die folgenden Schritte aus, um eine Richtlinie einem Genehmigungsberechtigten zuzuordnen.

  1. Erstellen Sie eine Datei pki_int.hcl mit der folgenden Konfiguration, um die Signierendpunkte der zwischengeschalteten Zertifizierungsstelle zuzulassen.

        path "${PKI_INT}/sign/*" {
              capabilities = ["create","update"]
            }
    <!--NeedCopy-->
    
  2. Fügen Sie die Datei zu einer neuen Richtlinie hinzu, die kube_allow_sign mit dem folgenden Befehl aufgerufen wird.

    vault policy write kube-allow-sign pki_int.hcl
    
  3. Aktualisieren Sie diese Richtlinie mit dem folgenden Befehl auf Approle.

    vault write auth/approle/role/kube-role policies=kube-allow-sign
    

Mit dem kube-role Approle können Sie die CSR mit einer zwischengeschalteten CA signieren.

Generieren Sie die Rollen-ID und die geheime ID

Die Rollen-ID und die geheime ID werden vom Cert-Manager verwendet, um sich beim Tresor zu authentifizieren.

Generieren Sie die Rollen-ID und die geheime ID und codieren Sie die geheime ID mit Base64. Führen Sie folgende Schritte aus:

% vault read auth/approle/role/kube-role/role-id
role_id     db02de05-fa39-4855-059b-67221c5c2f63

% vault write -f auth/approle/role/kube-role/secret-id
secret_id               6a174c20-f6de-a53c-74d2-6018fcceff64
secret_id_accessor      c454f7e5-996e-7230-6074-6ef26b7bcf86

# encode secret_id with base64
% echo 6a174c20-f6de-a53c-74d2-6018fcceff64 | base64
NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg==

Konfigurieren der ausstellenden Zertifikate in Kubernetes

Nachdem Sie Vault als Zwischenzertifizierungsstelle und die Approle-Authentifizierungsmethode für den Zugriff des Cert-Managers auf Vault konfiguriert haben, müssen Sie das Zertifikat für den Ingress konfigurieren.

Erstellen Sie einen Schlüssel mit der geheimen Approle-ID

Führen Sie die folgenden Schritte aus, um einen Schlüssel mit der geheimen Approle-ID zu erstellen.

  1. Erstellen Sie eine geheime Datei secretid.yaml mit dem Namen mit der folgenden Konfiguration.

    apiVersion: v1
    kind: Secret
    type: Opaque
    metadata:
      name: cert-manager-vault-approle
      namespace: cert-manager
    data:
      secretId: "NmExNzRjMjAtZjZkZS1hNTNjLTc0ZDItNjAxOGZjY2VmZjY0Cg=="
    

    Hinweis:

    Die geheime ID data.secretId ist die Base64-codierte geheime ID, die in Generieren der Rollen-ID und der geheimen IDgeneriert wird. Wenn Sie im nächsten Schritt eine Aussteller-Ressource verwenden, muss sich das Geheimnis im selben Namespace wie der befinden Issuer. Für ClusterIssuermuss sich das Geheimnis im cert-manager Namespace befinden.

  2. Stellen Sie die geheime Datei (secretid.yaml) mit dem folgenden Befehl bereit.

    % kubectl create -f secretid.yaml
    

Bereitstellen des Vault-Cluster-Ausstellers

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, die clusterweit ist. Für den Workflow müssen Sie verwenden ClusterIssuer.

Führen Sie die folgenden Schritte aus, um den Vault-Cluster-Aussteller bereitzustellen.

  1. Erstellen Sie eine Datei mit dem Namen issuer-vault.yaml mit der folgenden Konfiguration.

    apiVersion: cert-manager.io/v1
    kind: ClusterIssuer
    metadata:
      name: vault-issuer
    spec:
      vault:
        path: pki_int/sign/kube-ingress
        server: <vault-server-url>
        #caBundle: <base64 encoded caBundle PEM file>
        auth:
          appRole:
            path: approle
            roleId: "db02de05-fa39-4855-059b-67221c5c2f63"
            secretRef:
              name: cert-manager-vault-approle
              key: secretId
    

    SecretRef ist der geheime Kubernetes-Name, der im vorherigen Schritt erstellt wurde. Ersetzen Sie roleId durch das aus dem Tresor role_id abgerufene. Ein optionales base64-codiertes caBundle im PEM-Format kann zur Validierung der TLS-Verbindung zum Tresor-Server bereitgestellt werden. Wenn cabundle gesetzt ist, ersetzt es das CA-Bundle innerhalb des Containers, auf dem der Cert-Manager ausgeführt wird. Dieser Parameter hat keine Wirkung, wenn die verwendete Verbindung in reinem HTTP ausgeführt wird.

  2. Stellen Sie die Datei (issuer-vault.yaml) mit dem folgenden Befehl bereit.

    % kubectl create -f issuer-vault.yaml
    
  3. Überprüfen Sie mit dem folgenden Befehl, ob der Vault-Cluster-Aussteller erfolgreich mit dem Tresor authentifiziert wurde.

    % kubectl describe clusterIssuer vault-issuer  | tail -n 7
      Conditions:
        Last Transition Time:  2019-02-26T06:18:40Z
        Message:               Vault verified
        Reason:                VaultVerified
        Status:                True
        Type:                  Ready
    Events:                    <none>
    

Jetzt haben Sie den Cert-Manager für Vault erfolgreich als Zertifizierungsstelle eingerichtet. Der nächste Schritt ist das Sichern des Eingangs durch Generieren des Serverzertifikats. Es gibt zwei verschiedene Möglichkeiten, Ihren Ingress zu sichern. Sie können mit einem der Ansätze fortfahren, um Ihre Inresses zu sichern.

  • Ingress Shim-Ansatz
  • Manuelles Erstellen des certificate CRD-Objekts für das Zertifikat.

Ingress-Shim-Ansatz

Bei diesem Ansatz ändern Sie die Ingress-Annotation für den Cert-Manager, um das Zertifikat für den angegebenen Hostnamen automatisch zu generieren und es im angegebenen Secret zu speichern.

  1. Ändern Sie den Ingress mit dem tls Abschnitt, der einen Hostnamen und einen geheimen Schlüssel angibt. Geben Sie außerdem die Cert-Manager-Anmerkung cert-manager.io/cluster-issuer wie folgt an.

            apiVersion: networking.k8s.io/v1
            kind: Ingress
            metadata:
              annotations:
                cert-manager.io/cluster-issuer: vault-issuer
                kubernetes.io/ingress.class: citrix
              name: kuard
            spec:
              rules:
              - host: kuard.example.com
                http:
                  paths:
                  - backend:
                      service:
                        name: kuard-service
                        port:
                          number: 80
                    path: /
                    pathType: Prefix
              tls:
              - hosts:
                - kuard.example.com
                secretName: kuard-example-tls
    <!--NeedCopy-->
    
  2. Stellen Sie den modifizierten Ingress wie folgt bereit.

      % kubectl apply -f ingress.yml
      ingress.extensions/kuard created
    
      % kubectl get ingress kuard
      NAME    HOSTS               ADDRESS   PORTS     AGE
      kuard   kuard.example.com             80, 443   12s
    

Dieser Schritt löst ein certificate Objekt durch den Cert-Manager aus, der eine Certificate Signing Request (CSR) für die Domäne erstellt kuard.example.com. Bei erfolgreicher Signatur der CSR wird das Zertifikat in dem geheimen Namen gespeichert, der im Ingress kuard-example-tls angegeben ist.

  1. Stellen Sie mit dem folgenden Befehl sicher, dass das Zertifikat erfolgreich ausgestellt wurde.

      % kubectl describe certificates kuard-example-tls  | grep -A5 Events
      Events:
      Type    Reason      Age   From          Message
      ----    ------      ----  ----          -------
      Normal  CertIssued  48s   cert-manager  Certificate issued successfully
    

Erstellen Sie ein certificate CRD-Objekt für das Zertifikat

Sobald der Aussteller erfolgreich registriert wurde, müssen Sie das Zertifikat für die Eingangsdomäne erhalten kuard.example.com.

Sie müssen eine certificate Ressource mit commonName und erstellen dnsNames. Weitere Informationen finden Sie in der Dokumentation zum Cert-Manager. Sie können mehrere DNS-Namen angeben, die für das SAN-Feld im Zertifikat verwendet werden.

Um ein CRD-Objekt “Zertifikat” für das Zertifikat zu erstellen, gehen Sie wie folgt vor:

  1. Erstellen Sie eine Datei mit dem Namen certificate.yaml mit der folgenden Konfiguration.

    apiVersion: cert-manager.io/v1
    kind: Certificate
    metadata:
      name: kuard-example-tls
      namespace: default
    spec:
      secretName: kuard-example-tls
      issuerRef:
        kind: ClusterIssuer
        name: vault-issuer
      commonName: kuard.example.com
      duration: 720h
      #Renew before 7 days of expiry
      renewBefore: 168h
      commonName: kuard.example.com
      dnsNames:
      - www.kuard.example.com
    

    Das Zertifikat hat CN =kuard.example.com und SAN =Kuard.example.com,www.kuard.example.com. spec.secretName ist der Name des Geheimnisses, in dem das Zertifikat gespeichert wird, nachdem das Zertifikat erfolgreich ausgestellt wurde.

  2. Stellen Sie die Datei (certificate.yaml) mit dem folgenden Befehl auf dem Kubernetes-Cluster bereit.

    % kubectl create -f Zertifikat.yaml-Zertifikat.certmanager.k8s.io/kuard-example-tls erstellt

Prüfen Sie, ob das Zertifikat ausgestellt wurde

Sie können den Fortschritt des ausgestellten Zertifikats mit dem folgenden Befehl verfolgen:

% kubectl describe certificates kuard-example-tls  | grep -A5 Events
Events:
  Type    Reason      Age   From          Message
  ----    ------      ----  ----          -------
  Normal  CertIssued  48s   cert-manager  Certificate issued successfully > **Hinweis** > > Aufgrund der Vault-Richtlinien können einige Fehler auftreten. Wenn Sie auf solche Fehler stoßen, kehren Sie zum Tresor zurück und beheben Sie ihn.

Nach dem erfolgreichen Signieren wird ein kubernetes.io/tls Secret mit dem in der Certificate Ressource secretName angegebenen Wert erstellt.

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

Ändern Sie den Ingress, um das generierte Secret zu verwenden

Führen Sie die folgenden Schritte aus, um den Ingress so zu ändern, dass er das generierte Geheimnis verwendet.

  1. Bearbeiten Sie den ursprünglichen Ingress und fügen Sie einen spec.tls Abschnitt hinzu, der den geheimen Schlüssel kuard-example-tls wie folgt angibt.

          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
                  pathType: Prefix
                  path: /
            tls:
            - hosts:
              - kuard.example.com
              secretName: kuard-example-tls
    
  2. Stellen Sie den Ingress mit dem folgenden Befehl bereit.

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    % kubectl get ingress kuard
    NAME    HOSTS               ADDRESS   PORTS     AGE
    kuard   kuard.example.com             80, 443   12s
    

Überprüfen Sie die Ingress-Konfiguration in Citrix ADC

Sobald das Zertifikat erfolgreich generiert wurde, verwendet Citrix Ingress Controller dieses Zertifikat für die Konfiguration des virtuellen Front-End-SSL-Servers. Sie können es mit den folgenden Schritten überprüfen.

  1. 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-668bf6695f-4fwh8 bash
    cli_script.sh 'shsslvs'
    exec: shsslvs
    1) Vserver Name: k8s-10.244.3.148: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
      SSLv2 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
      SSLv2: DISABLED  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
    Done
    
    root@cpx-ingress-668bf6695f-4fwh8:/# cli_script.sh 'shsslvs k8s-10.244.3.148:443:ssl'
    exec: shsslvs k8s-10.244.3.148:443:ssl
    
      Advanced SSL configuration for VServer k8s-10.244.3.148: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
      SSLv2 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
      SSLv2: DISABLED  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-LMO3O3U6KC6WXKCBJAQY6K6X6JO Server Certificate for SNI
    
    7) Cipher Name: DEFAULT
      Description: Default cipher list with encryption strength >= 128bit
    Done
    
    root@cpx-ingress-668bf6695f-4fwh8:/# cli_script.sh 'sh certkey k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO'
    exec: sh certkey k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO
      Name: k8s-LMO3O3U6KC6WXKCBJAQY6K6X6JO Status: Valid,   Days to expiration:0
      Version: 3
      Serial Number: 524C1D9306F784A2F5277C05C2A120D5258D9A2F
      Signature Algorithm: sha256WithRSAEncryption
      Issuer:  CN=example.com CA intermediate
      Validity
        Not Before: Feb 26 06:48:39 2019 GMT
        Not After : Feb 27 06:49:09 2019 GMT
      Certificate Type: "Client Certificate" "Server Certificate"
      Subject:  CN=kuard.example.com
      Public Key Algorithm: rsaEncryption
      Public Key size: 2048
      Ocsp Response Status: NONE
      2) URI:http://127.0.0.1:8200/v1/pki_int/crl
      3) VServer name: k8s-10.244.3.148:443:ssl Server Certificate for SNI
    Done
    

    Der HTTPS-Webserver ist mit dem signierten Tresor-Zertifikat aktiv. CERT-Manager erneuert das Zertifikat automatisch, wie im RenewBefore Parameter im Zertifikat angegeben, bevor das Zertifikat abläuft.

    Hinweis:

    Die Vault-Signatur des Zertifikats schlägt fehl, wenn der Ablauf eines Zertifikats über den Ablauf der Stamm-CA oder der Zwischenzertifizierungsstelle hinausgeht Sie sollten sicherstellen, dass die CA-Zertifikate vor Ablauf im Voraus erneuert werden.

  2. Stellen Sie sicher, dass die Anwendung mit dem HTTPS-Protokoll zugänglich ist.

    % curl -sS -D - https://kuard.example.com -k -o /dev/null
    HTTP/1.1 200 OK
    Content-Length: 1472
    Content-Type: text/html
    Date: Tue, 11 May 2021 20:39:23 GMT
    
Bereitstellen einer HTTPS-Webanwendung auf Kubernetes mit Citrix Ingress Controller und HashiCorp Vault mit cert-manager