Version 1.8

Configurer des règles d'audit pour vos services

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 consulter les journaux d'audit dans l'explorateur de journaux Cloud Logging de Google Cloud Console. 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 Cloud Console, accédez au menu de navigation et sélectionnez Logging > Explorateur de journaux :

    Accéder à l'explorateur de journaux

  4. Sélectionnez un projet 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
    
  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 :

    image

  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 :

    image

  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 :

    image

  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"
    

    image

  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
    

    image image image

  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