Contrôleur d'entrée Citrix ADC

Déployer une application Web HTTPS sur Kubernetes avec le Citrix ingress controller et HashiCorp Vault à l’aide de cert-manager

Pour les ressources d’entrée déployées avec le Citrix ingress controller, vous pouvez automatiser le provisionnement, la révocation et le renouvellement des certificats TLS à l’aide de cert-manager et de HashiCorp Vault. Cette rubrique fournit un exemple de flux de travail qui utilise HashiCorp Vault en tant qu’autorité de certification auto-signée pour les demandes de signature de certificat du gestionnaire de certificats.

Plus précisément, le flux de travail utilise le moteur de secrets PKI Vault pour créer une autorité de certification (CA). Ce didacticiel suppose qu’un serveur Vault est installé et accessible à partir du cluster Kubernetes. Le moteur de secrets PKI de Vault est adapté aux applications internes. Pour les applications externes qui nécessitent l’approbation du public, reportez-vous à la section Automatisation des certificats TLS à l’aide de Let’s Encrypt CA.

Le flux de travail utilise un moteur secret Vault et des méthodes d’authentification. Pour obtenir la liste complète des fonctionnalités de Vault, consultez la documentation Vault suivante :

Cette rubrique fournit des informations sur la façon de déployer une application Web HTTPS sur un cluster Kubernetes, à l’aide de :

Conditions préalables

Assurez-vous que vous avez :

  • Le serveur Vault est installé, descellé et est accessible depuis le cluster Kubernetes. Pour plus d’informations sur l’installation du serveur Vault, consultez la documentation d’installation du coffre-fort.

  • RBAC activé sur votre cluster Kubernetes.

  • Citrix ADC MPX, VPX ou CPX déployé dans un modèle de déploiement de niveau 1 ou de niveau 2.

    Dans le modèle de déploiement de niveau 1, Citrix ADC MPX ou VPX est utilisé en tant que Delivery Controller d’applications (ADC). Le Citrix ingress controller exécuté dans le cluster Kubernetes configure les services virtuels pour les services exécutés sur le cluster Kubernetes. Citrix ADC exécute le service virtuel sur l’adresse IP routable publiquement et décharge SSL pour le trafic client à l’aide du certificat généré par Let’s Encrypt.

    Dans le déploiement de niveau 2, un service TCP est configuré sur Citrix ADC (VPX/MPX) s’exécutant en dehors du cluster Kubernetes pour transférer le trafic vers les instances Citrix ADC CPX exécutées dans le cluster Kubernetes. Citrix ADC CPX met fin à la session SSL et équilibre la charge du trafic vers les espaces de service réels.

  • Citrix ingress controller déployé. Consultez la section Topologies de déploiement pour différents scénarios de déploiement.

  • Autorisations d’administrateur pour toutes les étapes du déploiement. Si vous rencontrez des échecs en raison d’autorisations, assurez-vous que vous disposez de l’autorisation d’administrateur.

Remarque :

La procédure suivante indique les étapes à suivre pour configurer Vault en tant qu’autorité de certification avec Citrix ADC CPX utilisé comme périphérique d’entrée. Lorsqu’un VPX ou un MPX Citrix ADC est utilisé comme périphérique d’entrée, les étapes sont les mêmes sauf celles pour vérifier la configuration d’entrée dans Citrix ADC.

Déployer cert-manager à l’aide du fichier manifeste

Effectuez les étapes suivantes pour déployer le gestionnaire de certificats à l’aide du fichier manifeste YAML fourni.

  1. Installez cert-manager. Pour plus d’informations sur l’installation de cert-manager, consultez la documentation de cert-manager.

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

    Vous pouvez également installer cert-manager avec Helm. Pour plus d’informations, consultez la documentation de cert-manager.

  2. Vérifiez que cert-manager est en cours d’exécution à l’aide de la commande suivante.

    % 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
    

Déployer un exemple d’application Web

Effectuez les étapes suivantes pour déployer un exemple d’application Web.

Remarque :

Kuard, une application de démonstration Kubernetes, est utilisée à titre de référence dans cette rubrique.

  1. Créez un fichier YAML de déploiement (kuard-deployment.yaml) pour Kuard avec la configuration suivante.

    
            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. Déployez le fichier de déploiement Kuard (kuard-deployment.yaml) sur votre cluster, à l’aide des commandes suivantes.

    % 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. Créez un service pour le déploiement. Créez un fichier appelé service.yaml avec la configuration suivante.

          apiVersion: v1
          kind: Service
          metadata:
            name: kuard
          spec:
            ports:
            - port: 80
              targetPort: 8080
              protocol: TCP
            selector:
              app: kuard
    <!--NeedCopy-->
    
  4. Déployez et vérifiez le service à l’aide de la commande suivante.

    % 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. Exposez ce service au monde extérieur en créant une entrée déployée sur Citrix ADC CPX ou VPX en tant que serveur virtuel de commutation de contenu.

    Remarque :

    Assurez-vous de passer kubernetes.io/ingress.class à votre classe d’entrée sur laquelle le Citrix ingress controller est démarré.

        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-->
    

    Remarque :

    Remplacez la valeur spec.rules.host de par le domaine que vous contrôlez. Assurez-vous qu’une entrée DNS existe pour acheminer le trafic vers Citrix ADC CPX ou VPX.

  6. Déployez l’entrée à l’aide de la commande suivante.

    % 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. Vérifiez si l’entrée est configurée sur Citrix ADC CPX ou VPX à l’aide de la commande suivante.

    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. Vérifiez si la page est correctement affichée lorsque vous y êtes invité à l’aide de la commande curl.

    % 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
    

Une fois que vous avez déployé l’exemple d’application HTTP, vous pouvez procéder pour rendre l’application disponible via HTTPS. Ici, le serveur Vault signe le CSR généré par le gestionnaire de certificats et un certificat de serveur est automatiquement généré pour l’application.

Dans la procédure suivante, vous utilisez le coffre-fort configuré en tant qu’autorité de certification et configurez le gestionnaire de certificats pour qu’il utilise le coffre-fort en tant qu’autorité de signature pour le CSR.

Configurer HashiCorp Vault en tant qu’autorité de certification

Dans cette procédure, vous configurez une demande de signature de certificat d’autorité de certification intermédiaire à l’aide de HashiCorp Vault. Ce point de terminaison du coffre est utilisé par le gestionnaire de certificats pour signer le certificat pour les ressources d’entrée.

Remarque :

Assurez-vous d’avoir installé l’utilitaire jq avant d’effectuer ces étapes.

Créer une autorité de certification racine

Pour l’exemple de flux de travail, vous pouvez générer votre propre autorité de certification racine dans le coffre-fort. Dans un environnement de production, vous devez utiliser une autorité de certification racine externe pour signer l’autorité de certification intermédiaire que Vault utilise pour générer des certificats. Si vous avez une autorité de certification racine générée ailleurs, ignorez cette étape.

Remarque :

PKI_ROOT est un chemin d’accès où vous montez l’autorité de certification racine, généralement c’est le cas pki. $ {DOMAIN} dans cette procédure est 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-->

Générer une autorité de certification intermédiaire

Après avoir créé l’autorité de certification racine, effectuez les étapes suivantes pour créer un CSR intermédiaire à l’aide de l’autorité de certification racine.

  1. Activez généralement l’ICP à partir d’un chemin différent PKI_INT de celui de l’autorité de certification racine pki\_int. Utilisez la commande suivante :

        % 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. Générer un CSR pour ${DOMAIN} lequel il doit être signé par l’autorité de certification racine. La clé est stockée en interne dans le coffre-fort. Utilisez la commande suivante :

          % 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. Générez et signez le ${DOMAIN} certificat en tant qu’autorité de certification intermédiaire en utilisant l’autorité de certification racine, stockez-le sous intermediate.cert.pem Utilisez la commande suivante :

        % 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-->
    

    Si vous utilisez une autorité de certification racine externe, ignorez l’étape précédente et signez le CSR manuellement à l’aide de l’autorité de certification racine.

  4. Une fois que le CSR est signé et que l’autorité de certification racine renvoie un certificat, il doit être ajouté de nouveau dans le coffre-fort à l’aide de la commande suivante :

        % vault write "${PKI_INT}"/intermediate/set-signed certificate=@intermediate.cert.pem
      <!--NeedCopy-->
    
  5. Définissez l’emplacement de l’AC et de la CRL à l’aide de la commande suivante.

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

Une autorité de certification intermédiaire est configurée et peut être utilisée pour signer des certificats pour les ressources d’entrée.

Configurer un rôle

Un rôle est un nom logique qui correspond à des stratégies. Un administrateur peut contrôler la génération du certificat par le biais des rôles.

Créez un rôle pour l’autorité de certification intermédiaire qui fournit un ensemble de stratégies pour l’émission ou la signature des certificats à l’aide de cette autorité de certification.

De nombreuses configurations peuvent être configurées lors de la création de rôles. Pour plus d’informations, consultez la documentation sur le rôle du coffre.

Pour le flux de travail, créez un rôle kube-ingress qui vous permet de signer des certificats de ${DOMAIN} et de ses sous-domaines avec une durée de vie de 90 jours.

    # 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-->

Créer une authentification basée sur une approbation

Après avoir configuré une autorité de certification intermédiaire pour signer les certificats, vous devez fournir un mécanisme d’authentification permettant au gestionnaire de certificats d’utiliser le coffre-fort pour signer les certificats. Cert-Manager prend en charge la méthode d’authentification Approle qui permet aux applications d’accéder aux rôles définis par Vault.

Un AppRole représente un ensemble de stratégies de coffre-fort et de contraintes de connexion qui doivent être respectées pour recevoir un jeton avec ces stratégies. Pour plus d’informations sur cette méthode d’authentification, consultez la documentation Approle.

Créer une approbation

Créez une Approle nommée Kube-role. Le paramètre secret_idpour cert-manager ne doit pas être expiré pour utiliser cette Approle pour l’authentification. Par conséquent, ne définissez pas de durée de vie ou ne la définissez pas sur 0.

% vault auth enable approle

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

Associer une stratégie à l’Approle

Effectuez les étapes suivantes pour associer une stratégie à une Approle.

  1. Créez un fichier pki_int.hcl avec la configuration suivante pour autoriser les points de terminaison de signature de l’autorité de certification intermédiaire.

        path "${PKI_INT}/sign/*" {
              capabilities = ["create","update"]
            }
    <!--NeedCopy-->
    
  2. Ajoutez le fichier à une nouvelle stratégie appelée kube_allow_sign à l’aide de la commande suivante.

    vault policy write kube-allow-sign pki_int.hcl
    
  3. Mettez à jour cette stratégie vers l’Approle à l’aide de la commande suivante.

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

kube-role de approle vous permet de signer le CSR avec une autorité de certification intermédiaire.

Générer l’ID de rôle et l’ID secret

L’ID de rôle et l’ID secret sont utilisés par le gestionnaire de certificats pour s’authentifier auprès du coffre-fort.

Générez l’ID de rôle et l’ID secret et codez l’ID secret avec Base64. Procédez comme suit :

% 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==

Configurer l’émission de certificats dans Kubernetes

Après avoir configuré Vault en tant qu’autorité de certification intermédiaire et la méthode d’authentification Approle pour que le gestionnaire de certificats accède à Vault, vous devez configurer le certificat pour l’entrée.

Créer un secret avec l’identifiant secret Approle

Procédez comme suit pour créer un secret avec l’ID secret Approle.

  1. Créez un fichier secret appelé secretid.yaml avec la configuration suivante.

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

    Remarque :

    L’ID secret data.secretId est l’ID secret codé en base64 généré dans Générer l’identifiant de rôle et l’identifiant secret. Si vous utilisez une ressource Issuer à l’étape suivante, le secret doit se trouver dans le même espace de noms que le Issuer. Pour ClusterIssuer, le secret doit se trouver dans l’espace de cert-manager noms.

  2. Déployez le fichier secret (secretid.yaml) à l’aide de la commande suivante.

    % kubectl create -f secretid.yaml
    

Déployer l’émetteur du cluster Vault

Le gestionnaire de certificats prend en charge deux CRD différents pour la configuration Issuer, an, qui est limité à un seul espace de noms, et a ClusterIssuer, qui est à l’échelle du cluster. Pour le flux de travail, vous devez utiliser ClusterIssuer.

Effectuez les étapes suivantes pour déployer l’émetteur du cluster Vault.

  1. Créez un fichier appelé issuer-vault.yaml avec la configuration suivante.

    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 est le nom secret Kubernetes créé à l’étape précédente. roleId Remplacez-le par le role_id récupéré dans le coffre-fort. Un caBundle codé en base64 optionnel au format PEM peut être fourni pour valider la connexion TLS au serveur Vault. Lorsque CABundle est défini, il remplace le bundle CA à l’intérieur du conteneur exécutant le gestionnaire de certificats. Ce paramètre n’a aucun effet si la connexion utilisée est en HTTP brut.

  2. Déployez le fichier (issuer-vault.yaml) à l’aide de la commande suivante.

    % kubectl create -f issuer-vault.yaml
    
  3. À l’aide de la commande suivante, vérifiez si l’émetteur du cluster du coffre-fort est correctement authentifié auprès du coffre-fort.

    % 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>
    

Vous avez maintenant configuré avec succès le gestionnaire de certificats pour Vault en tant qu’autorité de certification. L’étape suivante consiste à sécuriser l’entrée en générant le certificat de serveur. Il existe deux options différentes pour sécuriser votre entrée. Vous pouvez procéder à l’une des approches pour sécuriser vos entrées.

  • Approche de la cale d’entrée
  • Création manuelle de l’objet certificate CRD pour le certificat.

Approche Ingress-Shim

Dans cette approche, vous modifiez l’annotation d’entrée pour le gestionnaire de certificats afin de générer automatiquement le certificat pour le nom d’hôte donné et de le stocker dans le secret spécifié.

  1. Modifiez l’entrée avec la section tls spécifiant un nom d’hôte et un secret. Spécifiez également l’annotation du gestionnaire de certificats cert-manager.io/cluster-issuer comme suit.

            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. Déployez l’entrée modifiée comme suit.

      % 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
    

Cette étape déclenche un certificate objet par le gestionnaire de certificats qui crée une demande de signature de certificat (CSR) pour le domaine kuard.example.com. En cas de signature réussie de la CSR, le certificat est stocké dans le nom secret kuard-example-tls spécifié dans l’entrée.

  1. Vérifiez que le certificat a été correctement émis à l’aide de la commande suivante.

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

Création d’un objet certificate CRD pour le certificat

Une fois l’émetteur enregistré avec succès, vous devez obtenir le certificat pour le domaine d’entrée kuard.example.com.

Vous devez créer une ressource certificate à l’aide des paramètres commonName et dnsNames. Pour plus d’informations, consultez la documentation de cert-manager. Vous pouvez spécifier plusieurs noms DNS qui sont utilisés pour le champ SAN du certificat.

Pour créer un objet CRD « certificat » pour le certificat, effectuez les opérations suivantes :

  1. Créez un fichier appelé certificate.yaml avec la configuration suivante.

    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
    

    Le certificat contient CN=kuard.example.com et SAN=Kuard.example.com,www.kuard.example.com. spec.secretName est le nom du secret dans lequel le certificat est stocké une fois le certificat émis avec succès.

  2. Déployez le fichier (certificate.yaml) sur le cluster Kubernetes à l’aide de la commande suivante.

    % kubectl create -f certificate.yaml certificate.certmanager.k8s.io/kuard-example-tls créé

Vérifiez si le certificat est émis

Vous pouvez suivre la progression du certificat au fur et à mesure de sa délivrance à l’aide de la commande suivante :

% kubectl describe certificates kuard-example-tls  | grep -A5 Events
Events:
  Type    Reason      Age   From          Message
  ----    ------      ----  ----          -------
  Normal  CertIssued  48s   cert-manager  Certificate issued successfully > **Remarque** > > Vous pouvez rencontrer des erreurs en raison des politiques du coffre-fort. Si vous rencontrez de telles erreurs, retournez dans le coffre-fort et corrigez-le.

Une fois la signature réussie, un kubernetes.io/tls secret est créé avec le secretName spécifié dans la Certificate ressource.

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

Modifiez l’entrée pour utiliser le secret généré

Effectuez les étapes suivantes pour modifier l’entrée afin d’utiliser le secret généré.

  1. Modifiez l’entrée d’origine et ajoutez une section spec.tls spécifiant le secret kuard-example-tls comme suit.

          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. Déployez l’entrée à l’aide de la commande suivante.

    % 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
    

Vérifiez la configuration Ingress dans Citrix ADC

Une fois le certificat généré avec succès, le Citrix ingress controller utilise ce certificat pour configurer le serveur virtuel SSL frontal. Vous pouvez le vérifier en suivant les étapes suivantes.

  1. Ouvrez une session sur Citrix ADC CPX et vérifiez si le certificat est lié au serveur virtuel SSL.

    % 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
    

    Le serveur Web HTTPS est en place avec le certificat signé du coffre. Le gestionnaire de certificats renouvelle automatiquement le certificat tel que spécifié dans le paramètre RenewBefore du certificat, avant l’expiration du certificat.

    Remarque :

    La signature du certificat par le coffre-fort échoue si l’expiration d’un certificat est au-delà de l’expiration de l’autorité de certification racine ou de l’autorité de certification intermédiaire. Vous devez vous assurer que les certificats d’autorité de certification sont renouvelés à l’avance avant leur expiration.

  2. Vérifiez que l’application est accessible à l’aide du protocole HTTPS.

    % 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
    
Déployer une application Web HTTPS sur Kubernetes avec le Citrix ingress controller et HashiCorp Vault à l’aide de cert-manager