Alibaba Cloud Service Mesh:Délivrer des certificats pour une passerelle ASM avec ACME

Prérequis

• Un cluster Container Service for Kubernetes (ACK) ajouté à une instance ASM version 1.16 ou ultérieure. Pour plus d'informations, consultez les rubriques Ajouter un cluster à une instance ASM et Mettre à niveau une instance ASM.

• Une passerelle d'entrée déployée avec les ports 80 et 443 exposés. Pour plus d'informations, consultez la rubrique Créer une passerelle d'entrée.

• L'application httpbin déployée dans le cluster associé à l'instance ASM. Pour plus d'informations, consultez la rubrique Déployer l'application httpbin.

• cert-manager installé. Pour plus d'informations, consultez la rubrique Installer cert-manager dans un cluster.

• La prise en charge de l'API Ingress activée sur la passerelle ASM. Pour plus d'informations, consultez l'étape Étape 1 : Activer l'accès à l'API Ingress.

Fonctionnement d'ACME dans cert-manager

Lorsque vous utilisez cert-manager, le composant ACME Issuer enregistre des comptes utilisateur auprès des serveurs d'autorité de certification (CA) compatibles avec le protocole ACME. Lors de la création d'un ACME Issuer, cert-manager génère une clé privée permettant une communication sécurisée avec le serveur CA ACME. Les certificats émis par des autorités publiques telles que Let's Encrypt sont généralement reconnus par la majorité des navigateurs web, ce qui permet aux utilisateurs d'accéder à votre site sans avertissements de sécurité. Le rôle principal d'une autorité de certification publique consiste à prouver au navigateur que le serveur est bien le propriétaire légitime du domaine. Pour ce faire, l'autorité doit vérifier que le demandeur contrôle le domaine avant de délivrer le certificat. Pour plus de détails sur le protocole ACME, consultez la RFC Automatic Certificate Management Environment.

Défis (Challenges)

Un défi constitue un mécanisme clé du protocole ACME utilisé pour vérifier la propriété d'un domaine par le demandeur de certificat. Au cours du processus de demande, le serveur CA ACME impose au client (le demandeur) de relever un défi spécifique. Cette procédure garantit que seul le propriétaire légitime du domaine peut obtenir un certificat, renforçant ainsi la sécurité et empêchant l'usurpation de domaine. cert-manager prend en charge deux types principaux de défis : le défi HTTP-01 et le défi DNS-01.

• Le défi HTTP-01 exige que le serveur expose une clé de validation via une URL HTTP spécifique accessible publiquement. Cette URL utilise le domaine pour lequel le certificat est demandé. Lorsque le serveur CA ACME récupère cette clé avec succès, il considère que le demandeur contrôle le domaine. Pour simplifier cette opération, cert-manager modifie automatiquement la ressource Ingress du cluster lorsqu'un défi HTTP-01 est configuré. Il redirige les requêtes vers l'URL de validation vers un service web temporaire contenant la clé requise et répondant au défi du serveur ACME.

• Le défi DNS-01 fonctionne en publiant une clé spécifique sous forme d'enregistrement TXT dans le système DNS. Après la propagation de cet enregistrement TXT, le serveur CA ACME peut récupérer la clé via une requête DNS standard afin de confirmer la propriété du domaine. Avec les autorisations appropriées, cert-manager crée et soumet automatiquement l'enregistrement TXT requis auprès de votre fournisseur DNS pour satisfaire au défi DNS-01.

Étape 1 : Préparer un domaine public

Pour utiliser Let's Encrypt afin de délivrer un certificat, vous devez disposer d'un domaine public. Vous devez également pointer ce domaine vers la passerelle d'entrée ASM que vous comptez utiliser. Reportez-vous à la documentation de votre fournisseur DNS pour les instructions spécifiques. Si vous utilisez Alibaba Cloud DNS, consultez la rubrique Ajouter un enregistrement DNS. Pour plus d'informations sur Let's Encrypt, consultez le guide Getting Started.

Étape 2 : Créer un émetteur (Issuer) pour Let's Encrypt

1. Utilisez le fichier KubeConfig de votre cluster de plan de données pour créer la ressource suivante.

   apiVersion: cert-manager.io/v1
   kind: Issuer
   metadata:
     name: letsencrypt-prod-issuer
     namespace: istio-system
   spec:
     acme:
       email: 'your-email@example.com'    # This field is optional but recommended. The ACME server may use this email to send you important notices about your certificate.
       privateKeySecretRef:
         name: letsencrypt-prod
       server: https://acme-v02.api.letsencrypt.org/directory
       solvers:
       - http01:
           ingress:
             ingressClassName: istio

   La ressource Issuer ci-dessus spécifie un solveur http01, qui utilise l'API Ingress avec un paramètre ingressClassName défini sur istio.

   Remarque

   cert-manager prend en charge des solveurs pour l'API Ingress et l'API Gateway. ASM prend également en charge ces deux API. Cet exemple utilise l'API Ingress.

2. Attendez que l'émetteur (Issuer) soit prêt. Exécutez la commande suivante pour vérifier son état.

   kubectl -n istio-system get issuer letsencrypt-prod-issuer

   Résultat attendu :

   NAME                      READY   AGE
   letsencrypt-prod-issuer   True    8m3s

Étape 3 : Délivrer un certificat pour la passerelle ASM

1. Utilisez le fichier KubeConfig de votre cluster de plan de données pour créer la ressource suivante.

   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: istio-ingressgateway-certs
     namespace: istio-system
   spec:
     dnsNames:
     - ${YOUR_DOMAIN}    # test.com
     issuerRef:
       group: cert-manager.io
       kind: Issuer
       name: letsencrypt-prod-issuer
     secretName: istio-ingressgateway-certs

2. Attendez que le certificat soit prêt. Exécutez la commande suivante pour vérifier son état.

   kubectl -n istio-system get certificate istio-ingressgateway-certs

   Résultat attendu :

   NAME                         READY   SECRET                       AGE
   istio-ingressgateway-certs   True    istio-ingressgateway-certs   59m

Fonctionnement de la délivrance des certificats

Après la création de la ressource Certificate, cert-manager utilise l'émetteur (Issuer) spécifié pour délivrer un certificat pour le domaine. Durant ce processus, le solveur configuré devient actif.

Let's Encrypt utilise un défi HTTP-01 pour confirmer que le serveur possède le domaine. Il envoie une requête HTTP au domaine et doit recevoir une réponse valide pour achever la vérification. Dans cet exemple, la passerelle d'entrée ne dispose que de règles de routage pour l'application httpbin, sans configuration explicite pour le défi. Let's Encrypt a-t-il réellement envoyé une requête de défi ? Et comment la passerelle y a-t-elle répondu ?

Exécutez la commande suivante pour consulter les journaux de la passerelle et déterminer si Let's Encrypt a envoyé une requête de défi.

kubectl -n istio-system logs ${GATEWAY_POD_NAME} | grep letsencrypt | tail -1

{
    "authority_for": "xxxxxxx",
    "bytes_received": "0",
    "bytes_sent": "87",
    "downstream_local_address": "xx.xx.xx.xx:80",
    "downstream_remote_address": "xx.xx.xx.xx:57101",
    "duration": "0",
    "istio_policy_status": "-",
    "method": "GET",
    "path": "/.well-known/acme-challenge/JfKvfdSNmkR7UqmCQU0OSkJC3EsnP4ZUiCc28OLLLxA",
    "protocol": "HTTP/1.1",
    "request_id": "e6806d08-0469-4383-be8e-4d7506b39ec5",
    "requested_server_name": "-",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "-",
    "start_time": "2024-04-08T12:04:06.153Z",
    "trace_id": "-",
    "upstream_cluster": "outbound|8089||cm-acme-http-solver-c4ch9.istio-system.svc.cluster.local",
    "upstream_host": "xx.xx.xx.xx:8089",
    "upstream_local_address": "xx.xx.xx.xx:55886",
    "upstream_response_time": "0",
    "upstream_service_time": "0",
    "upstream_transport_failure_reason": "-",
    "user_agent": "Mozilla/5.0 (compatible; Let's Encrypt validation server; +https://www.letsencrypt.org)",
    "x_forwarded_for": "xx.xx.xx.xx"
}

Les journaux indiquent que la passerelle a reçu et traité avec succès une requête provenant de Let's Encrypt. Étant donné que l'émetteur (Issuer) est configuré avec un paramètre ingressClassName défini sur istio, cert-manager crée automatiquement une ressource Ingress avec le même ingressClassName. Cette ressource transfère la requête de défi vers le solveur cert-manager correspondant, qui effectue la vérification.

Vous ne verrez pas cette ressource Ingress si vous exécutez kubectl -n istio-system get ingress une fois le certificat prêt. En effet, cert-manager nettoie automatiquement les ressources liées au solveur, telles que les ressources Ingress, Service et Deployment, dès que le certificat est délivré avec succès.

Étape 4 : Vérifier le certificat

1. Créez la règle de passerelle suivante pour appliquer le certificat généré à l'étape Étape 3 sur le port 443 de la passerelle. Pour plus d'informations, consultez la rubrique Gérer les règles de passerelle.

   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: httpbin-https
     namespace: default
   spec:
     selector:
       istio: ingressgateway
     servers:
     - hosts:
       - ${YOUR_DOMAIN}
       port:
         name: https
         number: 443
         protocol: HTTPS
       tls:
         credentialName: istio-ingressgateway-certs
         mode: SIMPLE

2. Mettez à jour le service virtuel httpbin-vs existant avec le contenu suivant. Pour plus d'informations, consultez la rubrique Gérer les services virtuels.

   apiVersion: networking.istio.io/v1beta1
   kind: VirtualService
   metadata:
     name: httpbin-vs
     namespace: default
   spec:
     gateways:
       - httpbin
       - httpbin-https  # Add this line.
     hosts:
       - '*'
     http:
       - name: test
         route:
           - destination:
               host: httpbin.default.svc.cluster.local
               port:
                 number: 8000

3. Accédez à https://${YOUR_DOMAIN} depuis votre navigateur web.

   La barre d'adresse du navigateur affiche une icône de cadenas. Cliquez sur l'icône (). Le message Connection is secure s'affiche. Cela indique que le navigateur fait confiance à votre certificat.