Anthos Service Mesh par exemple: autorisation


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

Qu'est-ce que l'autorisation ?

L'authentification vérifie une identité : s'agit-il de ce service ? L'autorisation vérifie l'autorisation. Ce service est-il autorisé à le faire ? L'identité est au cœur de cette idée. Avec Anthos Service Mesh, AuthorizationPolicies permet de contrôler la communication entre les charges de travail dans votre maillage, pour améliorer la sécurité et les 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 traditionnelles basées sur l'adresse IP ne permettent souvent pas de sécuriser l'accès entre les charges de travail. Avec Anthos Service Mesh, vous pouvez définir des règles d'autorisation pour:

  • Contrôlez l'accès aux charges de travail au sein de votre réseau maillé (charge à charge de travail ou utilisateur final à charge de travail)
  • Définissez des règles de façon générale ou précise en fonction de vos besoins. Pour obtenir une explication détaillée sur la configuration des règles et des bonnes pratiques, consultez la page Autorisation avec Anthos Service Mesh.

Coûts

Ce tutoriel utilise les composants facturables Google Cloud suivants :

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

  • 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:

    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 du type d'Anthos Service Mesh (géré ou au sein du cluster):

    Géré

    Appliquez le libellé de révision asm-managed à l'espace de noms :

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

    Ce libellé correspond à la version disponible d'Anthos Service Mesh géré pour la version d'Anthos Service Mesh.

    Dans le cluster

    1. Exécutez la commande suivante pour localiser le libellé 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 le libellé de révision à l'espace de noms. Dans la commande suivante, REVISION correspond à la valeur du libellé 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 --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 vous ne l'avez pas 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. Suivez la procédure pour activer l'injection side-car automatique.

  4. Déployez l'application exemple, le VirtualService pour l'interface et les comptes de service pour les charges de travail. Pour 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 2/2 n'apparaît pas au bout de 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 devrait s'afficher dans votre navigateur.

    interface de la boutique en ligne

Autorisation DenyAll pour une charge de travail

Cette section ajoute un AuthorizationPolicy pour refuser tout le trafic entrant vers le service de change. AuthorizationPolicies convertit AuthorizationPolicies en configurations lisibles par Envoy et applique ces configurations à vos proxys side-car. Cela permet au proxy Envoy d'autoriser ou de refuser les requêtes entrantes adressées à un service.

  1. Appliquez un AuthorizationPolicy au currencyservice. Notez la correspondance avec 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 au EXTERNAL-IP de votre passerelle pour afficher Online Boutique dans le navigateur Web. Vous devriez voir une erreur d'autorisation (erreur interne du service 500) de currency service.

    Erreur 500 authz rbac

Observer les journaux de votre proxy side-car

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

  1. Obtenez le nom de votre pod currencyservice:

    CURRENCY_POD=$(kubectl get pod -n onlineboutique |grep currency|awk '{print $1}')
    
  2. Configurez le proxy Envoy pour qu'il autorise les journaux de niveau de trace. Par défaut, les appels d'autorisation bloqués ne sont pas consignés:

    kubectl exec -it $CURRENCY_POD -n onlineboutique -c istio-proxy -- curl -X POST "http://localhost:15000/logging?level=trace"
    

    Résultat attendu : 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 liés au contrôle des accès basé sur les rôles (RBAC) dans votre proxy Istio:

    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 l'accès restreint

Au lieu d'une règle DENYALL, vous pouvez autoriser l'accès pour certaines charges de travail. Cela sera utile dans une architecture de microservices dans laquelle vous voulez vous assurer que seuls les services autorisés peuvent communiquer entre eux.

Dans cette section, vous allez permettre aux services frontend et checkout de communiquer avec le service currency.

  1. Dans le fichier ci-dessous, vérifiez qu'un source.principal(client) spécifique a été ajouté à la liste d'autorisation pour 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"]

Appliquez la règle :

kubectl apply -f docs/authorization/currency-allow-frontend-checkout.yaml -n onlineboutique
  1. Accédez à EXTERNAL-IP dans votre navigateur Web. Vous devriez maintenant être en mesure d'accéder à Online Boutique.

Observer vos services dans l'UI de sécurité d'Anthos Service Mesh

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

    Accéder à la page "Sécurité de GKE Enterprise"

  2. La page Sécurité vous permet d'ajouter ou d'activer des fonctionnalités pour sécuriser les charges de travail de vos applications. Pour en savoir plus, consultez Surveiller la sécurité du réseau maillé. Sélectionnez l'onglet Audit des stratégies pour afficher une vue d'ensemble de vos charges de travail.

  3. Notez que dans la colonne Service access control (Contrôle de l'accès au service), seul currencyservice s'affiche comme "Enabled" (Activé). Cliquez sur Enabled (Activé) pour afficher les détails de AuthorizationPolicy.

    audit des règles de sécurité

Ici, vous pouvez voir les AuthorizationPolicy que vous avez appliqués. Cela s'avère utile pour une visibilité sur l'ensemble de vos applications, en particulier si un grand nombre de règles sont appliquées à vos charges de travail. Explorez l'interface utilisateur. Vous pouvez visualiser les interactions entre vos services, ce qui est utile pour visualiser le comportement en matière de sécurité. Il ne s'agit là que d'un exemple simple des avantages offerts par les stratégies lors de la sécurisation de vos charges de travail.

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

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, vous pouvez soit supprimer le projet, soit supprimer les ressources individuelles.

Supprimer le 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 :

      amespace "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
    

Étapes suivantes