Exemple de Cloud Service Mesh: mTLS


Dans Cloud Service Mesh 1.5 et versions ultérieures, l'authentification TLS mutuelle (auto mTLS) 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 accepter le trafic en texte brut et mTLS. En injecter des proxys side-car à vos pods, recommandent également de configurer vos services pour n'accepter que le trafic mTLS.

Avec Cloud Service Mesh, vous pouvez appliquer l'authentification mTLS en dehors du code de votre application : en appliquant un seul fichier YAML. Cloud Service Mesh vous permet d'appliquer d'authentification à l'ensemble du maillage de services, à un espace de noms une charge de travail individuelle.

TLS mutuel

Coûts

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

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. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

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. Répertoriez les services dans l'espace de noms frontend :

    kubectl get services -n frontend
    

    Notez que frontend-external est LoadBalancer et qu'il possède une adresse IP externe. L'exemple d'application inclut un service d'un équilibreur de charge Google Cloud afin qu'il puisse être déployé sur GKE Cloud 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. Cloud Service Mesh vous permet de déployer une passerelle d'entrée. Vous pouvez également accéder à la boutique en ligne à l'aide de l'adresse IP externe du serveur de passerelle VPN haute disponibilité. Obtenez l'adresse IP externe de la passerelle. Remplacez les espaces réservés par les informations suivantes:

    • GATEWAY_SERVICE_NAME : nom du service de passerelle d'entrée. Si vous avez déployé l'exemple de passerelle sans modification ou si vous avez déployé la passerelle d'entrée par défaut, le nom est istio-ingressgateway.
    • GATEWAY_NAMESPACE : espace de noms dans lequel vous avez déployé la passerelle d'entrée. Si vous avez déployé la passerelle d'entrée par défaut, l'espace de noms est istio-system.
    kubectl get service GATEWAY_NAME -n GATEWAY_NAMESPACE
    
  5. Ouvrez un autre onglet dans votre navigateur et accédez à l'application en utilisant l'adresse IP externe de la passerelle d'entrée :

    http://INGRESS_GATEWAY_EXTERNAL_IP/
    
  6. Exécutez la commande suivante pour curl le service frontend avec le protocole HTTP brut d'un autre pod. Comme les services se trouvent dans des espaces de noms différents, vous devez boucler le nom DNS du service frontend.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local: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. Enregistrez la règle d'authentification suivante sous mtls-namespace.yaml.

    cat <<EOF > mtls-namespace.yaml
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "namespace-policy"
    spec:
      mtls:
        mode: STRICT
    EOF
    

    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. Appliquez la règle d'authentification pour configurer tous les services Boutique en ligne afin qu'ils n'acceptent que l'authentification mTLS :

    for ns in ad cart checkout currency email frontend loadgenerator \
         payment product-catalog recommendation shipping; do
    kubectl apply -n $ns -f mtls-namespace.yaml
    done
    

    Résultat attendu :

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

  3. Accédez à l'onglet de votre navigateur qui accède à Boutique en ligne à l'aide de l'adresse IP externe du service frontend-external :

    http://FRONTEND_EXTERNAL_IP/
    
  4. Actualisez la page. Le navigateur affiche l'erreur suivante :

    site inaccessible

    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.

  5. 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 la passerelle d'entrée, la requête prend le chemin suivant :

    TLS mutuel

    Flux d'authentification mTLS :

    1. Le navigateur envoie une requête HTTP en texte brut au serveur.
    2. Le conteneur du proxy de passerelle d'entrée intercepte la requête.
    3. Le proxy de passerelle d'entrée 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 les conteneurs proxy par Cloud Service Mesh.
    4. Le proxy de passerelle d'entrée 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 de passerelle d'entrée et serveurs établissent une connexion TLS mutuelle, et le serveur proxy transfère la requête au conteneur d'applications de serveur (le service de frontend).
  6. Exécutez la commande suivante pour curl le service frontend avec le protocole HTTP brut d'un autre pod.

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

    Votre requête échoue, car tous les services Boutique en ligne sont définis sur STRICT mTLS, et le proxy side-car bloque la requête au 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é de GKE Enterprise, y compris les règles d'authentification, dans la console Google Cloud.

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

    Accéder à la page "Présentation"

  2. Sélectionnez le projet Google Cloud dans la liste des projets de la barre de menu.

  3. Dans la fiche "État de la règle", cliquez sur Afficher la règle ou Activer la règle, en fonction de votre configuration. Le tableau de bord Policy Controller s'ouvre.

  4. Cliquez sur l'onglet Cas de non-respect des règles.

  5. Sous Resource Kind (Genre de ressource), cochez la case Pod. Cela affiche une liste de Pods qui ne respectent pas une règle.

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
    

    Le résultat ressemble à ce qui suit :

    NAMESPACE         NAME               MODE     AGE
    ad                namespace-policy   STRICT   17m
    cart              namespace-policy   STRICT   17m
    checkout          namespace-policy   STRICT   17m
    currency          namespace-policy   STRICT   17m
    email             namespace-policy   STRICT   17m
    frontend          namespace-policy   STRICT   17m
    loadgenerator     namespace-policy   STRICT   17m
    payment           namespace-policy   STRICT   17m
    product-catalog   namespace-policy   STRICT   17m
    recommendation    namespace-policy   STRICT   17m
    shipping          namespace-policy   STRICT   17m
    
  2. Supprimez la règle d'authentification de tous les espaces de noms de Boutique en ligne :

    for ns in ad cart checkout currency email frontend loadgenerator payment \
      product-catalog recommendation shipping; do
        kubectl delete peerauthentication -n $ns namespace-policy
    done;
    

    Résultat attendu :

    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    peerauthentication.security.istio.io "namespace-policy" deleted
    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 le service frontend avec le protocole HTTP brut d'un autre pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local: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, Cloud 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. 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 frontend -f -
    apiVersion: "security.istio.io/v1beta1"
    kind: "PeerAuthentication"
    metadata:
      name: "frontend"
      namespace: "frontend"
    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 frontend -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 le service frontend avec le protocole HTTP brut d'un autre pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local: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.

    seul le service frontend est mtls strict

  5. Supprimez la règle d'authentification :

    kubectl delete peerauthentication -n frontend frontend
    

    Résultat attendu :

    peerauthentication.security.istio.io "frontend" deleted
    
  6. Supprimez la règle de destination :

    kubectl delete destinationrule -n frontend frontend
    

    Résultat attendu :

    destinationrule.networking.istio.io "frontend" deleted
    

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 le service frontend avec le protocole HTTP brut d'un autre pod.

    kubectl exec \
      $(kubectl get pod -l app=productcatalogservice -n product-catalog -o jsonpath={.items..metadata.name}) \
      -c istio-proxy -n product-catalog -- \
      curl http://frontend.frontend.svc.cluster.local: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
    

    Résultat attendu :

    peerauthentication.security.istio.io "mesh-wide" deleted
    

    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 :

    1. Supprimez les espaces de noms de l'application :
    kubectl delete -f online-boutique/kubernetes-manifests/namespaces
    

    Résultat attendu :

    namespace "ad" deleted
    namespace "cart" deleted
    namespace "checkout" deleted
    namespace "currency" deleted
    namespace "email" deleted
    namespace "frontend" deleted
    namespace "loadgenerator" deleted
    namespace "payment" deleted
    namespace "product-catalog" deleted
    namespace "recommendation" deleted
    namespace "shipping" deleted
    
    1. Supprimez les entrées de service :
    kubectl delete -f online-boutique/istio-manifests/allow-egress-googleapis.yaml
    

    Résultat attendu :

    serviceentry.networking.istio.io "allow-egress-googleapis" deleted
    serviceentry.networking.istio.io "allow-egress-google-metadata" deleted
    

Étape suivante