Exemple avec Anthos Service Mesh : mTLS

---

Dans les versions 1.5 et ultérieures d'Anthos Service Mesh, l'authentification TLS mutuelle (mTLS) automatique est activée par défaut. L'authentification mTLS permet à un proxy side-car client de détecter automatiquement si le serveur possède un side-car. Le side-car client envoie l'authentification mTLS aux charges de travail avec des side-cars, et envoie du texte brut aux charges de travail sans side-car. Notez toutefois que les services acceptent à la fois le trafic en texte brut et le trafic mTLS. Lorsque vous injectez des proxys side-car dans vos pods, nous vous recommandons également de configurer vos services de manière à n'accepter que le trafic mTLS.

Avec Anthos Service Mesh, vous pouvez appliquer l'authentification mTLS en dehors du code de votre application en définissant un seul fichier YAML. Anthos Service Mesh vous donne la possibilité d'appliquer une règle d'authentification à l'ensemble du maillage de services, à un espace de noms ou à une charge de travail individuelle.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• GKE
• Anthos Service Mesh

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous aurez terminé ce tutoriel, évitez de payer des frais en supprimant les ressources que vous avez créées. Consultez la section Effectuer un nettoyage pour en savoir plus.

Avant de commencer

Ce tutoriel utilise l'exemple d'application Boutique en ligne pour démontrer la configuration de l'authentification mTLS sur un cluster GKE avec Anthos Service Mesh installé.

• Si vous devez configurer un cluster GKE pour ce tutoriel, consultez le guide de démarrage rapide d'Anthos Service Mesh, qui vous explique comment configurer un cluster, installer Anthos Service Mesh et déployer le Exemple de boutique en ligne à l'espace de noms demo.

• Si vous disposez d'un cluster GKE avec Anthos Service Mesh installé, mais que vous avez besoin de l'exemple, consultez la pageBoutique en ligne, qui vous guide tout au long du déploiement de l'exemple sur l'espace de noms demo.

Accéder à l'exemple boutique en ligne

1. Définissez le contexte actuel de kubectl sur le cluster sur lequel vous avez déployé la boutique en ligne :

   gcloud container clusters get-credentials CLUSTER_NAME  \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION
   

2. Obtenez la liste des services de boutique en ligne :

   kubectl get services -n demo
   

   Notez que frontend-external est LoadBalancer et qu'il possède une adresse IP externe. L'exemple d'application inclut un service qui est un équilibreur de charge, de sorte qu'il puisse être déployé sur GKE sans Anthos Service Mesh.

3. Accédez à l'application dans votre navigateur à l'aide de l'adresse IP externe du service frontend-external :

   http://FRONTEND_EXTERNAL_IP/
   

4. Anthos Service Mesh fournit une passerelle d'entrée par défaut appelée istio-ingressgateway. Vous pouvez également accéder à la boutique en ligne à l'aide de l'adresse IP externe de istio-ingressgateway. Obtenez l'adresse IP externe de istio-ingressgateway :

   kubectl get service istio-ingressgateway -n istio-system
   

5. Ouvrez un autre onglet dans votre navigateur et accédez à l'application en utilisant l'adresse IP externe de istio-ingressgateway :

   http://INGRESS_GATEWAY_EXTERNAL_IP/
   

6. Exécutez la commande suivante pour curl sur le service frontend en HTTP simple depuis un autre pod de l'espace de noms demo.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Votre requête aboutit avec l'état 200, car par défaut, le trafic TLS et le trafic en texte brut sont acceptés.

Activer l'authentification TLS mutuelle par espace de noms

Pour appliquer l'authentification mTLS, vous devez appliquer une règle PeerAuthentication avec kubectl.

1. Appliquez la règle d'authentification suivante pour configurer tous les services de l'espace de noms demo pour n'accepter que l'authentification mTLS :

   kubectl apply -f - <<EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "namespace-policy"
     namespace: "demo"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   Résultat attendu :

   peerauthentication.security.istio.io/namespace-policy created

   La ligne mode: STRICT du fichier YAML configure les services de manière à n'accepter que l'authentification mTLS. Par défaut, mode est défini sur PERMISSIVE, qui configure les services de sorte qu'ils acceptent à la fois le texte brut et l'authentification mTLS.

2. Accédez à l'onglet de votre navigateur qui accède à la boutique en ligne en utilisant l'adresse IP externe du service frontend-external, puis actualisez la page. Le navigateur affiche l'erreur suivante :

   

   L'actualisation de la page entraîne l'envoi de texte brut au service frontend. En raison de la règle d'authentification STRICT, le proxy side-car bloque la requête auprès du service.

3. Accédez à l'onglet de votre navigateur qui accède à la boutique en ligne en utilisant l'adresse IP externe de istio-ingressgateway, puis actualisez la page, qui s'affiche correctement. Lorsque vous accédez à la boutique en ligne à l'aide de istio-ingressgateway, la requête suit le chemin suivant :

   

   Flux d'authentification mTLS :

   1. Le navigateur envoie une requête HTTP en texte brut au serveur.
   2. Le conteneur de proxy istio-ingressgateway intercepte la requête.
   3. Le proxy istio-ingressgateway effectue un handshake TLS avec le proxy côté serveur (le service d'interface dans cet exemple). Ce handshake comprend un échange de certificats. Ces certificats sont pré-chargés dans les conteneurs du proxy par Anthos Service Mesh.
   4. Le proxy istio-ingressgateway effectue une vérification de la dénomination sécurisée du certificat du serveur, confirmant ainsi qu'une identité autorisée exécute le serveur.
   5. Les proxys istio-ingressgateway et serveurs proxy établissent une connexion TLS mutuelle, et le serveur proxy transfère la requête au conteneur d'applications de serveur (le service de frontend).

4. Exécutez la commande suivante pour curl sur le service frontend en HTTP simple depuis un autre pod de l'espace de noms demo.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Votre requête échoue, car tous les services de l'espace de noms demo sont définis sur STRICT mTLS, et le proxy side-car bloque la requête auprès du service.

   Résultat attendu :

   000
   command terminated with exit code 56

Afficher l'état de l'authentification mTLS

Vous pouvez afficher l'état des fonctionnalités de sécurité Anthos, y compris les règles d'authentification, dans Google Cloud Console.

1. Dans la console Google Cloud, accédez à la page Sécurité de GKE Enterprise.

   Accéder à la sécurité de GKE Enterprise

2. Sélectionnez le projet Google Cloud dans la liste déroulante de la barre de menu.

   Le récapitulatif des règles affiche l'état de la sécurité des applications, y compris l'authentification mTLS.

3. Cliquez sur Audit des règles pour afficher l'état de conformité avec les règles de la charge de travail pour chaque cluster et espace de noms. La fiche État mTLS fournit un aperçu. La liste Charges de travail indique l'état mTLS de chaque charge de travail.

   

Rechercher et supprimer des règles d'authentification

1. Pour obtenir la liste de toutes les règles PeerAuthentication du maillage de services, procédez comme suit :

   kubectl get peerauthentication --all-namespaces
   

2. Supprimez la règle d'authentification :

   kubectl delete peerauthentication -n demo namespace-policy
   

   Résultat attendu :

   peerauthentication.security.istio.io "namespace-policy" deleted

3. Accédez à la boutique en ligne à l'aide de l'adresse IP externe du service frontend-external, puis actualisez la page. La page s'affiche comme prévu.

4. Exécutez la commande suivante pour curl sur le service frontend en HTTP simple depuis un autre pod de l'espace de noms demo.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Votre requête aboutit avec l'état 200, car par défaut, le trafic TLS et le trafic en texte brut sont acceptés.

Si vous actualisez la page dans la console Google Cloud qui affiche la liste Charges de travail, l'état mTLS indiqué est maintenant Permissive.

Activer l'authentification TLS mutuelle par charge de travail

Pour définir une règle PeerAuthentication pour une charge de travail spécifique, vous devez configurer la section selector et spécifier les libellés correspondant à la charge de travail souhaitée. Toutefois, Anthos Service Mesh ne peut pas agréger les règles à l'échelle d'une charge de travail pour le trafic mTLS sortant vers un service. Vous devez configurer une règle de destination pour gérer ce comportement.

1. Appliquez une règle d'authentification à une charge de travail spécifique de l'espace de noms demo : Notez que la règle suivante utilise des étiquettes et des sélecteurs pour cibler le déploiement frontend spécifique.

   cat <<EOF | kubectl apply -n demo -f -
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "frontend"
     namespace: "demo"
   spec:
     selector:
       matchLabels:
         app: frontend
     mtls:
       mode: STRICT
   EOF
   

   Résultat attendu :

   peerauthentication.security.istio.io/frontend created

2. Configurez une règle de destination correspondante :

   cat <<EOF | kubectl apply -n demo -f -
   apiVersion: "networking.istio.io/v1alpha3"
   kind: "DestinationRule"
   metadata:
     name: "frontend"
   spec:
     host: "frontend.demo.svc.cluster.local"
     trafficPolicy:
       tls:
         mode: ISTIO_MUTUAL
   EOF
   

   Résultat attendu :

   destinationrule.networking.istio.io/frontend created

3. Accédez à la boutique en ligne à l'aide de l'adresse IP externe du service frontend-external, puis actualisez la page. La page ne s'affiche pas, car frontend service est défini sur STRICT mTLS et le proxy side-car bloque la requête.

4. Exécutez la commande suivante pour curl sur le service frontend en HTTP simple depuis un autre pod de l'espace de noms demo.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Votre requête échoue avec le code d'état 56.

   Si vous actualisez la page dans la console Google Cloud qui affiche la liste Charges de travail, elle indique maintenant que l'état mTLS du service frontend est Strict et tous les autres services sont définis sur Permissive.

   

5. Supprimez la règle d'authentification et la règle de destination :

   kubectl delete peerauthentication -n demo frontend
   kubectl delete destinationrule -n demo frontend
   

Appliquer l'authentification mTLS à l'échelle du maillage

Pour empêcher tous vos services du maillage d'accepter le trafic en texte brut, définissez une règle PeerAuthentication à l'échelle du maillage avec le mode mTLS défini sur STRICT. La règle PeerAuthentication à l'échelle du maillage ne doit pas comporter de sélecteur et doit être appliquée dans l'espace de noms racine istio-system. Lorsque vous déployez la règle, le plan de contrôle provisionne automatiquement les certificats TLS afin que les charges de travail puissent s'authentifier mutuellement.

1. Appliquez l'authentification mTLS à l'échelle du maillage :

   kubectl apply -f - <<EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "PeerAuthentication"
   metadata:
     name: "mesh-wide"
     namespace: "istio-system"
   spec:
     mtls:
       mode: STRICT
   EOF
   

   Résultat attendu :

   peerauthentication.security.istio.io/mesh-wide created

2. Accédez à la boutique en ligne à l'aide de l'adresse IP externe du service frontend-external, puis actualisez la page. La page ne s'affiche pas.

3. Exécutez la commande suivante pour curl sur le service frontend en HTTP simple depuis un autre pod de l'espace de noms demo.

   kubectl exec \
     $(kubectl get pod -l app=productcatalogservice -n demo -o jsonpath={.items..metadata.name}) \
     -c istio-proxy -n demo -- \
     curl http://frontend:80/ -o /dev/null -s -w '%{http_code}\n'
   

   Votre requête échoue avec le code d'état 56.

4. Supprimez la stratégie mesh-wide :

   kubectl delete peerauthentication -n istio-system mesh-wide
   

Si vous actualisez la page dans la console Google Cloud, vous constatez que les détails mTLS de tous les services affichent désormais Permissive.

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et les ressources individuelles.

• Si vous souhaitez éviter des frais supplémentaires, supprimez le cluster :

  gcloud container clusters delete  CLUSTER_NAME  \
      --project=PROJECT_ID \
      --zone=CLUSTER_LOCATION
  

• Si vous souhaitez conserver votre cluster et supprimer l'exemple de boutique en ligne, procédez comme suit :

  kubectl delete namespaces demo
  

Étapes suivantes

• Pour obtenir un guide général sur la configuration des règles PeerAuthentication, consultez la page Configurer la sécurité du transport.