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

La règle d'autorisation Cloud Service Mesh fournit un réseau maillé, un espace de noms et contrôle des accès au niveau de la charge de travail pour vos charges de travail dans le maillage. Cette page décrit en détail les fonctionnalités avancées des règles d'autorisation Cloud Service Mesh, y compris le mode de simulation et la journalisation de 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, qui vous permet 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 de simulation, Cloud Service Mesh consigne le le résultat de l'application Cloud Logging, pour appliquer la règle. 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 Run query.
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 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 la règle appliquée avec le mode de simulation désactivé, Cloud Service Mesh applique la règle.

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 stratégie 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 Run query.
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 en savoir plus sur la façon d'obtenir le journal d'accès, consultez la section Accéder aux journaux dans Cloud Logging.