Configurer des règles d'audit pour vos services

Preview — Audit policy

Cette fonctionnalité est soumise aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les fonctionnalités pré-DG sont disponibles "en l'état" et peuvent avoir une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

Une règle d'audit vous permet de réaliser un audit d'accès aux données pour vos services dans Anthos Service Mesh. L'audit de vos services vous aide à répondre aux questions "qui a fait quoi, quand et éventuellement pourquoi ?". Avec une règle d'audit, vous pouvez choisir quand un journal d'audit est créé et ce qu'il contient. Vous pouvez afficher les journaux d'audit dans l'explorateur de journaux Cloud Logging de la console Google Cloud. Ce guide explique comment installer Anthos Service Mesh sur GKE sur Google Cloud de manière à pouvoir utiliser une règle d'audit.

Une règle d'audit étend la méthode AuthorizationPolicy en ajoutant une action AUDIT. Elle n'est prise en compte que dans le champ d'application de règle cible (il peut s'agir d'une charge de travail, d'un espace de noms ou de l'ensemble du maillage). Les règles sont définies par ORed, ce qui signifie qu'une requête n'est enregistrée que si une règle l'exige. Si aucune règle d'audit ne s'applique à une charge de travail donnée, aucun journal d'audit n'est généré pour cette charge de travail.

Voici un exemple de règle d'audit permettant d'auditer tous les accès en écriture au chemin d'accès /user/profile/* dans myapi :

  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    namespace: ns1
    name: anyname
  spec:
    selector:
      matchLabels:
        app: myapi
    action: AUDIT
    rules:
    - to:
      - operation:
          methods: ["POST", "UPDATE", "DELETE"]
          paths: ["/user/profile/*"]

Limites

• Il n'y a pas de journal d'audit pour la passerelle d'entrée ingress-gateway.
• Le contenu d'audit n'est pas configurable.
• Les journaux d'audit d'Anthos Service Mesh offrent actuellement le même niveau de fiabilité que les journaux d'accès standards. Par exemple, si un pod de charge de travail est redémarré, certains journaux d'audit de la charge de travail peuvent être perdus s'ils ne sont pas conservés.

Personnaliser l'installation d'Anthos Service Mesh

Pour utiliser une règle d'audit, personnalisez l'installation d'Anthos Service Mesh :

1. Suivez les étapes de la page Installer Anthos Service Mesh sur GKE afin d'utiliser un script fourni par Google pour installer Anthos Service Mesh. Lorsque vous exécutez le script, incluez l'option suivante :

   --option audit-authorizationpolicy
   

   Exemple :

   ./install_asm \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --mode install \
     --output_dir DIR_PATH  \
     --enable_all \
     --option audit-authorizationpolicy
   

2. Terminez l'installation d'Anthos Service Mesh pour activer l'injection automatique de proxy sidecar sur vos charges de travail. Pour en savoir plus, consultez la page Déployer et redéployer des charges de travail.

Utiliser les journaux d'audit

Cette section utilise l'exemple Bookinfo pour montrer comment utiliser la journalisation d'audit.

1. Déployez l'exemple d'application Bookinfo dans l'espace de noms par défaut.

2. Obtenez l'adresse IP externe de la passerelle d'entrée et envoyez des requêtes à l'exemple d'application pour générer du trafic.

3. Dans la console Google Cloud, accédez au menu de navigation et sélectionnez Logging > Explorateur de journaux:
   

   Accéder à l'explorateur de journaux

4. Sélectionnez un projet Google Cloud.

5. Comme vous n'avez pas encore déployé de règle d'audit, vous n'aurez aucun journal d'audit. Notez que le journal d'audit est différent du journal d'accès. Pour afficher les journaux d'accès stackdriver, saisissez la requête suivante dans le champ Créateur de requête, puis cliquez sur Exécuter la requête :

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
   

   Pour en savoir plus sur l'utilisation de l'explorateur de journaux, consultez la page Présentation de l'explorateur de journaux.

Configurer la règle d'audit et vérifier les journaux d'audit

Cette section propose plusieurs options pour effectuer un audit de l'application Bookinfo. Après avoir déployé la règle d'audit, vous pouvez envoyer des requêtes puis vérifier le journal d'audit dans l'explorateur de journaux.

1. Saisissez la commande suivante pour obtenir des identifiants d'authentification afin d'interagir avec le cluster. Cette commande définit également le contexte actuel de kubectl sur le cluster.

   gcloud container clusters get-credentials CLUSTER_NAME \
       --project=PROJECT_ID \
       --zone=CLUSTER_LOCATION
   

   Remarque : pour le cluster régional, remplacez --region par --zone.

2. Appliquez la règle d'audit suivante pour auditer les requêtes GET sur le chemin /productpage :

   kubectl apply -f - << EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "AuthorizationPolicy"
   metadata:
     name: "audit-productpage"
     namespace: default
   spec:
     action: AUDIT
     rules:
     - to:
       - operation:
           methods: ["GET"]
           paths: ["/productpage"]
   EOF
   

3. Envoyez des requêtes à Bookinfo.

4. Dans l'explorateur de journaux, saisissez la requête suivante dans le champ du Générateur de requêtes, puis cliquez sur Exécuter la requête :

   logName="projects/PROJECT_ID/logs/server-istio-audit-log"
   

   La requête renvoie des journaux semblables à ce qui suit :

   

5. Appliquez la règle suivante pour auditer les requêtes adressées au service bookinfo-ratings. Les règles d'audit sont additives. Après avoir appliqué la règle suivante, vous verrez des journaux d'audit pour les requêtes envoyées à ProductPage et à Ratings.

   kubectl apply -f - << EOF
   apiVersion: "security.istio.io/v1beta1"
   kind: "AuthorizationPolicy"
   metadata:
     name: "audit-ratings"
     namespace: default
   spec:
     action: AUDIT
     rules:
     - from:
       - source:
           principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
       to:
       - operation:
           methods: ["GET"]
   EOF
   

   La nouvelle règle d'audit doit se propager avant d'être appliquée.

6. Envoyez 10 requêtes ou plus à Bookinfo pour être sûr d'appeler le service "ratings", puis consultez le journal d'audit dans l'explorateur de journaux. Le journal d'audit ressemble à ceci :

   

7. Appliquez la règle suivante pour auditer tous les services de l'espace de noms par défaut.

   kubectl apply -f - << EOF
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     namespace: default
     name: "audit-all"
   spec:
     action: AUDIT
     rules:
       - {}
   EOF
   

8. Envoyez des requêtes supplémentaires à Bookinfo, puis consultez le journal d'audit dans l'explorateur de journaux. Le journal d'audit consigne désormais toutes les requêtes :

   

9. Si vous souhaitez limiter la règle d'audit à ProductPage et Ratings, vous pouvez supprimer la règle audit-all :

   kubectl delete authorizationpolicy audit-all -n default
   

Dépannage

Si aucun journal d'audit ne s'affiche après l'activation d'une règle d'audit, vous pouvez effectuer les vérifications suivantes :

1. Assurez-vous qu'il y a du trafic pour la période spécifiée dans l'explorateur de journaux. Si vous testez avec Bookinfo, vous pouvez envoyer plusieurs requêtes en exécutant la commande suivante plusieurs fois :

   curl -s http://EXTERNAL_IP/productpage | grep Bookstore
   

2. Vérifiez si la passerelle d'entrée comporte une AuthorizationPolicy qui bloque les requêtes adressées au service audité.

3. Consultez les journaux d'accès stackdriver avec le filtre suivant dans l'explorateur de journaux pour vérifier si vos requêtes ont atteint l'application :

   logName="projects/PROJECT_ID/logs/server-accesslog-stackdriver"
   

   

4. Pour vous assurer que Stackdriver est configuré et que le journal d'audit est activé, créez un fichier de vidage de l'état istiod actuel. Dans config_dump, recherchez enable_audit_log et le nom de votre règle d'audit.

   istioctl dashboard envoy POD_NAME.NAMESPACE
   

   

5. Pour vous assurer que vos requêtes sont mises en correspondance avec les règles d'audit, vous pouvez consulter les journaux de débogage du contrôle des accès basé sur les rôles (RBAC). Activez la journalisation du débogage RBAC à l'aide de la commande suivante :

   kubectl exec POD_NAME -n NAMESPACE -c istio-proxy -- pilot-agent request POST 'logging?rbac=debug'
   

6. Envoyez des requêtes, puis vérifiez les journaux du pod à l'aide de la commande kubectl logs :

   kubectl logs POD_NAME -n NAMESPACE -c istio-proxy
   

Étapes suivantes

• Apprenez-en plus sur la sécurité dans Anthos Service Mesh.