Ce que les logs d'audit Kubernetes ne montrent pas

TL;DR. Le log d'audit Kubernetes voit les requêtes adressées à l'API server, et rien d'autre. Il ne voit pas ce qui se passe dans un conteneur ou sur un nœud, les requêtes faites directement au kubelet ou à etcd, les changements d'IAM cloud, ni le trafic réseau. Ce qu'il voit dépend de votre politique d'audit et de celle du fournisseur managé ; certains champs (IP source, user agent) sont influencés par le client ; et des règles à base de motifs ratent les attaquants qui se comportent comme vos admins. Combinez-le avec la détection runtime, les logs des nœuds et des conteneurs, les logs d'audit cloud et les logs de flux.

Chaque article de cette série défend l'idée que le log d'audit est au centre d'une enquête Kubernetes. Celui-ci explique où il s'arrête, pour qu'un résultat « sain » soit lu pour ce qu'il est.

Angle mort 1 : dans les conteneurs et sur les nœuds

L'API server autorise et enregistre la requête qui ouvre une session exec, y compris sa commande initiale, puis relaie des octets qu'il ne journalise pas. Tout ce qui suit est invisible :

• les commandes tapées dans un shell interactif ;
• les processus lancés par l'application après une RCE (reverse shell, binaire téléchargé) ;
• les modifications de fichiers dans le conteneur ;
• tout ce qui est fait sur le nœud après une évasion de conteneur : nouvelles clés SSH, entrées cron, réutilisation des identifiants du kubelet, conteneurs lancés directement via un socket de runtime.

Le log d'audit montre la préparation (un conteneur privilégié, un hostPath sur /, un exec avec chroot /host), pas l'exécution. Pour le reste, il faut des preuves runtime : Falco ou un EDR sur les nœuds, les logs propres des nœuds (journald, logs d'authentification), les logs des conteneurs et un snapshot disque des nœuds touchés.

L'analyseur accepte des alertes Falco en JSON à côté des logs d'audit et place les deux sur une même chronologie ; les alertes de priorité Error et au-dessus deviennent des constats.

Angle mort 2 : les chemins qui contournent l'API server

Le côté cloud a sa propre piste d'audit : CloudTrail pour EKS, Cloud Audit Logs pour GKE, le journal d'activité Azure pour AKS. Les sites frères AWS Forensics, GCP Forensics et Azure Forensics les couvrent.

Angle mort 3 : ce que la politique n'a pas gardé

Ce que vous pouvez détecter est borné par ce qui a été journalisé :

• Le niveau Metadata supprime les corps de requête. La création d'un DaemonSet est visible ; savoir s'il était privilégié, quelle image il exécutait, quel rôle un binding accordait, ne l'est pas. Plusieurs détections ne peuvent tout simplement pas se déclencher. Le guide de la politique d'audit montre quoi journaliser.
• Les politiques managées font leurs propres choix : la politique EKS publiée dans le guide des bonnes pratiques EKS ne journalise pas les Events ; GKE envoie les lectures vers des logs Data Access désactivés par défaut ; la catégorie AKS kube-audit-admin exclut get et list. Voir le guide EKS, GKE et AKS.
• Livraison et taille. EKS décrit la livraison des logs du plan de contrôle comme « best effort », et CloudWatch Logs plafonne les entrées à 1 Mo : les très gros objets peuvent être tronqués.
• Rétention. Les logs expirés avant le début de l'enquête sont perdus. L'accès initial précède souvent la détection.
• Couverture. Sur les clusters autogérés, chaque instance d'API server journalise les requêtes qu'elle a servies ; oublier le fichier d'un nœud du plan de contrôle, c'est perdre une partie de l'histoire.

L'analyseur indique ce qu'il a lu (fichiers, plage horaire, sources, enregistrements ignorés et tronqués) précisément pour rendre ces trous visibles.

Angle mort 4 : des champs auxquels on ne peut pas se fier entièrement

• sourceIPs : la référence des événements d'audit prévient que toutes les IP sauf la dernière peuvent être fixées par le client via X-Forwarded-For. Derrière un load balancer ou un endpoint privé, la dernière IP peut être une adresse d'infrastructure.
• userAgent : fourni par le client. Un attaquant soigneux envoie le même agent que le workload dont il a volé le token.
• Identité : le log nomme l'identifiant, pas la personne. Un token volé et son workload légitime se ressemblent en tout, sauf le contexte (source, horaires, comportement).
• Impersonation : lisez user et impersonatedUser ensemble ; n'en rapporter qu'un seul attribue mal les actions.

Angle mort 5 : les attaquants qui ont l'air normaux

Les règles de détection reconnaissent des motifs. Elles signalent un compte de service qui lance kubectl exec, un binding vers cluster-admin, une image de mineur. Elles ne signalent pas :

• un attaquant qui utilise les identifiants volés d'un admin pour faire ce que cet admin fait d'habitude ;
• une image malveillante au nom ordinaire, depuis votre registry habituel ;
• des données lues lentement, un secret par heure, sous tout seuil de rafale ;
• une identité nommée pour ressembler à un composant système. L'analyseur exclut les identités de contrôleurs par préfixe, ce qui est nécessaire pour éviter des milliers de faux positifs, mais signifie qu'un compte de service nommé pour correspondre à un préfixe exclu dans kube-system pourrait passer inaperçu. Vérifiez qui peut y créer des comptes de service.

Les références comportementales aident : premier exec d'une identité depuis 30 jours, première requête depuis un nouveau réseau, workload créé hors du pipeline de déploiement. Ces comparaisons exigent un historique que l'analyseur ne conserve pas d'une session à l'autre ; votre SIEM, si.

Lire un verdict sain

« Aucun signe de compromission » signifie qu'aucune règle n'a matché dans les données fournies. Avant de l'accepter, vérifiez :

1. La plage horaire couvre-t-elle la période concernée, avec de la marge ?
2. Toutes les sources du plan de contrôle sont-elles incluses, et des fichiers ont-ils été ignorés ?
3. La politique journalise-t-elle les corps des écritures de workloads et de RBAC ?
4. Sur GKE et AKS, les lectures étaient-elles journalisées ?
5. Existe-t-il des preuves indépendantes (alertes runtime, facture cloud, comportement des nœuds) qui contredisent le résultat ?

Si le doute persiste, faites appel à un intervenant expérimenté en réponse à incident et collectez des preuves runtime avant que les nœuds ne soient recyclés.

La carte des preuves

FAQ

Les logs d'audit Kubernetes enregistrent-ils les commandes lancées dans un conteneur ?

Seulement la commande initiale d'un kubectl exec, qui fait partie de l'URI de la requête. Tout ce qui est tapé ensuite dans la session, et tout processus lancé par l'application elle-même, est invisible pour l'API server et nécessite un outillage runtime.

Si l'analyseur n'indique aucun signe de compromission, le cluster est-il sain ?

Pas forcément. Cela signifie qu'aucune règle n'a matché dans les logs fournis. Des plages horaires manquantes, une politique d'audit en Metadata seulement, une activité sur les nœuds ou dans les conteneurs, et des attaquants qui imitent un comportement normal peuvent ne laisser aucune correspondance.

Avec quoi combiner les logs d'audit ?

Détection runtime sur les nœuds (Falco ou un EDR), logs des nœuds et des conteneurs, logs d'audit du plan de contrôle du fournisseur cloud, logs de flux réseau, et historique de déploiement de la CI ou du GitOps.

Articles liés

• Réponse à incident Kubernetes avec les logs d'audit
• Politique d'audit Kubernetes pour la forensique
• Pods privilégiés et indicateurs d'évasion de conteneur