Contrôleur d'entrée Citrix ADC

Déployez l’application Web HTTPS sur Kubernetes avec le Citrix ingress controller et Let`s Encrypt à l’aide de cert-manager

Let’s Encrypt et le protocole ACME (Automatic Certificate Management Environment) vous permettent de configurer un serveur HTTPS et d’obtenir automatiquement un certificat approuvé par le navigateur. Pour obtenir un certificat pour le domaine de votre site Web auprès de Let’s Encrypt, vous devez démontrer le contrôle du domaine en relevant certains défis. Un défi fait partie d’une liste de tâches spécifiées que seule une personne qui contrôle le domaine peut accomplir.

Il existe actuellement deux types de défis :

  • Défi HTTP-01 : Les défis HTTP-01 sont complétés en publiant un fichier spécifié dans un emplacement spécifié sur un site Web. Let’s Encrypt CA vérifie le fichier en effectuant une requête HTTP sur l’URI HTTP pour répondre au défi.

  • Défi DNS-01 : les défis DNS01 sont complétés en fournissant une clé calculée présente dans un enregistrement DNS TXT. Une fois cet enregistrement TXT propagé sur Internet, le serveur ACME peut récupérer cette clé via une recherche DNS. Le serveur ACME peut valider que le client est propriétaire du domaine pour le certificat demandé. Avec les autorisations correctes, cert-manager présente automatiquement cet enregistrement TXT pour votre fournisseur DNS spécifié.

En cas de validation réussie du défi, un certificat est accordé pour le domaine.

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

Conditions préalables

Assurez-vous que vous avez :

  • Le domaine pour lequel le certificat est demandé est accessible au public.
  • 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 modèle de déploiement de niveau 2, un service TCP est configuré sur Citrix ADC (VPX/MPX) s’exécutant en dehors du cluster Kubernetes. Ce service est créé 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.

  • Déploiement du Citrix ingress controller - effectué. Cliquez ici pour consulter les différents scénarios de déploiement.

  • Ouverture du port 80 pour l’adresse IP virtuelle sur le pare-feu afin que l’autorité de certification Let’s Encrypt valide le domaine pour le défi HTTP01.

  • Domaine DNS que vous contrôlez, dans lequel vous hébergez votre application Web pour le défi ACME DNS01.

  • Permissions d’administrateur pour toutes les étapes de déploiement. Si vous rencontrez des échecs en raison d’autorisations, assurez-vous de disposer des autorisations d’administrateur.

Installation de cert-manager

Pour installer cert-manager, consultez la documentation d’installation de cert-manager.

Vous pouvez installer cert-manager à l’aide de fichiers manifestes ou d’un graphique Helm.

Une fois que vous avez installé le gestionnaire de certificats, vérifiez que le gestionnaire de certificats est opérationnel comme expliqué lors de la vérification de l’installation.

Déployer un exemple d’application Web

Effectuez les opérations 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:
              labels:
                app: kuard
              name: kuard
            spec:
              replicas: 1
              selector:
                matchLabels:
                  app: kuard
              template:
                metadata:
                  labels:
                    app: kuard
                spec:
                  containers:
                  - image: gcr.io/kuar-demo/kuard-amd64:1
                    imagePullPolicy: Always
                    name: kuard
                    ports:
                    - containerPort: 8080
                      protocol: TCP
    <!--NeedCopy-->
    
  2. Déployez le fichier de déploiement Kuard (kuard-deployment.yaml) sur votre cluster, à l’aide des commandes suivantes :

    % kubectl créer -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 des commandes suivantes :

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

    Veille kubernetes.io/ingress.class à ce que vous remplaciez la valeur de par 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
    

Remarque :

Vous devez remplacer 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.

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

    % kubectl apply -f ingress.yml
    ingress.extensions/kuard created
    
    root@ubuntu-:~/cert-manager# kubectl get ingress
    NAME    HOSTS               ADDRESS   PORTS   AGE
    kuard   kuard.example.com             80      7s
    
  2. Vérifiez que 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-55c88788fd-qd4rg:/# cli_script.sh 'show cs vserver'
    exec: show cs vserver
    1)  k8s-192.168.8.178_80_http (192.168.8.178:80) - HTTP Type: CONTENT
      State: UP
      Last state change was at Sat Jan  4 13:36:14 2020
      Time since last state change: 0 days, 00:18:01.950
      Client Idle Timeout: 180 sec
      Down state flush: ENABLED
      Disable Primary Vserver On Down : DISABLED
      Comment: uid=MPPL57E3AFY6NMNDGDKN2VT57HEZVOV53Z7DWKH44X2SGLIH4ZWQ====
      Appflow logging: ENABLED
      Port Rewrite : DISABLED
      State Update: DISABLED
      Default:  Content Precedence: RULE
      Vserver IP and Port insertion: OFF
      L2Conn: OFF Case Sensitivity: ON
      Authentication: OFF
      401 Based Authentication: OFF
      Push: DISABLED  Push VServer:
      Push Label Rule: none
      Persistence: NONE
      Listen Policy: NONE
      IcmpResponse: PASSIVE
      RHIstate:  PASSIVE
      Traffic Domain: 0
    Done
    
    root@cpx-ingress-55c88788fd-qd4rg/# exit
    exit
    
  3. Vérifiez que la page Web est correctement diffusé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
    

Configurer l’émission d’un certificat ACME à l’aide du défi HTTP

Cette section décrit comment émettre le certificat ACME à l’aide de la validation HTTP. Si vous souhaitez utiliser la validation DNS, ignorez cette section et passez à la section suivante.

La validation HTTP à l’aide de cert-manager est un moyen simple d’obtenir un certificat de Let’s Encrypt pour votre domaine. Dans cette méthode, vous prouvez la propriété d’un domaine en vous assurant qu’un fichier particulier est présent sur le domaine. Il est supposé que vous contrôlez le domaine si vous êtes en mesure de publier le fichier donné sous un chemin donné.

Déployer Let’s Encrypt ClusterIssuer avec le fournisseur de défi HTTP01

Le gestionnaire de certificats prend en charge deux CRD différents pour la configuration, un Issuer, limité à un seul espace de noms, et un ClusterIssuer, avec une portée à l’échelle du cluster.

Pour que le Citrix ingress controller utilise l’entrée à partir de n’importe quel espace de noms, utilisez ClusterIssuer. Vous pouvez également créer un espace de noms Issuer pour chaque espace de noms sur lequel vous créez une ressource Ingress.

Pour plus d’informations, consultez la documentation de cert-manager pour la validation HTTP.

  1. Créez un fichier appelé issuer-letsencrypt-staging.yaml avec la configuration suivante :

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

    spec.acme.solvers[].http01.ingress.class fait référence à la classe Ingress du Citrix ingress controller. Si le Citrix ingress controller n’a pas de classe d’entrée, vous n’avez pas besoin de spécifier ce champ. Remarque : Il s’agit d’un exemple Clusterissuer de ressource cert-manager.io/v1alpha2. Pour plus d’informations, consultez la documentation http01 de cert-manager.

    Le serveur intermédiaire Let’s Encrypt émet un faux certificat, mais il n’est pas lié par les limites de débit de l’API du serveur de production. Cette approche vous permet de configurer et de tester votre environnement sans vous soucier des limites de débit. Vous pouvez répéter la même étape pour le serveur de production Let’s Encrypt.

  2. Après avoir modifié et enregistré le fichier, déployez-le à l’aide de la commande suivante :

    % kubectl apply -f issuer-letsencrypt-staging.yaml
    clusterissuer "letsencrypt-staging" created
    
  3. Vérifiez que l’émetteur est créé et enregistré sur le serveur ACME.

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  4. Vérifiez que ClusterIssuer est correctement enregistré à l’aide de la commande kubectl describe issuer letsencrypt-staging :

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

Certificat de délivrance pour l’objet Ingress

Une fois ClusterIssuer l’enregistrement réussi, vous pouvez obtenir un certificat pour le domaine d’entrée « kuard.exemple.com ».

Vous pouvez demander un certificat pour la ressource Ingress spécifiée à l’aide des méthodes suivantes :

  • Ajout d’annotations Ingress-shim à l’objet Ingress.

  • Création d’un objet certificate CRD.

La première méthode est simple et rapide, mais si vous avez besoin de plus de personnalisation et de granularité en termes de renouvellement de certificat, vous pouvez choisir la deuxième méthode. Vous pouvez choisir la méthode en fonction de vos besoins.

Ajout d’annotations Ingress-shim à l’objet Ingress

Dans cette approche, vous ajoutez les deux annotations suivantes à l’objet Ingress pour lequel vous demandez un certificat auprès du serveur ACME.

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

Remarque :

Vous pouvez trouver toutes les annotations prises en charge à partir de cert-manager for Ingress-shim, dans supported-annotations.

Modifiez également le ingress.yaml pour utiliser le protocole TLS en spécifiant un code secret.

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

L’annotation cert-manager.io/cluster-issuer: "letsencrypt-staging" indique au gestionnaire de certificats d’utiliser l’émetteur à l’échelle du cluster letsencrypt-staging pour demander un certificat aux serveurs intermédiaires de Let’s Encrypt. Le gestionnaire de certificats crée un certificate objet qui est utilisé pour gérer le cycle de vie du certificat pour kuard.example.com. La valeur du nom de domaine et de la méthode de défi pour l’objet de certificat est dérivée de l’objet d’entrée. Le gestionnaire de certificats gère le contenu du secret tant que l’entrée est présente dans votre cluster.

Déployez le fichier ingress.yaml à l’aide de la commande suivante :

% kubectl apply -f ingress.yml

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

Créer une ressource CRD de certificat

Vous pouvez également déployer un objet CRD de certificat indépendant de l’objet Ingress. La documentation du CRD « certificat » se trouve sur la page de validation HTTP.

  1. Créez le fichier certificate.yaml avec la configuration suivante :
        apiVersion: cert-manager.io/v1alpha2
        kind: Certificate
        metadata:
          name: example-com
          namespace: default
        spec:
          secretName: kuard-example-tls
          issuerRef:
            name: letsencrypt-staging
          commonName: kuard.example.com
          dnsNames:
          - www.kuard.example.com
   <!--NeedCopy-->

La spec.secretName clé est le nom du secret dans lequel le certificat est stocké en cas de réussite de l’émission du certificat.

  1. Déployez le fichier certificate.yaml sur le cluster Kubernetes :

    kubectl create -f certificate.yaml
    certificate.cert-manager.io/example-com created
    
  2. Vérifiez que la ressource personnalisée de certificat est créée par le gestionnaire de certificats qui représente le certificat spécifié dans l’entrée. Après quelques minutes, si la validation ACME se passe bien, l’état du certificat « READY » est défini sur true.

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

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

Émission d’un certificat ACME à l’aide du défi DNS

Cette section décrit une façon d’utiliser la validation DNS pour obtenir le certificat ACME auprès de Let’sEncrypt CA. Avec un défi DNS-01, vous démontrez la propriété d’un domaine en prouvant que vous contrôlez ses enregistrements DNS. Pour ce faire, créez un enregistrement TXT avec un contenu spécifique qui prouve que vous avez le contrôle des enregistrements DNS du domaine. Pour une explication détaillée du défi DNS et des meilleures pratiques de sécurité dans le déploiement du défi DNS, voir A Technical Deep Dive : Securing the Automation of ACME DNS Challenge Validation.

Remarque :

Dans cette procédure, route53 est utilisé en tant que fournisseur DNS. Pour les autres fournisseurs, consultez la documentation du gestionnaire de certificats sur la validation DNS.

Déployer le Cluster Issuer Let’s Encrypt avec le fournisseur de défi DNS01

Effectuez les opérations suivantes pour déployer Let’s Encrypt ClusterIssuer avec le fournisseur de défi DNS01 :

  1. Créez un compte utilisateur AWS IAM et téléchargez l’ID de clé d’accès secrète et la clé d’accès secrète.
  2. Accordez la stratégie IAM suivante à votre utilisateur :

    Politique d’accès Route53

  3. Créez un secret Kubernetes acme-route53 dans l’espace de kube-system noms.

    % kubectl create secret generic acme-route53 --from-literal secret-access-key=<secret_access_key>
    
  4. Créez un Issuer ou ClusterIssuer avec le fournisseur de défi DNS01.

    Vous pouvez fournir plusieurs fournisseurs sous DNS01 et spécifier le fournisseur à utiliser au moment de la création du certificat. Vous devez avoir accès au fournisseur DNS pour que cert-manager puisse créer un enregistrement TXT. Les informations d’identification sont stockées dans le secret Kubernetes spécifié dans spec.dns01.secretAccessKeySecretRef. Pour obtenir des instructions détaillées sur la façon d’obtenir des informations d’identification, consultez la documentation du fournisseur DNS.

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

    Remarque :

    Remplacez user@example.com par votre adresse e-mail. Pour chaque domaine mentionné dans une section DNS01, cert-manager utilise les informations d’identification du fournisseur de l’émetteur référencé pour créer un enregistrement TXT appelé _acme-challenge. Cet enregistrement est ensuite vérifié par le serveur ACME pour émettre le certificat. Pour plus d’informations sur la configuration du fournisseur DNS et la liste des fournisseurs pris en charge, consultez le document de référence DNS01.

  5. Après avoir modifié et enregistré le fichier, déployez-le à l’aide de la commande suivante :

    % kubectl apply -f acme_clusterissuer_dns.yaml
    clusterissuer "letsencrypt-staging" created
    
  6. Vérifiez si l’émetteur est créé et enregistré sur le serveur ACME à l’aide de la commande suivante :

    % kubectl get issuer
    NAME                  AGE
    letsencrypt-staging   8d
    
  7. Vérifiez si ClusterIssuer est correctement enregistré à l’aide de la commande kubectl describe issuer letsencrypt-staging :

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

Certificat d’émission pour la ressource Ingress

Une fois l’émetteur enregistré avec succès, vous pouvez obtenir un certificat pour le domaine d’entrée kuard.example.com. Comme pour le défi HTTP01, vous pouvez demander le certificat pour une ressource d’entrée spécifiée de deux manières :

  • Ajout d’annotations Ingress-shim à l’objet Ingress.

  • Création d’un objet certificate CRD. Pour obtenir des instructions détaillées, reportez-vous à la section Créer une ressource CRD de certificat.

Ajout d’annotations Ingress-shim à l’objet Ingress

Ajoutez l’annotation suivante à l’objet Ingress avec la section spec.tls:

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

Le gestionnaire de certificat crée une ressource Certificate CRD avec le défi DNS01. Il utilise les informations d’identification spécifiées dans le ClusterIssuer pour créer un enregistrement TXT sur le serveur DNS pour le domaine que vous possédez. Ensuite, Let’s Encypt CA valide le contenu de l’enregistrement TXT pour terminer le défi.

Ajouter une ressource Certificate CRD**

Vous pouvez également créer explicitement une ressource de définition de ressource personnalisée de certificat pour déclencher la génération automatique de certificats.

  1. Créez le fichier certificate.yaml avec la configuration suivante :

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

    Une fois le nom de domaine validé, l’état READY du certificat est défini sur True.

  2. Vérifiez que le certificat est émis.

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

    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 | tail -n 6

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

Vérifiez le certificat dans Citrix ADC

Letsencrypt CA a validé avec succès le domaine et a émis un nouveau certificat pour le domaine. Un secret kubernetes.io/tls est créé avec le secretName spécifié dans le champ tls: de l’entrée. De plus, cert-manager lance automatiquement un renouvellement, 30 jours avant l’expiration.

Pour le défi HTTP, cert-manager crée une ressource d’entrée temporaire pour acheminer le trafic généré par l’autorité de certification Let’s Encrypt vers les espaces du gestionnaire de certificats. En cas de validation réussie du domaine, cette entrée temporaire est supprimée.

  1. Vérifiez que le secret est créé à l’aide de la commande suivante :

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

    Le Citrix ingress controller récupère le secret et lie le certificat au serveur virtuel de commutation de contenu sur Citrix ADC CPX. S’il existe des certificats d’autorité de certification intermédiaires, ils sont automatiquement liés au certificat du serveur et présentés au client lors de la négociation SSL.

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

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

Le serveur Web HTTPS est maintenant opérationnel avec un faux certificat signé LE. L’étape suivante consiste à passer en production avec les certificats Let’s Encrypt.

Passez à la production

Après avoir testé avec succès Let’s Encrypt-staging, vous pouvez obtenir le certificat Let’s Encrypt.

Vous devez remplacer le point de terminaison Let’s Encrypt par https:acme-staging-v02.api.letsencrypt.org/directoryhttps:acme-v02.api.letsencrypt.org/directory

Ensuite, remplacez le nom du letsencrypt-staging clusterIssuer par letsencrypt-production


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

Remarque :

Remplacez user@example.com par votre adresse e-mail.

Déployez le fichier à l’aide de la commande suivante :

% kubectl apply -f letsencrypt-prod.yaml

 clusterissuer "letsencrypt-prod" created

Répétez maintenant la procédure de modification de l’annotation dans Ingress ou de création d’un certificat CRD qui déclenche la génération d’un nouveau certificat.

Remarque

Assurez-vous de supprimer l’ancien secret afin que le gestionnaire de certificats lance un nouveau défi avec l’autorité de certification de production.

% kubectl delete secret kuard-example-tls

 secret "kuard-example-tls" deleted

Une fois que le site Web HTTP est actif, vous pouvez rediriger le trafic de HTTP vers HTTPS à l’aide de l’annotation ingress.citrix.com/insecure-termination: redirect dans l’objet d’entrée.

Résolution des problèmes

Étant donné que la génération du certificat implique plusieurs composants, cette section résume les techniques de dépannage que vous pouvez utiliser en cas d’échec.

Vérifiez l’état de la génération des certificats

L’objet CRD du certificat définit la gestion du cycle de vie de la génération et du renouvellement des certificats. Vous pouvez afficher l’état du certificat à l’aide de la commande kubectl describe comme suit.

% kubectl get certificate

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

%  kubectl describe certificate kuard-example-tls

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

Vous pouvez également afficher les principaux événements liés aux certificats à l’aide de la commande kubectl events :

kubectl get events

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

Analyser les journaux depuis le cert-manager

En cas d’échec, la première étape consiste à analyser les journaux du composant cert-manager. Identifiez le pod cert-manager à l’aide de la commande suivante :

% kubectl get po -n cert-manager

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

cert-manager-76d48d47bf-5w4vx Voici le module principal du gestionnaire de certificats, et les deux autres espaces sont des modules de webhook de gestionnaire de certificats.

Obtenez les journaux du gestionnaire de certificats à l’aide de la commande suivante :

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

En cas d’échec d’obtention du certificat, les journaux ERROR fournissent des détails sur l’échec.

Vérifiez le secret de Kubernetes

Utilisez la commande kubectl describe pour vérifier si les certificats et la clé sont renseignés dans le code secret Kubernetes.

% kubectl describe secret kuard-example-tls

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

Type:  kubernetes.io/tls

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

Si les deux tls.crt et tls.key sont renseignés dans le secret Kubernetes, la génération du certificat est terminée. Si seul tls.key est présent, la génération du certificat est incomplète. Analysez les journaux du gestionnaire de certificats pour plus de détails sur le problème.

Analyser les journaux du Citrix ingress controller

Si un secret Kubernetes est généré et complet, mais qu’il n’est pas chargé sur Citrix ADC, vous pouvez analyser les journaux du Citrix ingress controller à l’aide de la commande suivante.

% kubectl logs -f cpx-ingress-685c8bc976-zgz8q
Déployez l’application Web HTTPS sur Kubernetes avec le Citrix ingress controller et Let`s Encrypt à l’aide de cert-manager