Exemples avec Cloud Service Mesh: autorisation

Remarque : Ce guide est uniquement consacré à Cloud Service Mesh avec les API Istio. Il ne concerne pas les API. Google Cloud Pour en savoir plus, consultez la présentation de Cloud Service Mesh. .

Dans ce tutoriel, vous allez découvrir ce qu'est l'autorisation et comment l'activer avec Cloud Service Mesh sur un exemple d'application. Vous apprendrez également à activer des règles d'autorisation pour vos microservices. Vous allez créer une AuthorizationPolicy pour DENY l'accès à un microservice, puis une AuthorizationPolicy pour ALLOW un accès spécifique à un microservice.

Qu'est-ce que l'autorisation ?

L'authentification vérifie une identité : ce service est-il bien celui qu'il prétend être ? L'autorisation vérifie l'autorisation : ce service est-il autorisé à effectuer cette action ? L'identité est fondamentale pour ce concept. Avec Cloud Service Mesh, les AuthorizationPolicies permettent de contrôler la communication entre les charges de travail de votre maillage pour améliorer la sécurité et l'accès.

Dans une architecture de microservices, où les appels sont effectués au-delà des limites du réseau, les règles de pare-feu basées sur l'adresse IP ne suffisent souvent pas à sécuriser l'accès entre les charges de travail. Avec Cloud Service Mesh, vous pouvez définir des règles d'autorisation pour :

• contrôler l'accès aux charges de travail de votre maillage, que ce soit entre charges de travail ou entre un utilisateur final et une charge de travail ;
• définir des règles de manière générale ou précise, selon vos besoins.

Pour obtenir une explication détaillée sur la configuration des règles et les bonnes pratiques, consultez la section Autorisation avec Cloud Service Mesh.

Coûts

Ce tutoriel utilise les composants facturables suivants de Google Cloud:

• GKE
• Cloud Service Mesh

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

• Assurez-vous que la facturation est activée pour votre projet.

• Provisionnez Cloud Service Mesh sur un cluster GKE. Plusieurs méthodes de configuration sont compatibles :

  • API Fleet et plan de contrôle géré sur Google Cloud

  • asmcli et plan de contrôle non géré au sein du cluster Google Cloud

• Clonez le dépôt :

  git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-samples
  cd anthos-service-mesh-samples
  

Déployer une passerelle d'entrée

1. Définissez le contexte actuel de kubectl sur le cluster :

   Remarque : Utilisez --region au lieu de --zone si le cluster est un cluster régional.

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

2. Créez un espace de noms pour votre passerelle d'entrée :

   kubectl create namespace asm-ingress
   

3. Activez l'espace de noms pour l'injection : Les étapes dépendent de votre mise en œuvre du plan de contrôle.

   Plan de contrôle géré (TD)

   Appliquez les étiquettes d'injection par défaut à l'espace de noms.

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Plan de contrôle géré (Istiod)

   Recommandation : Exécutez la commande suivante pour appliquer l'étiquette d'injection par défaut à l'espace de noms :

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Si vous utilisez déjà le plan de contrôle Istiod géré : nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est acceptée. Suivez les instructions suivantes :

   1. Exécutez la commande suivante pour localiser les canaux de publication disponibles :

      kubectl -n istio-system get controlplanerevision
      

      Le résultat ressemble à ce qui suit :

      NAME                AGE
      asm-managed-rapid   6d7h
      

      Remarque : Si deux révisions du plan de contrôle apparaissent dans la liste précédente, supprimez-en une. Il n'est pas possible d'avoir plusieurs canaux de plan de contrôle dans un même cluster.

      Dans le résultat, la valeur de la colonne NAME est l'étiquette de révision qui correspond au canal de publication disponible pour la version de Cloud Service Mesh.

   2. Appliquez l'étiquette de révision à l'espace de noms :

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

   Au sein du cluster

   Recommandation : Exécutez la commande suivante pour appliquer l'étiquette d'injection par défaut à l'espace de noms :

   kubectl label namespace asm-ingress \
       istio.io/rev- istio-injection=enabled --overwrite
   

   Nous vous recommandons d'utiliser l'injection par défaut, mais l'injection basée sur les révisions est acceptée : Suivez les instructions ci-dessous :

   1. Exécutez la commande suivante pour localiser l'étiquette de révision sur istiod :

      kubectl get deploy -n istio-system -l app=istiod -o \
          jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
      

   2. Appliquez l'étiquette de révision à l'espace de noms. Dans la commande suivante, REVISION_LABEL correspond à la valeur de l'étiquette de révision istiod que vous avez notée à l'étape précédente.

      kubectl label namespace asm-ingress \
          istio-injection- istio.io/rev=REVISION_LABEL --overwrite
      

4. Déployez l'exemple de passerelle dans le dépôt anthos-service-mesh-samples :

   kubectl apply -n asm-ingress \
       -f docs/shared/asm-ingress-gateway
   

   Résultat attendu :

   serviceaccount/asm-ingressgateway configured
   service/asm-ingressgateway configured
   deployment.apps/asm-ingressgateway configured
   gateway.networking.istio.io/asm-ingressgateway configured
   

Déployez l'exemple d'application Boutique en ligne.

1. Si ce n'est pas déjà fait, définissez le contexte actuel de kubectl sur le cluster :

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

2. Créez l'espace de noms pour l'exemple d'application :

   kubectl create namespace onlineboutique
   

3. Ajoutez un libellé à l'espace de noms onlineboutique pour injecter automatiquement les proxys Envoy :

   kubectl label namespace onlineboutique \
      istio.io/rev- istio-injection=enabled --overwrite
   

4. Déployez l'application exemple, le VirtualService pour l'interface et les comptes de service pour les charges de travail. Dans ce tutoriel, vous allez déployer Online Boutique, une application de démonstration de microservices.

   kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/virtual-service.yaml
   

   kubectl apply \
     -n onlineboutique \
     -f docs/shared/online-boutique/service-accounts
   

Afficher vos services

1. Affichez les pods dans l'espace de noms onlineboutique :

   kubectl get pods -n onlineboutique
   

   Résultat attendu :

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-85598d856b-m84m6               2/2     Running   0          2m7s
   cartservice-c77f6b866-m67vd              2/2     Running   0          2m8s
   checkoutservice-654c47f4b6-hqtqr         2/2     Running   0          2m10s
   currencyservice-59bc889674-jhk8z         2/2     Running   0          2m8s
   emailservice-5b9fff7cb8-8nqwz            2/2     Running   0          2m10s
   frontend-77b88cc7cb-mr4rp                2/2     Running   0          2m9s
   loadgenerator-6958f5bc8b-55q7w           2/2     Running   0          2m8s
   paymentservice-68dd9755bb-2jmb7          2/2     Running   0          2m9s
   productcatalogservice-84f95c95ff-c5kl6   2/2     Running   0          114s
   recommendationservice-64dc9dfbc8-xfs2t   2/2     Running   0          2m9s
   redis-cart-5b569cd47-cc2qd               2/2     Running   0          2m7s
   shippingservice-5488d5b6cb-lfhtt         2/2     Running   0          2m7s
   

   Tous les pods de votre application doivent être opérationnels, avec une valeur 2/2 dans la colonne READY. Cela indique que les pods ont un proxy side-car Envoy injecté avec succès. Si la valeur 2/2 ne s'affiche pas après quelques minutes, consultez le guide de dépannage.

2. Obtenez l'adresse IP externe et définissez-la sur une variable :

   kubectl get services -n asm-ingress
   export FRONTEND_IP=$(kubectl --namespace asm-ingress \
   get service --output jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}' \
   )
   

   Vous obtenez un résultat semblable à celui-ci :

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
   asm-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m
   
   

3. Accédez à l'adresse EXTERNAL-IP dans votre navigateur Web. La boutique en ligne doit s'afficher dans votre navigateur.

   

Autorisation DenyAll pour une charge de travail

Cette section ajoute une AuthorizationPolicy pour refuser tout le trafic entrant vers le service de devise. Les AuthorizationPolicies fonctionnent en transformant les AuthorizationPolicies en configurations lisibles par Envoy et en appliquant les configurations à vos proxys side-car. Cela permet au proxy Envoy d'autoriser ou de refuser les requêtes entrantes vers un service.

1. Appliquez une AuthorizationPolicy au currencyservice. Notez la correspondance sur le libellé currencyservice dans le fichier YAML.

   kubectl apply -f docs/authorization/currency-deny-all.yaml -n onlineboutique
   

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: currency-policy
   spec:
     selector:
       matchLabels:
         app: currencyservice

2. Essayez d'accéder à l'EXTERNAL-IP de votre passerelle pour afficher la boutique en ligne dans le navigateur Web. Une erreur d'autorisation (500 Internal Service Error) doit s'afficher à partir du currency service.

   

Observer les journaux de votre proxy side-car

Pour voir ce qui se passe dans le proxy side-car, vous pouvez consulter les journaux dans le pod.

1. Obtenez le nom de votre pod currencyservice :

   CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')
   

2. Définissez le proxy Envoy pour autoriser les journaux au niveau du suivi. Par défaut, les appels d'autorisation bloqués ne sont pas consignés :

   kubectl debug --image istio/base --target istio-proxy -it $CURRENCY_POD -n onlineboutique -- curl -X POST "http://localhost:15000/logging?level=trace"
   

   Résultat attendu : none {:.devsite-disable-click-to-copy} active loggers: admin: trace alternate_protocols_cache: trace ... tracing: trace upstream: trace udp: trace wasm: trace

3. Utilisez curl pour envoyer du trafic à votre EXTERNAL_IP afin de générer des journaux :

   for i in {0..10}; do
   curl -s -I $FRONTEND_IP ; done
   

4. Affichez les journaux associés au contrôle des accès basé sur les rôles (RBAC) dans votre istio-proxy :

   kubectl logs -n onlineboutique $CURRENCY_POD -c istio-proxy | grep -m5 rbac
   

   Résultat attendu :

   2022-07-08T14:19:20.442920Z     debug   envoy rbac      checking request: requestedServerName: outbound_.7000_._.currencyservice.onlineboutique.svc.cluster.local, sourceIP: 10.8.8.5:34080, directRemoteIP: 10.8.8.5:34080, remoteIP: 10.8.8.5:34080,localAddress: 10.8.0.6:7000, ssl: uriSanPeerCertificate: spiffe://christineskim-tf-asm.svc.id.goog/ns/onlineboutique/sa/default, dnsSanPeerCertificate: , subjectPeerCertificate: OU=istio_v1_cloud_workload,O=Google LLC,L=Mountain View,ST=California,C=US, headers: ':method', 'POST'
   2022-07-08T14:19:20.442944Z     debug   envoy rbac      enforced denied, matched policy none
   2022-07-08T14:19:20.442965Z     debug   envoy http      [C73987][S13078781800499437460] Sending local reply with details rbac_access_denied_matched_policy[none]
     ```
   

Un message enforced denied doit s'afficher dans les journaux, indiquant que currencyservice est configuré pour bloquer les requêtes entrantes.

Autoriser un accès limité

Au lieu d'une règle DENYALL, vous pouvez définir un accès autorisé pour certaines charges de travail. Cela sera pertinent dans une architecture de microservices où vous souhaitez vous assurer que seuls les services autorisés peuvent communiquer entre eux.

Dans cette section, vous allez activer la possibilité pour les services frontend et checkout de communiquer avec le service currency.

1. Dans le fichier suivant, vous verrez qu'un source.principal(client) spécifique est autorisé à accéder à currencyservice :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: currency-policy
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/onlineboutique/sa/checkoutservice"]

1. Appliquez la règle :

   kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
   

2. Accédez à l'EXTERNAL-IP dans votre navigateur Web. Vous devriez maintenant pouvoir accéder à la boutique en ligne.

Libérer de l'espace

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 supprimez les ressources individuelles.

Pour éviter que les ressources utilisées lors de ce tutoriel continuent d'être facturées sur votre Google Cloud compte pour, supprimez le projet ou les ressources individuelles.

Supprimer le projet

Attention : La suppression d'un projet a les effets suivants :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour ce tutoriel, lorsque vous le supprimez, vous supprimez également tout autre travail que vous avez effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, comme une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'intégralité du projet.

Dans Cloud Shell, supprimez le projet :

  gcloud projects delete PROJECT_ID

Supprimer les ressources

• 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 namespace onlineboutique
     

     Résultat attendu :

     namespace "onlineboutique" deleted
     

  2. Supprimez l'espace de noms de la passerelle d'entrée :

     kubectl delete namespace asm-ingress
     

     Résultat attendu :

     namespace "asm-ingress" deleted
     

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

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

Étape suivante

• Pour obtenir un guide général sur la configuration des règles PeerAuthentication, consultez la page Configurer la sécurité du transport.
• Explorez le tableau de bord de sécurité de votre maillage avec Surveiller la sécurité du maillage.
• Approfondissez vos connaissances sur les règles d'autorisation avec Configurer les fonctionnalités avancées des règles d'autorisation.
• Familiarisez-vous avec les bonnes pratiques de sécurité pour Cloud Service Mesh.