Anthos Service Mesh 1.13 est arrivé en fin de vie et n'est plus compatible. Consultez la section Mettre à niveau à partir de versions antérieures.

Accédez à la documentation la plus récente ou sélectionnez une autre version disponible :

Versions disponibles

1.20 (la plus récente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

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. Ce guide explique comment installer Anthos 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
GKE sur VMware
Google Distributed Cloud Virtual pour 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 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.

Avant de commencer

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

Préparer la configuration de la passerelle

Anthos 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é.

Par défaut, asmcli n'installe pas la 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. Si vous avez besoin d'installer l'option istio-ingressgateway par défaut avec le plan de contrôle au sein du cluster, incluez l'argument --option legacy-default-ingressgateway.

Personnaliser l'installation d'Anthos Service Mesh

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

Installations

Suivez les étapes de la page Installer Anthos 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 Anthos Service Mesh.

Terminez l'installation d'Anthos 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.

Licences

Suivez les étapes de la page Mettre à niveau Anthos 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 Anthos Service Mesh.
Terminez l'installation d'Anthos 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.

Déployez l'exemple d'application Bookinfo dans l'espace de noms par défaut.
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.
Dans la console Google Cloud, accédez au menu de navigation et sélectionnez Logging > Explorateur de journaux:

Accéder à l'explorateur de journaux
Sélectionnez un projet Google Cloud.
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.

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.

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

Envoyez des requêtes à Bookinfo.
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 :
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.
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 :

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

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 :
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 :

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
```
Vérifiez si la passerelle d'entrée comporte une AuthorizationPolicy qui bloque les requêtes adressées au service audité.
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"
```
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
```
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'
```
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.