Automatiser la gestion des certificats dans un environnement Kubernetes

Jason Schmidt

Les certificats SSL/TLS valides sont indispensables dans le paysage applicatif moderne. Malheureusement, la gestion du renouvellement des certificats est souvent reléguée au second plan lors du déploiement d’une application. Les certificats ont une durée de validité limitée, allant d’environ 13 mois pour les certificats de DigiCert à 90 jours pour les certificats Let’s Encrypt. Pour maintenir un accès sécurisé, ces certificats doivent être renouvelés ou réémis avant leur expiration. Compte tenu de la charge de travail considérable de la plupart des équipes d’exploitation, le renouvellement des certificats passe parfois entre les mailles du filet, ce qui entraîne une course contre la montre à l’approche de leur date d’expiration, voire, pire encore, une fois celle-ci dépassée.

Il n’est pas nécessaire qu’il en soit ainsi. Avec un peu de planification et de préparation, la gestion des certificats peut être automatisée et rationalisée. Nous allons ici examiner une solution pour Kubernetes reposant sur trois technologies :

• Le cert-manager de Jetstack
• Let’s Encrypt
• Contrôleur Ingress NGINX

Dans cet article, vous apprendrez à simplifier la gestion des certificats en fournissant à vos points de terminaison des certificats uniques, renouvelés et mis à jour automatiquement.

Certificats dans un environnement Kubernetes

Avant d’entrer dans les détails techniques, nous devons définir quelques termes. L’expression « certificat TLS » désigne deux composants nécessaires pour activer les connexions HTTPS sur notre contrôleur Ingress :

• Le certificat
• La clé privée

Le certificat et la clé privée sont tous deux émis par Let’s Encrypt. Pour une explication complète du fonctionnement des certificats TLS, consultez l’article de DigiCert intitulé « Fonctionnement des certificats TLS/SSL ».

Dans Kubernetes, ces deux composants sont stockés sous forme de Secrets. Les charges de travail Kubernetes, telles que le contrôleur Ingress NGINX et cert-manager, peuvent lire et écrire ces Secrets, qui peuvent également être gérés par les utilisateurs ayant accès à l’installation Kubernetes.

Présentation de cert-manager

Le projet « cert-manager » est un contrôleur de certificats compatible avec Kubernetes et OpenShift. Lorsqu’il est déployé dans Kubernetes, cert-manager émet automatiquement les certificats requis par les contrôleurs Ingress et veille à ce qu’ils soient valides et à jour. Il surveille également les dates d’expiration des certificats et tente de les renouveler selon un intervalle configuré. Bien qu’il fonctionne avec de nombreux émetteurs publics et privés, nous présenterons ici son intégration avec Let’s Encrypt.

Deux types de défis

Lorsque vous utilisez Let’s Encrypt, toute la gestion des certificats est automatisée. Bien que cela soit très pratique, cela soulève également un problème : comment le service s’assure-t-il que vous êtes bien propriétaire du nom de domaine complet (FQDN) concerné ?

Ce problème est résolu à l’aide d’un challenge, qui vous oblige à répondre à une demande de vérification à laquelle seule une personne ayant accès aux enregistrements DNS du domaine concerné peut répondre. Les challenges peuvent prendre l’une des deux formes suivantes :

1. HTTP-01 : ce challenge peut être relevé en disposant d’un enregistrement DNS pour le nom de domaine complet (FQDN) pour lequel vous émettez un certificat. Par exemple, si l’adresse IP de votre serveur est www.xxx.yyy.zzz et que votre FQDN est cert.example.com, le mécanisme de challenge mettra à disposition un jeton sur le serveur à l’adresse www.xxx.yyy.zzz, et les serveurs de Let’s Encrypt tenteront d’y accéder via cert.example.com. En cas de réussite, le challenge est validé et le certificat est émis. HTTP-01 est le moyen le plus simple de générer un certificat, car il ne nécessite pas d’accès direct au fournisseur DNS. Ce type de challenge s’effectue toujours sur le port 80 (HTTP). Notez que lors de l’utilisation de challenges HTTP-01, cert-manager utilise le contrôleur Ingress pour fournir le jeton du challenge.

1. DNS-01 : ce challenge crée un enregistrement DNS TXT contenant un jeton, qui est ensuite vérifié par l’émetteur. Si le jeton est reconnu, vous avez prouvé que vous êtes propriétaire de ce domaine et pouvez désormais émettre des certificats pour ses enregistrements. Contrairement au challenge HTTP-01, lorsque vous utilisez le challenge DNS-01, le nom de domaine complet (FQDN) n’a pas besoin de pointer vers l’adresse IP de votre serveur (ni même d’exister). De plus, DNS-01 peut être utilisé lorsque le port 80 est bloqué. En contrepartie de cette facilité d’utilisation, vous devez fournir à l’installation de cert-manager un accès à votre infrastructure DNS au moyen d’un jeton d’API.

Contrôleurs d’entrée

Un contrôleur Ingress est un service spécialisé pour Kubernetes qui achemine le trafic provenant de l’extérieur du cluster, le répartit entre les pods internes (un groupe d’un ou plusieurs conteneurs) et gère le trafic sortant. De plus, le contrôleur Ingress est piloté via l’API Kubernetes et surveille et met à jour la configuration de l’équilibrage de charge à mesure que des pods sont ajoutés, supprimés ou tombent en panne.

Pour en savoir plus sur les contrôleurs Ingress, consultez les articles de blog suivants :

• Les bases de la mise en réseau Kubernetes
• Guide pour choisir un contrôleur Ingress, 4e partie : les différentes options de contrôleur Ingress NGINX

Dans les exemples ci-dessous, nous utiliserons NGINX Ingress Controller, développé et maintenu par F5 NGINX.

Exemples de gestion des certificats

Ces exemples supposent que vous disposez d’une installation Kubernetes opérationnelle sur laquelle vous pouvez effectuer des tests et que celle-ci peut attribuer une adresse IP externe (objet LoadBalancer de Kubernetes). Ils supposent également que vous pouvez recevoir du trafic sur les ports 80 et 443 (si vous utilisez le challenge HTTP-01), ou uniquement sur le port 443 (si vous utilisez le challenge DNS-01). Ces exemples sont illustrés sous Mac OS X, mais peuvent également être utilisés sous Linux ou WSL.

Vous aurez également besoin d’un fournisseur DNS et d’un nom de domaine complet (FQDN) dont vous pouvez modifier l’enregistrement A. Si vous utilisez le challenge HTTP-01, il vous suffit de pouvoir ajouter un enregistrement A (ou de le faire ajouter pour vous). Si vous utilisez le challenge DNS-01, vous aurez besoin d’un accès à l’API d’un fournisseur DNS pris en charge ou d’un fournisseur de webhook pris en charge.

Déployer le contrôleur Ingress NGINX

Le moyen le plus simple consiste à effectuer le déploiement via Helm. Ce déploiement vous permet d’utiliser à la fois l’Ingress Kubernetes et la CRD VirtualServer de NGINX.

1. Ajoutez le dépôt NGINX.

$ helm repo add nginx-stable https://helm.nginx.com/stable  "nginx-stable" has been added to your repositories 

1. Mettez à jour le dépôt.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  Update Complete. ⎈Happy Helming!⎈ 

1. Déployez le contrôleur Ingress.

$ helm install nginx-kic nginx-stable/nginx-ingress \  --namespace nginx-ingress  --set controller.enableCustomResources=true \ 
  --create-namespace  --set controller.enableCertManager=true 
  NAME: nginx-kic
  LAST DEPLOYED: Thu Sep  1 15:58:15 2022
  NAMESPACE: nginx-ingress
  STATUS: deployed
  REVISION: 1
  TEST SUITE: None
  NOTES:
  The NGINX Ingress Controller has been installed. 

1. Vérifiez le déploiement et récupérez l’adresse IP de sortie du contrôleur Ingress. Notez que vous ne pouvez pas continuer sans une adresse IP valide.

$ kubectl get deployments --namespace nginx-ingress  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-kic-nginx-ingress   1/1     1            1           23s
  $ kubectl get services --namespace nginx-ingress
  NAME                      TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
  nginx-kic-nginx-ingress   LoadBalancer   10.128.60.190   www.xxx.yyy.zzz   80:31526/TCP,443:32058/TCP   30s 

Ajoutez votre enregistrement DNS de type A

La procédure dépendra ici de votre fournisseur DNS. Ce nom DNS devra pouvoir être résolu depuis les serveurs de Let’s Encrypt. Vous devrez donc peut-être attendre la propagation de l’enregistrement avant qu’il ne fonctionne. Pour en savoir plus, consultez l’article de SiteGround intitulé « Qu’est-ce que la propagation DNS et pourquoi prend-elle autant de temps ? »

Une fois que le nom de domaine complet (FQDN) choisi peut être résolu, vous pouvez passer à l’étape suivante.

$ host cert.example.com  cert.example.com has address www.xxx.yyy.zzz

Déployer cert-manager

L’étape suivante consiste à déployer la version la plus récente de cert-manager. Là encore, nous utiliserons Helm pour effectuer le déploiement.

1. Ajoutez le dépôt Helm.

$ helm repo add jetstack https://charts.jetstack.io  "jetstack" has been added to your repositories 

1. Mettez à jour le dépôt.

$ helm repo update  Hang tight while we grab the latest from your chart repositories...
  ...Successfully got an update from the "nginx-stable" chart repository
  ...Successfully got an update from the "jetstack" chart repository
  Update Complete. ⎈Happy Helming!⎈ 

1. Déployez cert-manager.

$ helm install cert-manager jetstack/cert-manager \  --namespace cert-manager --create-namespace \
  --version v1.9.1  --set installCRDs=true 
  NAME: cert-manager
  LAST DEPLOYED: Thu Sep  1 16:01:52 2022 
  NAMESPACE: cert-manager
  STATUS: deployed
  REVISION: 1 
  TEST SUITE: None
  NOTES:
  cert-manager v1.9.1 has been deployed successfully!
  In order to begin issuing certificates, you will need to set up a ClusterIssuer
  or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
  More information on the different types of issuers and how to configure them
  can be found in our documentation:
  https://cert-manager.io/docs/configuration/ For information on how to configure cert-manager to automatically provision
  Certificates for Ingress resources, take a look at the `ingress-shim`
  documentation:
  https://cert-manager.io/docs/usage/ingress/

1. Validez le déploiement.

$ kubectl get deployments --namespace cert-manager  NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
  cert-manager              1/1     1            1           4m30s
  cert-manager-cainjector   1/1     1            1           4m30s
  cert-manager-webhook      1/1     1            1           4m30s 

Déployer l’exemple NGINX Cafe

Nous allons utiliser l’exemple NGINX Cafe pour fournir notre déploiement backend et nos Services. Il s’agit d’un exemple courant dans la documentation fournie par NGINX. Nous ne déploierons pas d’Ingress dans ce cadre.

1. Clonez le projet GitHub NGINX Ingress.

$ git clone https://github.com/nginxinc/kubernetes-ingress.git  Cloning into 'kubernetes-ingress'...
  remote: Enumerating objects: 44979, done.
  remote: Counting objects: 100% (172/172), done.
  remote: Compressing objects: 100% (108/108), done.
  remote: Total 44979 (delta 87), reused 120 (delta 63), pack-reused 44807
  Receiving objects: 100% (44979/44979), 60.27 MiB | 27.33 MiB/s, done.
  Resolving deltas: 100% (26508/26508), done. 

1. Accédez au répertoire examples. Ce répertoire contient plusieurs exemples illustrant différentes configurations du contrôleur Ingress. Nous utilisons l’exemple fourni dans le répertoire complete-example.

$ cd ./kubernetes-ingress/examples/ingress-resources/complete-example 

1. Déployez l’exemple NGINX Cafe.

$ kubectl apply -f ./cafe.yaml
  deployment.apps/coffee created
  service/coffee-svc created
  deployment.apps/tea created
  service/tea-svc created

1. Validez le déploiement et les services à l’aide de la commande kubectl get. Vérifiez que les pods sont indiqués comme étant READY et que les services sont indiqués comme étant running. L’exemple ci-dessous présente un aperçu représentatif du résultat attendu. Notez que le service kubernetes est un service système qui s’exécute dans le même espace de noms (default) que l’exemple NGINX Cafe.

$ kubectl get deployments,services  --namespace default  NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
  deployment.apps/coffee   2/2     2            2           69s
  deployment.apps/tea      3/3     3            3           68s
NAME                 TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
  service/coffee-svc   ClusterIP   10.128.154.225   <none>        80/TCP    68s
  service/kubernetes   ClusterIP   10.128.0.1       <none>        443/TCP   29m
	service/tea-svc      ClusterIP   10.128.96.145    <none>        80/TCP    68s 

Déployer le ClusterIssuer

Dans cert-manager, le ClusterIssuer peut être utilisé pour émettre des certificats. Il s’agit d’un objet à l’échelle du cluster qui peut être référencé par n’importe quel espace de noms et utilisé par toute demande de certificat auprès de l’autorité de certification définie. Dans cet exemple, toutes les demandes de certificats Let’s Encrypt peuvent être traitées par ce ClusterIssuer.

Déployez le ClusterIssuer correspondant au type de challenge que vous avez sélectionné. Bien que cela dépasse le cadre de cet article, il existe des options de configuration avancées qui vous permettent de spécifier plusieurs solveurs (sélectionnés en fonction des champs de sélecteur) dans votre ClusterIssuer.

Principes de base des challenges ACME

Le protocole Automated Certificate Management Environment (ACME) permet de vérifier que vous êtes propriétaire d’un nom de domaine et qu’un certificat Let’s Encrypt peut donc vous être délivré. Pour ce challenge, les paramètres suivants doivent être transmis :

• metadata.name: nom du ClusterIssuer, qui doit être unique au sein de l’installation Kubernetes. Ce nom sera utilisé plus loin dans l’exemple lors de l’émission d’un certificat.
• spec.acme.email: Il s’agit de l’adresse e-mail que vous enregistrez auprès de Let’s Encrypt afin de générer des certificats. Cette adresse doit être la vôtre.
• spec.acme.privateKeySecretRef: Il s’agit du nom du secret Kubernetes que vous utiliserez pour stocker votre clé privée.
• spec.acme.solvers: Cette valeur doit être laissée telle quelle. Elle indique le type de challenge (ou « solveur », selon la terminologie d’ACME) que vous utilisez (HTTP-01 ou DNS-01), ainsi que la classe Ingress à laquelle il doit être appliqué, en l’occurrence nginx.

Utilisation de HTTP-01

Cet exemple montre comment configurer un ClusterIssuer afin d’utiliser le challenge HTTP-01 pour prouver la propriété du domaine et obtenir un certificat.

1. Créez le ClusterIssuer en utilisant HTTP-01 pour les challenges.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
      - http01:
         ingress:
           class: nginx
  EOF
  clusterissuer.cert-manager.io/prod-issuer created 

1. Validez le ClusterIssuer (il devrait être indiqué comme prêt).

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    34s 

Utilisation de DNS-01

Cet exemple montre comment configurer un ClusterIssuer afin d’utiliser le challenge DNS-01 pour confirmer que vous êtes propriétaire de votre domaine. Selon votre fournisseur DNS, vous devrez probablement utiliser un Secret Kubernetes pour stocker votre jeton. Cet exemple utilise Cloudflare. Notez l’utilisation de l’espace de noms. L’application cert-manager, qui est déployée dans l’espace de noms cert-manager, doit avoir accès au Secret.

Pour cet exemple, vous aurez besoin d’un jeton d’API Cloudflare, que vous pouvez créer depuis votre compte. Vous devrez le renseigner à la ligne <API Token> ci-dessous. Si vous n’utilisez pas Cloudflare, vous devrez suivre la documentation de votre fournisseur.

1. Créez un Secret pour le jeton d’API.

$ cat << EOF | kubectl apply -f   apiVersion: v1
  kind: Secret
  metadata:
    name: cloudflare-api-token-secret
    namespace: cert-manager
  type: Opaque
  stringData:
    api-token: <API Token> 
  EOF 

1. Créez l’émetteur en utilisant DNS-01 pour les challenges.

$ cat << EOF | kubectl apply -f   apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: prod-issuer
  spec:
    acme:
      email: example@example.com
      server: https://acme-v02.api.letsencrypt.org/directory
      privateKeySecretRef:
        name: prod-issuer-account-key
      solvers:
        - dns01:
            cloudflare:
              apiTokenSecretRef:
                name: cloudflare-api-token-secret
                key: api-token
  EOF 

1. Validez l’émetteur (il devrait apparaître comme prêt).

$ kubectl get clusterissuer  NAME          READY   AGE
	prod-issuer   True    31m 

Déployer l’Ingress

Nous arrivons à l’étape vers laquelle tous nos efforts ont convergé : le déploiement de la ressource Ingress pour notre application. Celle-ci acheminera le trafic vers l’application NGINX Cafe que nous avons déployée précédemment.

Utilisation de l’Ingress Kubernetes

Si vous utilisez la ressource Ingress standard de Kubernetes, utilisez le fichier YAML de déploiement suivant pour configurer l’Ingress et demander un certificat.

apiVersion: networking.k8s.io/v1   kind: Ingress 
  metadata: 
    name: cafe-ingress 
    annotations: 
      cert-manager.io/cluster-issuer: prod-issuer 
      acme.cert-manager.io/http01-edit-in-place: "true" 
  spec: 
    ingressClassName: nginx 
    tls: 
    - hosts: 
      - cert.example.com 
      secretName: cafe-secret 
    rules: 
    - host: cert.example.com 
      http: 
        paths: 
        - path: /tea 
          pathType: Prefix 
          backend: 
            service: 
              name: tea-svc 
              port: 
                number: 80 
        - path: /coffee 
          pathType: Prefix 
          backend: 
            service: 
              name: coffee-svc 
              port: 
number: 80 

Il est utile d’examiner certains éléments clés du manifeste :

• L’API appelée est l’API Ingress standard de Kubernetes.
• Un élément clé de cette configuration se trouve sous metadata.annotations, où nous définissons acme.cert-manager.io/http01-edit-in-place sur « true ». Cette valeur est obligatoire et modifie la manière dont le challenge est présenté. Pour plus d’informations, consultez le document sur les annotations prises en charge. Cela peut également être géré à l’aide d’une configuration maître/minion.
• Le champ « spec.ingressClassName » fait référence au contrôleur Ingress NGINX que nous avons installé et que nous utiliserons.
• La ressource Kubernetes Secret spec.tls.secret stocke la clé du certificat renvoyée lorsque le certificat est émis par Let’s Encrypt.
• Notre nom d’hôte cert.example.com est indiqué dans spec.tls.hosts et spec.rules.host. Il s’agit du nom d’hôte pour lequel notre ClusterIssuer a émis le certificat.
• La section spec.rules.http définit les chemins et les services backend qui traiteront les requêtes adressées à ces chemins. Par exemple, le trafic vers /tea sera redirigé vers le port 80 du service tea-svc.

1. Modifiez le manifeste ci-dessus en fonction de votre installation. Vous devrez au minimum modifier les valeurs spec.rules.host et spec.tls.hosts, mais vous devez vérifier tous les paramètres de la configuration.
2. Appliquez le manifeste.

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created 

1. Attendez que le certificat soit émis. La valeur du champ READY doit être « True ».

$ kubectl get certificates  NAME                                      READY   SECRET        AGE
  certificate.cert-manager.io/cafe-secret   True    cafe-secret   37m 

Utilisation du serveur virtuel NGINX et des routes virtuelles

Si vous utilisez les CRD NGINX, vous devrez utiliser le fichier YAML de déploiement suivant pour configurer votre Ingress.

  apiVersion: k8s.nginx.org/v1 
  kind: VirtualServer 
  metadata: 
    name: cafe 
  spec: 
    host: cert.example.com 
    tls: 
      secret: cafe-secret 
      cert-manager: 
        cluster-issuer: prod-issuer 
    upstreams: 
      - name: tea 
        service: tea-svc 
        port: 80 
      - name: coffee 
        service: coffee-svc 
        port: 80 
    routes: 
      - path: /tea 
        action: 
          pass: tea 
      - path: /coffee 
        action: 
          pass: coffee

Là encore, il convient de passer en revue certains éléments clés du manifeste :

• L’API appelée est l’API k8s.nginx.org/v1 propre à NGINX pour la ressource VirtualServer.
• La ressource Secret Kubernetes spec.tls.secret stocke la clé du certificat qui est renvoyée lorsque le certificat est émis par Let’s Encrypt.
• Notre nom d’hôte cert.example.com est indiqué dans spec.host. Il s’agit du nom d’hôte pour lequel notre ClusterIssuer a émis le certificat.
• Les valeurs spec.upstreams pointent vers nos services backend, y compris les ports.
• Le champ « spec.routes » définit à la fois la route et l’action à effectuer lorsque ces routes sont sollicitées.

1. Modifiez le manifeste ci-dessus en fonction de votre installation. Vous devrez au minimum modifier la valeur de spec.host, mais il est recommandé de vérifier tous les paramètres de la configuration.
2. Appliquez le manifeste.

$  kubectl apply -f ./cafe-virtual-server.yaml  virtualserver.k8s.nginx.org/cafe created

1. Attendez que le certificat soit émis. Le statut « Valid » devrait s’afficher.

$ kubectl get VirtualServers  NAME   STATE   HOST                    IP             PORTS      AGE
  cafe   Valid   cert.example.com   www.xxx.yyy.zzz   [80,443]   51m 

Afficher le certificat

Vous pouvez consulter le certificat via l’API Kubernetes. Vous pourrez ainsi afficher les informations relatives au certificat, notamment sa taille et la clé privée associée.

$ kubectl describe secret cafe-secret  Name:         cafe-secret
  Namespace:    default
  Labels:       <none>
  Annotations:  cert-manager.io/alt-names: cert.example.com
                cert-manager.io/certificate-name: cafe-secret
                cert-manager.io/common-name: cert.example.com
                cert-manager.io/ip-sans:
                cert-manager.io/issuer-group:
                cert-manager.io/issuer-kind: ClusterIssuer
                cert-manager.io/issuer-name: prod-issuer
                cert-manager.io/uri-sans:Type:  kubernetes.io/tlsData
  ====
  tls.crt:  5607 bytes
  tls.key:  1675 bytes 

Si vous souhaitez afficher le certificat et la clé proprement dits, exécutez la commande suivante. (Remarque : cela met en évidence une faiblesse des Secrets Kubernetes : toute personne disposant des autorisations d’accès nécessaires peut les lire.)

$ kubectl get secret cafe-secret -o yaml

Tester l’Ingress

Testez les certificats. Vous pouvez utiliser ici la méthode de votre choix. L’exemple ci-dessous utilise cURL. En cas de réussite, un bloc semblable à celui présenté précédemment s’affiche. Il contient le nom du serveur, son adresse interne, la date, l’URI (route) choisie (coffee ou tea) et l’identifiant de la requête. En cas d’échec, des codes d’erreur HTTP s’affichent, le plus souvent 400 ou 301.

$ curl https://cert.example.com/tea
  Server address: 10.2.0.6:8080
  Server name: tea-5c457db9-l4pvq
  Date: 02/Sep/2022:15:21:06 +0000
  URI: /tea
  Request ID: d736db9f696423c6212ffc70cd7ebecf
  $ curl https://cert.example.com/coffee
  Server address: 10.2.2.6:8080
  Server name: coffee-7c86d7d67c-kjddk
  Date: 02/Sep/2022:15:21:10 +0000
  URI: /coffee
Request ID: 4ea3aa1c87d2f1d80a706dde91f31d54 

Renouvellement des certificats

Au début, nous avions promis que cette approche éviterait d’avoir à gérer le renouvellement des certificats. Cependant, nous n’avons pas encore expliqué comment cela fonctionne. Pourquoi ? Parce qu’il s’agit d’une fonctionnalité essentielle intégrée à cert-manager. Dans le cadre de ce processus automatique, lorsque cert-manager constate qu’un certificat est absent, a expiré, arrive à expiration dans les 15 jours ou que l’utilisateur demande un nouveau certificat via la CLI, un nouveau certificat est automatiquement demandé. Difficile de faire plus simple.

Questions fréquentes

Qu’en est-il de NGINX Plus ?

Si vous êtes abonné à NGINX Plus, la seule différence pour vous concernera l’installation du contrôleur Ingress NGINX. Consultez la section « Installation avec Helm » de la documentation NGINX pour savoir comment modifier la commande Helm indiquée ci-dessus à cette fin.

Quel type de challenge dois-je utiliser ?

Cela dépend en grande partie de votre cas d’usage.

La méthode de validation HTTP-01 nécessite que le port 80 soit ouvert sur Internet et que l’enregistrement DNS A soit correctement configuré pour l’adresse IP du contrôleur Ingress. Cette approche ne nécessite aucun accès au fournisseur DNS, hormis pour créer l’enregistrement A.

La méthode de validation DNS-01 peut être utilisée lorsque vous ne pouvez pas exposer le port 80 sur Internet. Elle nécessite uniquement que cert-manager dispose d’un accès sortant au fournisseur DNS. Toutefois, cette méthode exige que vous ayez accès à l’API de votre fournisseur DNS, bien que le niveau d’accès requis varie selon le fournisseur.

Comment résoudre les problèmes ?

Kubernetes étant très complexe, il est difficile de fournir des informations de dépannage ciblées. Si vous rencontrez des problèmes, nous vous invitons à nous poser vos questions sur le Slack de la communauté NGINX (les abonnés à NGINX Plus peuvent utiliser leurs options d’assistance habituelles).

Commencez dès aujourd’hui

Commencez par demander votre essai gratuit de 30 jours de NGINX Ingress Controller avec NGINX App Protect WAF et DoS, puis téléchargez NGINX Service Mesh, toujours gratuit.

À propos de l’auteur

Jason Schmidt

Autres articles de Jason Schmidt