Anthos Service Mesh et Traffic Director sont désormais Cloud Service Mesh. Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

Cette page a été traduite par l'API Cloud Translation.

Configurer les fonctionnalités avancées des règles d'autorisation

{version_1.0.1 d

La règle d'autorisation Cloud Service Mesh fournit un contrôle des accès au niveau du maillage, de l'espace de noms et de la charge de travail pour les charges de travail du maillage. Cette page décrit en détail la configuration des fonctionnalités avancées de la règle d'autorisation Cloud Service Mesh, y compris le mode de simulation et la journalisation des refus. Les fonctionnalités décrites sur cette page partent du principe que vous connaissez les concepts fondamentaux des règles d'autorisation décrites dans la page Présentation des règles d'autorisation.

Mode de simulation

La règle d'autorisation Cloud Service Mesh est compatible avec le mode de simulation, ce qui vous permet de tester une règle d'autorisation avec du trafic de production réel sans l'appliquer. Le mode de simulation vous permet de mieux comprendre l'effet d'une règle d'autorisation avant de l'appliquer. Cela permet de réduire le risque d'interruption du trafic de production causé par une règle d'autorisation incorrecte.

Vous utilisez l'annotation "istio.io/dry-run": "true" de la règle d'autorisation pour la passer en mode de simulation.

Exemple de mode de simulation

L'exemple suivant, deny-path-headers, montre une règle avec l'annotation dry-run définie sur "true. La règle d'autorisation refuse les requêtes envoyées au chemin headers et autorise toutes les autres requêtes.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "true"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Lorsque vous appliquez une règle d'autorisation en mode dry run, Cloud Service Mesh consigne le résultat de l'application forcée dans Cloud Logging, mais ne l'applique pas. La requête est toujours autorisée, et vous pouvez consulter l'explorateur de journaux pour déterminer si la règle d'autorisation fonctionne comme prévu.

Détails de la journalisation de simulation

Après avoir appliqué une règle d'autorisation en mode de simulation, vous pouvez afficher les résultats de la règle dans l'explorateur de journaux.

Accéder à l'explorateur de journaux Dans la commande suivante, remplacez PROJECT_ID par l'ID de votre projet :
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Dans le champ Query-builder (Générateur de requêtes), saisissez une requête pour trouver la règle d'autorisation du mode de simulation. Dans la requête suivante, remplacez NAMESPACE par votre espace de noms :
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.dry_run_result="AuthzDenied"
```
Cliquez sur Exécuter la requête.
Ajustez la période selon vos besoins.

La capture d'écran suivante montre les libellés de simulation dans le journal du trafic dans l'explorateur de journaux après l'application de l'exemple de règle deny-path-headers :

Le mode de simulation est compatible avec les règles d'autorisation ALLOW et DENY, en plus des résultats de simulation Istio. Cloud Service Mesh stocke les résultats de la simulation dans Cloud Logging sous les libellés suivants:

dry_run_result : le résultat de la simulation est "AuthzAllowed" ou "AuthzDenied".
dry_run_policy_name : espace de noms et nom de la règle d'autorisation correspondante effectuant la décision de simulation.
dry_run_policy_rule : index de la règle de stratégie d'autorisation correspondante ayant pris la décision de simulation.

Le tableau suivant présente les détails enregistrés pour une règle d'autorisation en mode de simulation :

Règle d'autorisation appliquée en mode de simulation	Résultat de correspondance	Résultat de simulation	Cloud Logging
Règle `DENY` uniquement	Pas de correspondances	Autorisés	dry_run_result : "AuthzAllowed"
Règle `DENY` uniquement	Correspondance	refus	dry_run_result : "AuthzDenied" dry_run_policy_name : . dry_run_policy_rule:
Règle `ALLOW` uniquement	Pas de correspondances	refus	dry_run_result : "AuthzDenied"
Règle `ALLOW` uniquement	Correspondance	Autorisés	dry_run_result : "AuthzAllowed" dry_run_policy_name : . dry_run_policy_rule:
Règles `ALLOW` et `DENY`	Aucune correspondance	refus	dry_run_result : "AuthzDenied"
	Règle `DENY` correspondance uniquement	refus	dry_run_result : "AuthzDenied" dry_run_policy_name : . dry_run_policy_rule:
	Règle `ALLOW` correspondance uniquement	Autorisés	dry_run_result : "AuthzAllowed" dry_run_policy_name : . dry_run_policy_rule:
	Correspondance avec les deux règles	refus	dry_run_result : "AuthzDenied" dry_run_policy_name : . dry_run_policy_rule:

Lorsque vous êtes sûr du résultat de la simulation, vous pouvez le mode de simulation de l'une des manières suivantes :

Supprimez complètement l'annotation de simulation, ou
Remplacez la valeur de l'annotation de simulation par false.

Une fois que vous avez appliqué la règle en désactivant le mode de simulation, Cloud Service Mesh l'applique.

Journalisation de refus

La stratégie d'autorisation refuse une requête si celle-ci n'est pas autorisée par la stratégie. Pour les protocoles HTTP (y compris gRPC), la requête est refusée avec le code d'état 403. Pour les protocoles non HTTP, la connexion est interrompue directement. Le journal de trafic Cloud Logging contient des informations supplémentaires utiles pour comprendre pourquoi le trafic est refusé. Par exemple, le journal indique le nombre de requêtes refusées par la stratégie d'autorisation, et peut vous aider à déterminer la stratégie à l'origine du refus depuis l'application backend.

Dans l'exemple suivant, l'annotation dry-run est définie sur "false. Lorsque vous appliquez la règle d'autorisation DENY, Cloud Service Mesh l'applique.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: deny-path-headers
  annotations:
    "istio.io/dry-run": "false"
spec:
  selector:
    matchLabels:
      app: httpbin
  action: DENY
  rules:
  - to:
    - operation:
        paths: ["/headers"]

Après avoir appliqué une stratégie d'autorisation DENY, vous pouvez afficher les résultats de la règle dans l'explorateur de journaux.

Accéder à l'explorateur de journaux Dans la commande suivante, remplacez PROJECT_ID par l'ID de votre projet :
```
https://console.cloud.google.com/logs/query?project=PROJECT_ID
```
Dans le champ Query builder (Générateur de requêtes), saisissez une requête pour trouver la stratégie d'autorisation DENY. Dans la requête suivante, remplacez NAMESPACE par votre espace de noms :
```
logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver" labels.destination_namespace="NAMESPACE" labels.response_details="AuthzDenied"
```
Cliquez sur Exécuter la requête.
Ajustez la période selon vos besoins.

La capture d'écran suivante montre une entrée de journal dans l'explorateur de journaux après l'application de l'exemple de stratégie deny-path-headers pour appliquer la règle. Vous pouvez constater que la stratégie d'autorisation était responsable de l'erreur 403 en consultant les libellés:

Le journal de trafic de l'explorateur de journaux inclut les libellés suivants pour le refus d'autorisation :

response_details : est défini sur "AuthzDenied" si le refus est causé par une stratégie d'autorisation.
policy_name : contient l'espace de noms et le nom de la stratégie d'autorisation DENY à l'origine du refus. La valeur est au format <Namespace>.<Name>. Par exemple, foo.deny-path-headers correspond à une stratégie d'autorisation deny-path-headers dans l'espace de noms foo.
policy_rule : contient l'index de la règle au sein de la stratégie d'autorisation à l'origine du refus. Par exemple, 0 correspond à la première règle de la stratégie.

Étape suivante

Pour obtenir la liste de toutes les règles d'autorisation du maillage de services:

kubectl get authorizationpolicy --all-namespaces

Si une règle d'autorisation est appliquée ,vous pouvez la supprimer avec kubectl delete :

kubectl delete authorizationpolicy -n NAMESPACE AUTH_POLICY_NAME

Pour savoir comment obtenir le journal de trafic, consultez la page Journaux d'accès.