Déployer une application web HTTPS sur Kubernetes avec NetScaler Ingress Controller et HashiCorp Vault à l'aide de cert-manager

Dernière publication : Oct 02, 2026
Pour les ressources d'entrée déployées avec le NetScaler Ingress Controller, vous pouvez automatiser l'approvisionnement, 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 comme autorité de certification auto-signée pour les demandes de signature de certificat de cert-manager.
Plus précisément, le flux de travail utilise le moteur de secrets PKI de Vault pour créer une autorité de certification (CA). Ce tutoriel suppose que vous avez un serveur Vault installé et accessible depuis le cluster Kubernetes. Le moteur de secrets PKI de Vault est adapté aux applications internes. Pour les applications externes qui nécessitent une confiance publique, consultez l'automatisation des certificats TLS à l'aide de l'autorité de certification Let’s Encrypt.
Le flux de travail utilise un moteur de secrets Vault et des méthodes d'authentification. Pour la liste complète des fonctionnalités de Vault, consultez la documentation Vault suivante :
Cette rubrique vous fournit des informations sur la façon de déployer une application web HTTPS sur un cluster Kubernetes, en utilisant :
Related information
Gestion des certificats

Prérequis

Assurez-vous que vous avez :
  • Le serveur Vault est installé, déverrouillé et accessible depuis le cluster Kubernetes. Pour plus d'informations sur l'installation du serveur Vault, consultez la documentation d'installation de Vault.
  • Activé le RBAC sur votre cluster Kubernetes.
  • Déployé NetScaler MPX, VPX ou CPX dans un modèle de déploiement de niveau 1 ou de niveau 2.
    Dans le modèle de déploiement de niveau 1, NetScaler MPX ou VPX est utilisé comme contrôleur de livraison d'applications (ADC). Le NetScaler Ingress Controller exécuté dans le cluster Kubernetes configure les services virtuels pour les services exécutés sur le cluster Kubernetes. NetScaler exécute le service virtuel sur l'adresse IP routable publiquement et décharge le 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 le NetScaler (VPX/MPX) exécuté en dehors du cluster Kubernetes pour transférer le trafic vers les instances NetScaler CPX exécutées dans le cluster Kubernetes. NetScaler CPX met fin à la session SSL et équilibre la charge du trafic vers les pods de service réels.
  • NetScaler Ingress Controller déployé. Consultez Topologies de déploiement pour les différents scénarios de déploiement.
  • Autorisations d'administrateur pour toutes les étapes de déploiement. Si vous rencontrez des échecs dus aux autorisations, assurez-vous de disposer de l'autorisation d'administrateur.
Remarque :
La procédure suivante présente les étapes pour configurer Vault en tant qu'autorité de certification avec NetScaler CPX utilisé comme périphérique d'entrée. Lorsqu'un NetScaler VPX ou MPX est utilisé comme périphérique d'entrée, les étapes sont les mêmes, à l'exception des étapes de vérification de la configuration d'entrée dans le NetScaler.

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

Effectuez les étapes suivantes pour déployer cert-manager à 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 opérationnel à 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 comme 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
  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 nommé service.yaml avec la configuration suivante.
    apiVersion: v1
    kind: Service
    metadata:
      name: kuard
    spec:
      ports:
      - port: 80
        targetPort: 8080
        protocol: TCP
      selector:
        app: kuard
  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 un Ingress qui est déployé sur NetScaler CPX ou VPX en tant que serveur virtuel de commutation de contenu.
    Remarque :
    Assurez-vous de modifier ingressClassName: citrix par votre classe d'entrée sur laquelle le contrôleur d'entrée NetScaler est démarré.
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
      name: kuard
    spec:
      ingressClassName: citrix
      rules:
      - host: kuard.example.com
        http:
          paths:
          - backend:
              service:
                name: kuard
                port:
                  number: 80
            path: /
            pathType: Prefix
    Remarque :
    Modifiez la valeur de spec.rules.host par le domaine que vous contrôlez. Assurez-vous qu'une entrée DNS existe pour acheminer le trafic vers NetScaler CPX ou VPX.
  6. Déployez l'Ingress à 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'Ingress est configuré sur NetScaler 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 servie lorsqu'elle est demandée à 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 rendre l'application disponible via HTTPS. Ici, le serveur Vault signe le CSR généré par le cert-manager et un certificat de serveur est automatiquement généré pour l'application.
Dans la procédure suivante, vous utilisez le Vault configuré comme autorité de certification et configurez le cert-manager pour qu'il utilise le Vault comme 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 Vault est utilisé par le cert-manager pour signer le certificat des ressources d'entrée.
Remarque :
Assurez-vous d'avoir installé l'utilitaire jq avant d'effectuer ces étapes.

Créer une AC racine

Pour l'exemple de flux de travail, vous pouvez générer votre propre autorité de certification racine (Root Certificate Authority) au sein de Vault. Dans un environnement de production, vous devriez 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 où vous montez l'autorité de certification racine, il s'agit généralement de 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"

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

Après avoir créé l'autorité de certification racine, suivez les étapes suivantes pour créer une demande de signature de certificat (CSR) intermédiaire à l'aide de l'autorité de certification racine.
  1. Activez le PKI à partir d'un chemin différent PKI_INT de l'autorité de certification racine, généralement 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}
  2. Générez une CSR pour ${DOMAIN} qui doit être signée par l'autorité de certification racine. La clé est stockée en interne dans Vault. 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)
  3. Générez et signez le certificat ${DOMAIN} en tant qu'autorité de certification intermédiaire à l'aide de l'autorité de certification racine, stockez-le sous le nom 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
    Si vous utilisez une autorité de certification racine externe, ignorez l'étape précédente et signez manuellement la CSR à l'aide de l'autorité de certification racine.
  4. Une fois la CSR signée et que l'autorité de certification racine renvoie un certificat, celui-ci doit être réintégré dans Vault à l'aide de la commande suivante :
    % vault write "${PKI_INT}"/intermediate/set-signed certificate=@intermediate.cert.pem
  5. Définissez l'emplacement de la CA 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"
Une CA 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 politiques. Un administrateur peut contrôler la génération de certificats via les rôles.
Créez un rôle pour l'autorité de certification intermédiaire qui fournit un ensemble de politiques pour l'émission ou la signature des certificats à l'aide de cette autorité de certification.
De nombreuses configurations peuvent être définies lors de la création de rôles. Pour plus d'informations, consultez la documentation sur les rôles Vault.
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 (TTL) 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

Créer une authentification basée sur Approle

Après avoir configuré une CA intermédiaire pour signer les certificats, vous devez fournir un mécanisme d'authentification pour que cert-manager puisse utiliser Vault 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 dans Vault.
Un AppRole représente un ensemble de politiques Vault et de contraintes de connexion qui doivent être respectées pour recevoir un jeton avec ces politiques. Pour plus d'informations sur cette méthode d'authentification, consultez la documentation Approle.

Créer un Approle

Créez un Approle nommé Kube-role. Le secret_id pour le cert-manager ne doit pas être expiré pour utiliser cet Approle pour l'authentification. Par conséquent, ne définissez pas de TTL ou définissez-le sur 0.
% vault auth enable approle

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

Associer une politique à l'Approle

Effectuez les étapes suivantes pour associer une politique à un 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"]
        }
  2. Ajoutez le fichier à une nouvelle politique appelée kube_allow_sign à l'aide de la commande suivante.
    vault policy write kube-allow-sign pki_int.hcl
  3. Mettez à jour cette politique pour l'Approle à l'aide de la commande suivante.
    vault write auth/approle/role/kube-role policies=kube-allow-sign
L'approle kube-role vous permet de signer le CSR avec l'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 cert-manager pour s'authentifier auprès de Vault.
Générez l'ID de rôle et l'ID secret, puis encodez l'ID secret en Base64. Effectuez les opérations suivantes :
% 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 comme CA intermédiaire et la méthode d'authentification Approle pour que le cert-manager accède à Vault, vous devez configurer le certificat pour l'ingress.

Créer un secret avec l'ID secret Approle

Effectuez les opérations suivantes pour créer un secret avec l'ID secret Approle.
  1. Créez un fichier secret nommé 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 encodé en base64 généré dans Générer l'ID de rôle et l'ID 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 noms cert-manager.
  2. Déployez le fichier secret (secretid.yaml) à l'aide de la commande suivante.
    % kubectl create -f secretid.yaml

Déployer l'émetteur de cluster Vault

Le cert-manager prend en charge deux CRD différentes pour la configuration : un Issuer, qui est limité à un seul espace de noms, et un ClusterIssuer, qui est à l'échelle du cluster. Pour le workflow, vous devez utiliser ClusterIssuer.
Effectuez les étapes suivantes pour déployer l'émetteur de cluster Vault.
  1. Créez un fichier nommé 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 du secret Kubernetes créé à l'étape précédente. Remplacez roleId par le role_id récupéré de Vault. Un caBundle encodé en base64 facultatif 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 cert-manager. Ce paramètre n'a aucun effet si la connexion utilisée est en HTTP simple.
  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 de cluster Vault est correctement authentifié auprès de Vault.
    % 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 cert-manager pour Vault en tant qu'autorité de certification. L'étape suivante consiste à sécuriser l'ingress en générant le certificat de serveur. Il existe deux options différentes pour sécuriser votre ingress. Vous pouvez procéder avec l'une des approches pour sécuriser vos ingress.
  • Approche Ingress Shim
  • Création manuelle de l'objet CRD certificate pour le certificat.

Approche Ingress-shim

Dans cette approche, vous modifiez l'annotation d'ingress pour que le cert-manager génère automatiquement le certificat pour le nom d'hôte donné et le stocke dans le secret spécifié.
  1. Modifiez l'ingress avec la section tls spécifiant un nom d'hôte et un secret. Spécifiez également l'annotation cert-manager cert-manager.io/cluster-issuer comme suit.
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
        cert-manager.io/cluster-issuer: vault-issuer
      name: kuard
    spec:
      ingressClassName: citrix
      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
  2. Déployez l'ingress modifié 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 objet certificate par le cert-manager 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 de secret kuard-example-tls spécifié dans l'ingress.
  1. Vérifiez que le certificat est 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éer un objet CRD certificate 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 avec commonName et dnsNames. Pour plus d'informations, consultez la documentation cert-manager. Vous pouvez spécifier plusieurs dnsNames qui sont utilisés pour le champ SAN dans le certificat.
Pour créer un objet CRD "certificate" pour le certificat, effectuez les opérations suivantes :
  1. Créez un fichier nommé 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 a CN=kuard.example.com et SAN=Kuard.example.com,www.kuard.example.com. spec.secretName est le nom du secret où le certificat est stocké après son émission réussie.
  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érifier si le certificat est émis

Vous pouvez suivre la progression de l'émission du certificat à 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 dues aux politiques de Vault. Si vous rencontrez de telles erreurs, revenez à Vault et corrigez-les.
Après une signature réussie, un secret kubernetes.io/tls est créé avec le secretName spécifié dans la ressource Certificate.
% kubectl get secret kuard-example-tls
NAME                TYPE                DATA   AGE
kuard-exmaple-tls   kubernetes.io/tls   3      4m20s

Modifier 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 originale et ajoutez une section spec.tls spécifiant le secret kuard-example-tls comme suit.
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      annotations:
      name: kuard
    spec:
      ingressClassName: citrix®
      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'Ingress à 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érifier la configuration de l'Ingress dans NetScaler

Une fois le certificat généré avec succès, NetScaler Ingress Controller utilise ce certificat pour configurer le serveur virtuel SSL frontal. Vous pouvez le vérifier en suivant les étapes ci-dessous.
  1. Connectez-vous à NetScaler 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 opérationnel avec le certificat signé par Vault. Cert-manager renouvelle automatiquement le certificat, comme spécifié dans le paramètre RenewBefore du certificat, avant l'expiration de celui-ci.
    Remarque :
    La signature du certificat par Vault échoue si l'expiration d'un certificat dépasse l'expiration de l'AC racine ou de l'AC intermédiaire. Vous devez vous assurer que les certificats d'AC sont renouvelés à l'avance avant leur expiration.
  2. Vérifiez que l'application est accessible via le 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