Use Layer 4 authorization policies - - Centre de documentation Alibaba Cloud

Le modèle de configuration de l'authentification et de l'autorisation en mode Ambient Mesh diffère de celui du mode Sidecar d'origine en raison de la séparation entre le niveau 4 et le niveau 7. Cette rubrique explique comment utiliser les politiques d'autorisation de niveau 4 dans les instances Service Mesh (ASM) v1.18.

Prérequis

Une passerelle d'entrée et les applications associées sont déployées, et les fonctionnalités de base sont vérifiées. Pour plus d'informations, consultez les prérequis et l'étape 1 de la section Prise en main.

Limites

Les limites suivantes s'appliquent aux politiques d'autorisation dans les ztunnels :
- Le champ action ne peut pas être défini sur CUSTOM ; les ztunnels ne prennent donc pas en charge les services d'autorisation personnalisés.
- Les champs requestPrincipals et remoteIpBlocks ne sont pas pris en charge dans le champ source.
- Seul le champ ports est pris en charge dans le champ operation.
En l'absence de proxy waypoint, les ztunnels appliquent les politiques d'autorisation. Dans ce cas, liez les politiques d'autorisation aux charges de travail spécifiées.
Un ztunnel est un proxy de niveau 4. Si vous configurez une politique d'autorisation contenant des règles de niveau 7 sur un ztunnel, seules les règles de niveau 4 s'appliquent.

Exemple 1 : Autoriser uniquement la passerelle et l'application sleep à accéder au service productpage

Cet exemple vérifie si les ztunnels exécutent correctement l'autorisation en fonction des principals. Pour plus d'informations, consultez la section Prise en main.

Une fois le test terminé, exécutez la commande suivante pour supprimer la politique d'autorisation :

kubectl delete authorizationpolicy productpage-viewer

Exemple 2 : Interdire l'accès au port 9080 du service productpage

Cet exemple vérifie principalement si les ztunnels exécutent correctement l'autorisation en fonction des ports de destination.

Créez un fichier productpage-viewer.yaml avec le contenu suivant :

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: productpage-viewer
 namespace: default
spec:
 selector:
   matchLabels:
     app: productpage
 action: DENY
 rules:
 - to:
   - operation:
       ports:
       - "9080"

Connectez-vous à l'instance ASM via kubectl en utilisant les informations du fichier kubeconfig, puis exécutez la commande suivante pour créer la politique d'autorisation :
```
kubectl apply -f productpage-viewer.yaml
```
Vérifiez si la politique d'autorisation prend effet.
1. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Résultat attendu :
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Résultat attendu :
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Résultat attendu :
```
command terminated with exit code 56
```
4. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Résultat attendu :
```
command terminated with exit code 56
```
  Le résultat indique qu'aucun pod ne peut accéder au port 9080 du service productpage.
  
  Lors des deux premiers tests, une erreur upstream connect error or disconnect/reset before headers. reset reason: connection termination% apparaît dans les réponses aux requêtes d'accès au service productpage via la passerelle. La passerelle d'entrée renvoie cette erreur. Si la passerelle ne peut pas accéder au service productpage (le service productpage n'autorise pas la passerelle d'entrée à accéder à son port 9080), une erreur HTTP 503 s'affiche.
  
  Les réponses des deux derniers tests affichent command terminated with exit code 56, renvoyé par la commande curl. La commande curl tente directement d'établir une connexion avec le service productpage, mais échoue. Par conséquent, aucune erreur HTTP n'apparaît, contrairement à l'erreur observée lors d'un accès direct via la passerelle.
Exécutez la commande suivante pour supprimer la politique d'autorisation :
```
kubectl delete authorizationpolicy productpage-viewer
```

Exemple 3 : Interdire à l'adresse IP du pod sleep d'accéder au service productpage

Cet exemple vérifie principalement si les ztunnels exécutent correctement l'autorisation en fonction des adresses IP source.

Exécutez la commande suivante pour obtenir l'adresse IP du pod sleep :

kubectl get pod -o wide | grep sleep

Résultat attendu :

notsleep-5fb85fb789-z****         1/1     Running   0          48m   10.0.67.92   cn-hangzhou.10.0.67.41   <none>           <none>
sleep-bc9998558-z****             1/1     Running   0          48m   10.0.67.91   cn-hangzhou.10.0.67.42   <none>           <none>

Le résultat attendu indique que l'adresse IP du pod sleep dans l'environnement de test actuel est 10.0.67.91. L'adresse IP réelle du pod peut varier selon l'environnement.

Créez un fichier productpage-viewer.yaml avec le contenu suivant afin d'interdire aux requêtes provenant de l'adresse IP du pod sleep d'accéder au service productpage.

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

Connectez-vous à l'instance ASM via kubectl en utilisant les informations du fichier kubeconfig, puis exécutez la commande suivante pour créer la politique d'autorisation :
```
kubectl apply -f productpage-viewer.yaml
```
Vérifiez si la politique d'autorisation prend effet.
1. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Résultat attendu :
```
<title>Simple Bookstore App</title>
```
2. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage" | grep -o "<title>.*</title>"
```
  Résultat attendu :
```
<title>Simple Bookstore App</title>
```
3. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/
```
  Résultat attendu :
```
command terminated with exit code 56
```
4. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Résultat attendu :
```
<title>Simple Bookstore App</title>
```
  Le résultat indique que lorsque vous déployez uniquement des ztunnels sans proxy waypoint, vous ne pouvez pas empêcher le pod sleep d'accéder au service productpage via la passerelle. En effet, le champ remoteIpBlocks de la politique d'autorisation dépend de l'en-tête X-Forwarded-For de la requête, tandis qu'un ztunnel est un proxy de niveau 4.
Exécutez la commande suivante pour supprimer la politique d'autorisation :
```
kubectl delete authorizationpolicy productpage-viewer
```

Exemple 4 : Interdire aux pods du namespace istio-system d'accéder au service productpage

Cet exemple vérifie principalement si les ztunnels exécutent correctement l'autorisation en fonction des namespaces source. Un namespace source désigne le namespace dans lequel un pod initie une requête.

Créez un fichier productpage-viewer.yaml avec le contenu suivant afin d'interdire aux pods du namespace istio-system d'accéder au service productpage :

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

Connectez-vous à l'instance ASM via kubectl en utilisant les informations du fichier kubeconfig, puis exécutez la commande suivante pour créer la politique d'autorisation :
```
kubectl apply -f productpage-viewer.yaml
```
Vérifiez si la politique d'autorisation prend effet.
1. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/sleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Résultat attendu :
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
2. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/notsleep -- curl -s "http://$GATEWAY_HOST/productpage"
```
  Résultat attendu :
```
upstream connect error or disconnect/reset before headers. reset reason: connection termination%
```
3. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/sleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Résultat attendu :
```
<title>Simple Bookstore App</title>
```
4. Exécutez la commande suivante pour tester l'accès :
```
kubectl exec deploy/notsleep -- curl -s http://productpage:9080/ | grep -o "<title>.*</title>"
```
  Résultat attendu :
```
<title>Simple Bookstore App</title>
```
  La passerelle d'entrée est déployée dans le namespace istio-system. Le résultat indique qu'après la création de la politique d'autorisation, les applications sleep et notsleep ne peuvent pas accéder au service productpage via la passerelle, mais elles peuvent y accéder directement.
Exécutez la commande suivante pour supprimer la politique d'autorisation :
```
kubectl delete authorizationpolicy productpage-viewer
```