:Layer 7 authorization policies for waypoint proxies

Fonctionnement de l'autorisation avec les proxys Waypoint

Sans proxy Waypoint, les ztunnels appliquent l'autorisation uniquement au niveau de la couche 4 (ports, adresses IP, identités). Après le déploiement d'un proxy Waypoint pour un service :

1. Le ztunnel délègue toutes les décisions d'autorisation pour ce service au proxy Waypoint et laisse passer le trafic du proxy Waypoint inconditionnellement.

2. Les stratégies d'autorisation qui utilisent selector pour faire correspondre le pod d'application (ciblant le ztunnel) sont contournées.

3. Les stratégies d'autorisation doivent utiliser selector avec le libellé istio.io/gateway-name pour cibler le proxy Waypoint.

Le proxy Waypoint peut ensuite appliquer des stratégies de niveau 7 basées sur les attributs HTTP tels que les hôtes, les chemins, les méthodes et les en-têtes. Lorsqu'une requête est refusée, le proxy Waypoint renvoie RBAC: access denied avec le statut HTTP 403.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Une instance ASM exécutant la version v1.18

• Une passerelle d'entrée et des applications exemples déployées, avec vérification des fonctionnalités de base. Pour plus de détails, consultez les prérequis et l'étape 1 de la section Prise en main

Limites

Déployer un proxy Waypoint

Déployez un proxy Waypoint pour le service productpage avant d'exécuter les exemples.

1. Déployez le proxy Waypoint :

   istioctl x waypoint apply --service-account bookinfo-productpage

2. Vérifiez que le pod du proxy Waypoint est en cours d'exécution :

   kubectl get pod --show-labels | grep waypoint

   Sortie attendue :

   bookinfo-productpage-istio-waypoint-6c579dd48d-l****   1/1     Running   0          91s    gateway.istio.io/managed=istio.io-mesh-controller,istio.io/gateway-name=bookinfo-productpage,pod-template-hash=6c579dd48d,service.istio.io/canonical-name=bookinfo-productpage-istio-waypoint,service.istio.io/canonical-revision=latest,sidecar.istio.io/inject=false

Exemple 1 : Les stratégies ciblant le ztunnel n'ont aucun effet lorsqu'un proxy Waypoint est déployé

Une erreur de configuration courante consiste à appliquer une stratégie d'autorisation à un ztunnel alors qu'un proxy Waypoint est déjà déployé pour le service. Étant donné que le ztunnel s'en remet au proxy Waypoint, la stratégie est entièrement contournée. Cet exemple décrit d'abord l'approche incorrecte, puis montre comment la corriger.

Exemple 2 : Refuser l'accès depuis une adresse IP spécifique

Les stratégies d'autorisation des proxys Waypoint ne prennent pas en charge ipBlocks. Utilisez remoteIpBlocks pour faire correspondre l'adresse IP du client d'origine. Vous pouvez configurer le champ remoteIpBlocks pour faire correspondre les requêtes transitant par la passerelle.

1. Créez un fichier productpage-viewer.yaml qui refuse l'adresse IP du pod sleep :

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: productpage-viewer
    namespace: default
   spec:
    selector:
      matchLabels:
        istio.io/gateway-name: bookinfo-productpage
    action: DENY
    rules:
    - from:
      - source:
          remoteIpBlocks:
          - "${sleep Pod IP}"

   Remplacez ${sleep Pod IP} par l'adresse IP réelle du pod sleep.

2. Appliquez la stratégie :

   kubectl apply -f productpage-viewer.yaml

3. Testez l'accès depuis le pod sleep.

   Via la passerelle :

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

   Sortie :

   RBAC: access denied%

   Accès direct :

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

   Sortie :

   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Fri, 19 Jul 2024 08:17:08 GMT
   server: istio-envoy

   L'accès via la passerelle et l'accès direct depuis le pod sleep sont tous deux refusés.

4. Supprimez la stratégie :

   kubectl delete authorizationpolicy productpage-viewer

Exemple 3 : Refuser l'accès depuis un namespace spécifique

Cet exemple bloque tout le trafic provenant du namespace istio-system. Étant donné que la passerelle d'entrée s'exécute dans istio-system, les requêtes routées via la passerelle sont refusées, tandis que les requêtes directes de pod à pod provenant d'autres namespaces aboutissent toujours.

1. Créez un fichier productpage-viewer.yaml :

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
    name: productpage-viewer
    namespace: default
   spec:
    selector:
      matchLabels:
        istio.io/gateway-name: bookinfo-productpage
    action: DENY
    rules:
    - from:
      - source:
          namespaces:
          - istio-system

2. Appliquez la stratégie :

   kubectl apply -f productpage-viewer.yaml

3. Testez l'accès.

   Via la passerelle depuis sleep :

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

   Sortie :

   RBAC: access denied%

   Via la passerelle depuis notsleep :

   kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"

   Sortie :

   RBAC: access denied%

   Accès direct depuis sleep :

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

   Sortie :

   <title>Simple Bookstore App</title>

   Accès direct depuis notsleep :

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

   Sortie :

   <title>Simple Bookstore App</title>

   Le trafic routé via la passerelle est refusé car la passerelle s'exécute dans le namespace istio-system. L'accès direct depuis les pods d'autres namespaces (tels que default) n'est pas affecté.

4. Supprimez la stratégie :

   kubectl delete authorizationpolicy productpage-viewer

Exemple 4 : Refuser les requêtes par en-tête d'hôte

Cet exemple refuse les requêtes dont l'en-tête host est test.com sur le port 9080. Les requêtes avec d'autres valeurs d'hôte passent.

1. Créez un fichier productpage-viewer.yaml :

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: productpage-viewer
     namespace: default
   spec:
     selector:
       matchLabels:
         istio.io/gateway-name: bookinfo-productpage
     action: DENY
     rules:
     - to:
       - operation:
           hosts: ["test.com"]
           ports: ["9080"]

2. Appliquez la stratégie :

   kubectl apply -f productpage-viewer.yaml

3. Testez l'accès.

   Requête avec Host: test.com :

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -H "Host: test.com"

   Sortie :

   RBAC: access denied%

   Requête avec Host: test1.com :

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -H "Host: test1.com" -I

   Sortie :

   HTTP/1.1 200 OK
   content-type: text/html; charset=utf-8
   content-length: 5290
   server: istio-envoy
   date: Tue, 15 Aug 2023 03:39:29 GMT
   x-envoy-upstream-service-time: 18

   Seul l'hôte test.com est refusé. Les autres valeurs d'hôte passent normalement.

4. Supprimez la stratégie :

   kubectl delete authorizationpolicy productpage-viewer

Exemple 5 : Refuser une méthode HTTP spécifique sur un chemin spécifique

Cet exemple bloque les requêtes HEAD vers le chemin /productpage. Les requêtes GET vers le même chemin et les requêtes HEAD vers d'autres chemins sont autorisées.

1. Créez un fichier productpage-viewer.yaml :

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: productpage-viewer
     namespace: default
   spec:
     selector:
       matchLabels:
         istio.io/gateway-name: bookinfo-productpage
     action: DENY
     rules:
     - to:
       - operation:
           methods: ["HEAD"]
           paths: ["/productpage"]

2. Appliquez la stratégie :

   kubectl apply -f productpage-viewer.yaml

3. Testez l'accès.

   Requête HEAD vers /productpage :

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -I

   Sortie :

   HTTP/1.1 403 Forbidden
   content-length: 19
   content-type: text/plain
   date: Tue, 15 Aug 2023 03:59:37 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 0

   Requête GET vers /productpage :

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/productpage -XGET -I

   Sortie :

   HTTP/1.1 200 OK
   content-type: text/html; charset=utf-8
   content-length: 5290
   server: istio-envoy
   date: Tue, 15 Aug 2023 03:39:29 GMT
   x-envoy-upstream-service-time: 18

   Requête HEAD vers /api/v1/products :

   kubectl exec deploy/sleep -- curl -s http://$GATEWAY_HOST/api/v1/products -I

   Sortie :

   HTTP/1.1 200 OK
   content-type: text/html; charset=utf-8
   content-length: 5290
   server: istio-envoy
   date: Tue, 15 Aug 2023 03:39:29 GMT
   x-envoy-upstream-service-time: 18

   Seules les requêtes HEAD vers /productpage sont refusées. La stratégie n'affecte pas les autres méthodes ou chemins.

4. Supprimez la stratégie :

   kubectl delete authorizationpolicy productpage-viewer

Étapes suivantes

• Authentification et autorisation de niveau 4 – Configurez des stratégies d'autorisation appliquées par les ztunnels au niveau de la couche 4

• Prise en main – Déployez les applications exemples utilisées dans ces exemples