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.
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
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.
-
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 -
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.
-
Accédez à
productpagevia la passerelle :kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"Résultat attendu :
<title>Simple Bookstore App</title> -
Accédez à
productpagedirectement depuis le podsleep:kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"Résultat attendu :
<title>Simple Bookstore App</title> -
Tentez d'accéder à
productpagedepuis le podnotsleep(non autorisé) :kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"Résultat attendu :
command terminated with exit code 56La 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 :
Créez un proxy waypoint avec un libellé spécifiant le type de trafic qu'il gère.
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
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.
-
Déployez un proxy waypoint pour le compte de service
bookinfo-productpage:istioctl x waypoint apply --service-account bookinfo-productpage -
Confirmez que le proxy waypoint est prêt :
kubectl get gtw bookinfo-productpage -o yaml -
Mettez à jour la politique d'autorisation pour n'autoriser que les requêtes GET provenant du compte de service
sleepet 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 -
Vérifiez la politique :
-
Requête DELETE via la passerelle (bloquée) :
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" -X DELETERésultat attendu :
RBAC: access denied -
Requête depuis
notsleep(bloquée) :kubectl exec deploy/notsleep -- curl -s http://productpage:9080/Résultat attendu :
RBAC: access denied -
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
-
Acheminez le trafic
reviewsvia le proxy waypoint existant :kubectl label service reviews istio.io/use-waypoint=waypoint -
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 -
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-v1et 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
-
Déployez un proxy waypoint pour le compte de service
bookinfo-reviews:istioctl x waypoint apply --service-account bookinfo-reviews -
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 -
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-v1et 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-