Tous les produits
Search
Centre de documentation

:Get started with Ambient Mesh

Dernière mise à jour :Aug 11, 2026

Appliquez des politiques d'autorisation et configurez le routage pondéré du trafic pour une application déployée en mode Ambient Mesh. Ce guide détaille l'application des politiques de couche 4 et de couche 7 à l'aide de l'exemple d'application Bookinfo, puis illustre la répartition du trafic entre différentes versions de service.

Prérequis

  • L'exemple d'application Bookinfo et les charges de travail associées (sleep, notsleep) sont déployés. Pour obtenir les instructions d'installation, consultez la rubrique Préparatifs.

  • L'interface CLI istioctl est installée et correspond à votre système d'exploitation ainsi qu'à la version de votre instance ASM. Téléchargez-la depuis les versions d'Istio sur GitHub.

Important

De nombreuses étapes de ce guide nécessitent de basculer entre les contextes Kubernetes des clusters de plan de données et de plan de contrôle. Vérifiez toujours votre contexte actuel avant chaque opération afin d'éviter toute mauvaise configuration. Utilisez l'outil kubectx pour changer de contexte plus rapidement, ou activez l'option Accès à l'API Kubernetes aux ressources Istio depuis les clusters de plan de données pour gérer directement les ressources du plan de contrôle.

Étape 1 : Appliquer des politiques d'autorisation

Les politiques d'autorisation déterminent quelles charges de travail peuvent communiquer au sein du maillage. Commencez par définir une politique de couche 4 basée sur l'identité de la charge de travail, puis ajoutez une politique de couche 7 pour contrôler les aspects HTTP, tels que la restriction des méthodes.

Créer une politique d'autorisation de couche 4

Remarque

Les politiques d'autorisation de couche 4 pour ASM V1.22 sont en phase de test canari. Les politiques pour ASM V1.21 et versions antérieures fonctionnent comme prévu. Pour activer les politiques de couche 4 sur ASM V1.22, soumettez un ticket.

Une politique de couche 4 filtre le trafic selon des attributs liés à la connexion, tels que l'identité source. La politique suivante autorise uniquement le compte de service sleep et la passerelle d'entrée à accéder au service productpage.

  1. Basculez kubectl vers le contexte de l'instance ASM et appliquez la politique :

       kubectl apply -f - <<EOF
       apiVersion: security.istio.io/v1beta1
       kind: AuthorizationPolicy
       metadata:
         name: productpage-viewer
         namespace: default
       spec:
         selector:
           matchLabels:
             app: productpage
         action: ALLOW
         rules:
         - from:
           - source:
               principals:
               - cluster.local/ns/default/sa/sleep
               - cluster.local/ns/istio-system/sa/istio-ingressgateway
       EOF
  2. Vérifiez la politique. Les identités autorisées reçoivent une réponse, tandis que les charges de travail non autorisées sont rejetées.

    1. Accédez à productpage via la passerelle :

         kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"

      Résultat attendu :

         <title>Simple Bookstore App</title>
    2. Accédez à productpage directement depuis le pod sleep :

         kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      Résultat attendu :

         <title>Simple Bookstore App</title>
    3. Tentez d'accéder à productpage depuis le pod notsleep (non autorisé) :

         kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      Résultat attendu :

         command terminated with exit code 56

      La requête émise par notsleep échoue car son compte de service ne figure pas dans la liste d'autorisation.

Ajouter des politiques d'autorisation de couche 7

Les politiques de couche 7 ajoutent des contrôles au niveau HTTP, comme la restriction des méthodes autorisées (GET, POST, DELETE). Un proxy waypoint doit intercepter le trafic destiné au service cible avant que les politiques de couche 7 ne prennent effet.

ASM V1.22 et versions ultérieures

ASM V1.22 utilise une approche en deux étapes pour configurer les proxies waypoint :

  1. Créez un proxy waypoint avec un libellé spécifiant le type de trafic qu'il gère.

  2. Associez les services au waypoint en appliquant un libellé contenant le nom du waypoint à chaque service, namespace ou pod concerné.

Déployez le proxy waypoint. Basculez kubectl vers le contexte du cluster ACK :

kubectl apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  labels:
    istio.io/waypoint-for: service
  name: waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE
EOF

Champs clés :

Champ Valeur Description
gatewayClassName istio-waypoint Identifie cette Gateway comme un proxy waypoint
istio.io/waypoint-for service Le proxy gère le trafic au niveau du service. Autres options : workload (niveau pod) ou all (les deux)

Acheminez le trafic de productpage via le waypoint. Ajoutez un libellé au service productpage :

kubectl label service productpage istio.io/use-waypoint=waypoint

Mettez à jour la politique d'autorisation. Basculez kubectl vers le contexte de l'instance ASM. Cette politique de couche 7 n'autorise que les requêtes GET provenant du compte de service sleep :

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: productpage-viewer
  namespace: default
spec:
  targetRefs:
  - kind: Service
    group: ""
    name: productpage
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/sleep
    to:
    - operation:
        methods: ["GET"]
EOF
Remarque

Si cette politique ne s'applique pas correctement, supprimez d'abord la politique existante à l'aide de la commande kubectl delete authorizationpolicy productpage-viewer, puis réappliquez-la.

Vérifiez la politique de couche 7. Basculez kubectl vers le contexte du cluster ACK et exécutez les tests suivants :

Requête GET depuis sleep (autorisée) :

kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

Résultat attendu :

<title>Simple Bookstore App</title>

Requête DELETE depuis sleep (bloquée — seule la méthode GET est autorisée) :

kubectl exec deploy/sleep -- curl -XDELETE -s http://productpage:9080/

Résultat attendu :

RBAC: access denied

Requête depuis notsleep (bloquée — absent de la liste d'autorisation) :

kubectl exec deploy/notsleep -- curl -s http://productpage:9080/

Résultat attendu :

RBAC: access denied

Ces trois résultats confirment que la politique restreint l'accès en fonction de l'identité et de la méthode HTTP.

ASM V1.21 et versions antérieures

Pour ASM V1.21, utilisez istioctl pour déployer un proxy waypoint lié à un compte de service.

  1. Déployez un proxy waypoint pour le compte de service bookinfo-productpage :

       istioctl x waypoint apply --service-account bookinfo-productpage
  2. Confirmez que le proxy waypoint est prêt :

       kubectl get gtw bookinfo-productpage -o yaml

    Résultat attendu

       apiVersion: gateway.networking.k8s.io/v1beta1
       kind: Gateway
       metadata:
         annotations:
           gateway.istio.io/controller-version: "5"
           istio.io/for-service-account: bookinfo-productpage
         creationTimestamp: "2023-08-10T08:35:51Z"
         generation: 1
         name: bookinfo-productpage
         namespace: default
         resourceVersion: "7828921"
         uid: c085b788-a8fa-4a2c-8376-18d08689****
       spec:
         gatewayClassName: istio-waypoint
         listeners:
         - allowedRoutes:
             namespaces:
               from: Same
           name: mesh
           port: 15008
           protocol: HBONE
       status:
         conditions:
         - lastTransitionTime: "2023-08-10T08:35:51Z"
           message: Handled by Istio controller
           observedGeneration: 1
           reason: Accepted
           status: "True"
           type: Accepted
  3. Mettez à jour la politique d'autorisation pour n'autoriser que les requêtes GET provenant du compte de service sleep et de la passerelle d'entrée :

       kubectl apply -f - <<EOF
       apiVersion: security.istio.io/v1beta1
       kind: AuthorizationPolicy
       metadata:
         name: productpage-viewer
         namespace: default
       spec:
         selector:
           matchLabels:
             istio.io/gateway-name: bookinfo-productpage
         action: ALLOW
         rules:
         - from:
           - source:
               principals:
               - cluster.local/ns/default/sa/sleep
               - cluster.local/ns/istio-system/sa/istio-ingressgateway
           to:
           - operation:
               methods: ["GET"]
       EOF
  4. Vérifiez la politique :

    1. Requête DELETE via la passerelle (bloquée) :

         kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" -X DELETE

      Résultat attendu :

         RBAC: access denied
    2. Requête depuis notsleep (bloquée) :

         kubectl exec deploy/notsleep -- curl -s http://productpage:9080/

      Résultat attendu :

         RBAC: access denied
    3. Requête GET depuis sleep (autorisée) :

         kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"

      Résultat attendu :

         <title>Simple Bookstore App</title>

Étape 2 : Configurer le routage pondéré du trafic

Une fois le proxy waypoint en place, vous pouvez appliquer des règles de routage pondéré pour répartir le trafic entre les versions de service. Cet exemple dirige 90 % du trafic vers reviews-v1 et 10 % vers reviews-v2.

ASM V1.22 et versions ultérieures

  1. Acheminez le trafic reviews via le proxy waypoint existant :

       kubectl label service reviews istio.io/use-waypoint=waypoint
  2. Appliquez une DestinationRule et une VirtualService pour répartir le trafic :

       kubectl apply -f - <<EOF
       apiVersion: networking.istio.io/v1alpha3
       kind: DestinationRule
       metadata:
         name: reviews
       spec:
         host: reviews
         trafficPolicy:
           loadBalancer:
             simple: RANDOM
         subsets:
         - name: v1
           labels:
             version: v1
         - name: v2
           labels:
             version: v2
         - name: v3
           labels:
             version: v3
       ---
       apiVersion: networking.istio.io/v1alpha3
       kind: VirtualService
       metadata:
         name: reviews
       spec:
         hosts:
           - reviews
         http:
         - route:
           - destination:
               host: reviews
               subset: v1
             weight: 90
           - destination:
               host: reviews
               subset: v2
             weight: 10
       EOF
  3. Envoyez 100 requêtes et vérifiez qu'environ 10 % atteignent reviews-v2 :

       kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://$GATEWAY_HOST/productpage | grep reviews-v.-; done"

    Résultat attendu (environ 90 lignes correspondant à reviews-v1 et 10 lignes à reviews-v2) :

       <u>reviews-v1-5896f547f5-48zcn</u>
       <u>reviews-v1-5896f547f5-48zcn</u>
       <u>reviews-v2-5d99885bc9-qb5cv</u>
       <u>reviews-v1-5896f547f5-48zcn</u>
       ...

ASM V1.21 et versions antérieures

  1. Déployez un proxy waypoint pour le compte de service bookinfo-reviews :

       istioctl x waypoint apply --service-account bookinfo-reviews
  2. Appliquez une DestinationRule et une VirtualService pour répartir le trafic :

       kubectl apply -f - <<EOF
       apiVersion: networking.istio.io/v1alpha3
       kind: DestinationRule
       metadata:
         name: reviews
       spec:
         host: reviews
         trafficPolicy:
           loadBalancer:
             simple: RANDOM
         subsets:
         - name: v1
           labels:
             version: v1
         - name: v2
           labels:
             version: v2
         - name: v3
           labels:
             version: v3
       ---
       apiVersion: networking.istio.io/v1alpha3
       kind: VirtualService
       metadata:
         name: reviews
       spec:
         hosts:
           - reviews
         http:
         - route:
           - destination:
               host: reviews
               subset: v1
             weight: 90
           - destination:
               host: reviews
               subset: v2
             weight: 10
       EOF
  3. Envoyez 100 requêtes et vérifiez la répartition du trafic :

       kubectl exec deploy/sleep -- sh -c "for i in \$(seq 1 100); do curl -s http://$GATEWAY_HOST/productpage | grep reviews-v.-; done"

    Résultat attendu (environ 90 lignes correspondant à reviews-v1 et 10 lignes à reviews-v2) :

       <u>reviews-v1-5896f547f5-48zcn</u>
       <u>reviews-v1-5896f547f5-48zcn</u>
       <u>reviews-v2-5d99885bc9-qb5cv</u>
       <u>reviews-v1-5896f547f5-48zcn</u>
       ...

Étape 3 : Nettoyage

Supprimez les ressources créées dans ce guide.

Supprimez les proxies waypoint et les politiques d'autorisation :

istioctl x waypoint delete --service-account bookinfo-productpage
istioctl x waypoint delete --service-account bookinfo-reviews
kubectl delete authorizationpolicy productpage-viewer

Supprimez les règles de routage du trafic (si elles ont été appliquées) :

kubectl delete virtualservice reviews
kubectl delete destinationrule reviews

Supprimez les libellés waypoint des services (ASM V1.22) :

kubectl label service productpage istio.io/use-waypoint-
kubectl label service reviews istio.io/use-waypoint-