Configurer des règles d'audit pour vos services

Pour en savoir plus, consultez la présentation de Cloud Service Mesh.

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.

Ce tutoriel n'est compatible qu'avec l'implémentation du plan de contrôle dans le cluster.

Une règle d'audit vous permet de réaliser un audit d'accès aux données pour vos services dans Cloud 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. Ce guide explique comment installer Cloud Service Mesh afin de pouvoir utiliser une règle d'audit.

Étant donné que vous consultez les journaux d'audit dans l'explorateur de journaux Cloud Logging de Google Cloud Console, les règles d'audit ne sont compatibles qu'avec les plates-formes suivantes :

• GKE sur Google Cloud
• Google Distributed Cloud (logiciel uniquement) pour VMware
• Google Distributed Cloud (logiciel uniquement) pour solution Bare Metal

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 de Cloud 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.

Avant de commencer

Suivez les étapes de la page Installer les outils dépendants et valider le cluster pour effectuer les opérations suivantes :

• Installer les outils nécessaires
• Télécharger asmcli
• Accorder des autorisations d'administrateur de cluster
• Valider votre projet et votre cluster

Préparer la configuration de la passerelle

Cloud Service Mesh vous permet de déployer et de gérer des passerelles avec votre maillage de services. Une passerelle décrit un équilibreur de charge fonctionnant à la périphérie du réseau maillé recevant des connexions HTTP/TCP entrantes ou sortantes. Les passerelles sont des proxys Envoy qui vous permettent de contrôler avec précision le trafic entrant et sortant du réseau maillé.

asmcli n'installe pas istio-ingressgateway. Nous vous recommandons de déployer et de gérer le plan de contrôle et les passerelles séparément. Pour en savoir plus, consultez la section Installer et mettre à niveau des passerelles.

Personnaliser l'installation de Cloud Service Mesh

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

Installations

1. Suivez les étapes de la page Installer Cloud Service Mesh. Lorsque vous exécutez asmcli install, incluez l'option suivante :

   --option audit-authorizationpolicy
   

   Exemple :

   ./asmcli install \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --ca mesh_ca \
     --output_dir DIR_PATH  \
     --enable_all \
     --option audit-authorizationpolicy
   

   Veillez à spécifier tous les autres fichiers de superposition dont vous avez besoin pour configurer Cloud Service Mesh.

2. Terminez l'installation de Cloud Service Mesh pour activer l'injection automatique de proxy side-car sur vos charges de travail. Consultez la section Déployer et redéployer des charges de travail.

Mises à niveau

1. Suivez les étapes de la page Mettre à niveau Cloud Service Mesh. Lorsque vous exécutez asmcli install, incluez l'option suivante :

   --option audit-authorizationpolicy
   

   Exemple :

   ./asmcli install \
     --project_id PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --ca mesh_ca \
     --output_dir DIR_PATH  \
     --enable_all \
     --option audit-authorizationpolicy
   

   Veillez à spécifier tous les autres fichiers de superposition dont vous avez besoin pour configurer Cloud Service Mesh.

2. Terminez l'installation de Cloud Service Mesh pour activer l'injection automatique de proxy side-car sur vos charges de travail. Pour les mises à niveau, consultez la section Passer au nouveau plan de contrôle

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
   

Étape suivante

• En savoir plus sur la sécurité dans Cloud Service Mesh