Logs d'audit EKS, GKE et AKS : les activer et les exporter

TL;DR. Sur un Kubernetes managé, vous ne pouvez pas modifier la politique d'audit, mais vous décidez si le log d'audit est conservé. EKS : activez le type de log audit du plan de contrôle ; les événements arrivent dans CloudWatch Logs, groupe /aws/eks/<cluster>/cluster, flux kube-apiserver-audit-*. GKE : l'Admin Activity (écritures) est toujours active ; les lectures, y compris celles de secrets, vont dans les logs Data Access, à activer pour l'API Kubernetes Engine. AKS : créez un paramètre de diagnostic avec la catégorie kube-audit (ou kube-audit-admin, qui exclut get et list). Exportez en JSON, puis déposez les fichiers dans l'analyseur de logs d'audit.

Aucune de ces trois plateformes n'est configurée par défaut d'une manière qui couvre une enquête. Le pire moment pour le découvrir, c'est le lendemain d'une alerte. Ce guide couvre ce qu'il faut activer dès maintenant et comment sortir les données le jour où vous en avez besoin.

Amazon EKS

Activer

Par défaut, EKS n'envoie aucun log du plan de contrôle vers CloudWatch ; chaque type de log s'active séparément, comme l'indique la documentation sur la journalisation du plan de contrôle EKS. Dans la console : cluster, Observability, Control plane logging, Manage logging, activez Audit (et Authenticator, qui fait le lien entre principaux IAM et utilisateurs Kubernetes). En CLI :

aws eks update-cluster-config --region eu-west-1 --name my-cluster \
  --logging '{"clusterLogging":[{"types":["audit","authenticator"],"enabled":true}]}'

Les frais standard d'ingestion et de stockage CloudWatch Logs s'appliquent. La livraison est en « best effort » et prend en général quelques minutes. Fixez sur le groupe de logs une rétention adaptée à vos besoins d'enquête.

Ce que journalise la politique EKS

AWS publie la politique d'audit EKS dans le guide des bonnes pratiques EKS. Les points qui comptent en forensique :

• Secrets, configmaps et token reviews : Metadata uniquement.
• serviceaccounts/token : Request.
• Lectures (get, list, watch) sur le groupe core et les groupes d'API connus : Request ; écritures : RequestResponse. Les specs de workloads et les corps RBAC sont donc disponibles.
• Les events ne sont pas journalisés du tout. Une suppression d'Events n'apparaîtra pas.
• Les entrées CloudWatch Logs sont plafonnées à 1 Mo alors qu'une requête d'API peut atteindre 1,5 Mio : les très gros objets peuvent être tronqués ou réduits aux métadonnées.

Exporter

Pour une courte période, filter-log-events suffit :

aws logs filter-log-events --log-group-name /aws/eks/my-cluster/cluster \
  --log-stream-name-prefix kube-apiserver-audit \
  --start-time 1789344000000 --end-time 1789430400000 > eks-audit.json

Les heures sont en millisecondes epoch. Pour des jours ou des semaines de logs, utilisez une tâche d'export vers S3 (aws logs create-export-task) et téléchargez les objets .gz : chaque ligne est un horodatage suivi de l'événement JSON. Les résultats de CloudWatch Logs Insights exportés en JSON fonctionnent aussi. L'analyseur lit ces trois formes, y compris les fichiers gzip et les dossiers entiers.

Les identités IAM apparaissent dans le log d'audit sous le nom d'utilisateur défini par les access entries ou la ConfigMap aws-auth. Pour suivre le même principal côté AWS (CloudTrail, API EKS, appels AssumeRole), voir AWS Forensics.

Google GKE

Deux logs, dont un désactivé par défaut

GKE écrit les entrées d'audit Kubernetes dans Cloud Audit Logs, sous le type de ressource k8s_cluster. La politique d'audit GKE les répartit ainsi :

• les requêtes create, update et delete vont dans le log Admin Activity, toujours actif et impossible à désactiver ;
• get, list et updateStatus vont dans le log Data Access qui, comme le rappelle la page sur la journalisation d'audit GKE, est désactivé par défaut et facturé une fois activé.

La conséquence est brutale : sur un projet GKE par défaut, un attaquant qui lit tous les secrets avec get ne laisse aucune entrée d'audit pour ces lectures. Activez les logs Data Access de l'API Kubernetes Engine dans IAM et administration, Journaux d'audit, avant d'en avoir besoin, en mettant en balance volume et coût.

Ce que journalise la politique GKE

La même page indique que les requêtes sur les secrets, configmaps et token reviews sont journalisées en Metadata, les lectures en général en Metadata, et les écritures en général en RequestResponse. Les specs de workloads et les bindings RBAC sont donc visibles pour les écritures.

Dans Cloud Logging, l'événement est réécrit : protoPayload.methodName (par exemple io.k8s.core.v1.pods.exec.create), protoPayload.resourceName, protoPayload.authenticationInfo.principalEmail, protoPayload.requestMetadata.callerIp et callerSuppliedUserAgent, un code de statut gRPC au lieu du code HTTP. L'analyseur ramène tout cela au verbe, à la ressource, à la sous-ressource, à l'utilisateur, à l'IP et au code HTTP.

Exporter

gcloud logging read \
  'resource.type="k8s_cluster" AND logName:"cloudaudit.googleapis.com"' \
  --project=my-project --freshness=30d --format=json > gke-audit.json

Vous pouvez aussi télécharger les résultats de l'Explorateur de journaux en JSON ou, pour de longues périodes, router les logs avec un sink vers Cloud Storage ou BigQuery. BigQuery stocke la charge utile dans protopayload_auditlog, avec les corps de requête et de réponse en texte JSON ; l'analyseur lit ces lignes si vous exportez la table ou les résultats de requête en JSON ou JSON délimité par des sauts de ligne (pas en CSV, Avro ou Parquet). La rétention dépend du bucket de logs : les logs Admin Activity vont dans le bucket _Required, les logs Data Access dans _Default, sauf si vous avez modifié le routage. Pour le côté Google Cloud d'un incident (IAM, clés de comptes de service, Compute), GCP Forensics couvre ces logs.

Une limite actuelle de l'analyseur : les détails d'impersonation GKE portés par serviceAccountDelegationInfo ne sont pas encore interprétés.

Azure AKS

Activer

AKS envoie les logs du plan de contrôle via un paramètre de diagnostic sur la ressource du cluster. La documentation de supervision AKS décrit les catégories d'audit :

kube-audit est celle qu'il vous faut pour le vol d'identifiants, puisque les lectures de secrets sont des get et des list. Microsoft prévient qu'elle peut coûter cher ; kube-audit-admin est le compromis moins coûteux, au prix des lectures. Destinations :

• Log Analytics, en mode spécifique à la ressource (tables AKSAudit et AKSAuditAdmin) ou en mode Azure Diagnostics historique (table AzureDiagnostics, JSON de l'événement dans log_s).
• Compte de stockage : blobs horaires PT1H.json dans le conteneur insights-logs-kube-audit.
• Event Hubs : lots {"records": [...]}, généralement consommés par un SIEM.

Exemple avec Azure CLI, vers Log Analytics en mode spécifique à la ressource :

az monitor diagnostic-settings create --name aks-audit \
  --resource <aks-resource-id> --workspace <workspace-resource-id> \
  --export-to-resource-specific true \
  --logs '[{"category":"kube-audit","enabled":true}]'

Exporter

Depuis un compte de stockage, téléchargez les blobs PT1H.json de la période (l'arborescence encode la date et l'heure) et déposez le dossier entier. Depuis Log Analytics, interrogez la table et enregistrez le résultat en JSON plutôt qu'en CSV :

az monitor log-analytics query --workspace <workspace-guid> \
  --analytics-query "AKSAudit | where TimeGenerated between (datetime(2026-09-13) .. datetime(2026-09-15))" \
  -o json > aks-audit.json

La taille des résultats de requête est plafonnée : découpez les longues périodes en plusieurs requêtes. L'analyseur lit les lignes AKSAudit (colonnes en PascalCase), les lignes AzureDiagnostics, les blobs de compte de stockage et les lots Event Hubs. Pour les connexions Entra ID et l'activité Azure autour du cluster, voir Azure Forensics.

Clusters autogérés

Sur kubeadm, k3s, RKE2 ou des distributions on-premises, la politique et les fichiers sont à vous. Copiez audit.log et ses fichiers rotés depuis chaque nœud du plan de contrôle (chaque API server ne journalise que les requêtes qu'il a servies), ou exportez-les depuis la destination de votre webhook ou de votre agent d'expédition. L'article sur la politique d'audit propose une politique orientée forensique comme point de départ.

Avant d'analyser

• Couvrez toute la période, en commençant plusieurs jours avant le premier événement suspect.
• Gardez les originaux intacts et travaillez sur des copies ; calculez des empreintes si le dossier peut aller en justice.
• Notez le fuseau horaire. Les horodatages d'audit sont en UTC ; les exports de console ne le sont pas forcément.
• Cherchez les trous. Une journée sans aucun événement signifie en général un changement de configuration, pas un cluster calme.

Ouvrez ensuite l'analyseur de logs d'audit Kubernetes, déposez les fichiers ou dossiers, et suivez le guide d'analyse pas à pas.

Articles liés

• Politique d'audit Kubernetes pour la forensique
• Anatomie d'un événement d'audit Kubernetes
• Réponse à incident Kubernetes avec les logs d'audit