Kubernetes Audit Logs

Définition

Les Kubernetes Audit Logs enregistrent toutes les requêtes effectuées vers le kube-apiserver, le composant central du plan de contrôle Kubernetes. Ils constituent la source de données forensique la plus complète pour investiguer des incidents de sécurité dans un cluster Kubernetes : toute action (création, modification, suppression de ressources, exec dans un pod, accès aux secrets) génère un event d'audit avec des informations complètes sur qui, quoi, quand et depuis quelle source. Un événement d'audit Kubernetes contient : le timestamp, l'identité du demandeur (user, group, UID, ServiceAccount), la ressource ciblée (type, namespace, nom), le verbe (create, get, list, patch, delete, exec), les en-têtes de requête et réponse, le corps de requête (pour les mutations) et le code de réponse. Ces informations permettent de reconstituer précisément la timeline d'une attaque. La politique d'audit (AuditPolicy) définit quels événements sont journalisés et avec quel niveau de détail : None (pas de log), Metadata (métadonnées seulement, pas de corps de requête/réponse), Request (métadonnées + corps de la requête), RequestResponse (métadonnées + corps requête + corps réponse). Une politique granulaire capture les événements critiques (accès aux Secrets, exec, création de ClusterRoleBindings) au niveau RequestResponse et filtre les événements bruyants à faible valeur (health checks, watch operations) au niveau None. Dans les clusters managés EKS, AKS, et GKE, les logs d'audit sont gérés par le cloud provider et accessibles via leurs services de logging (CloudWatch Logs, Log Analytics/Azure Monitor, Cloud Logging). Des outils de détection spécifiques à Kubernetes dans les SIEMs (Microsoft Sentinel Kubernetes règles, Falco Kubernetes Audit Plugin, Elastic Security for Kubernetes) analysent ces logs pour détecter les patterns d'attaque MITRE ATT&CK for Containers. Les événements Kubernetes Audit à surveiller prioritairement incluent : creation de ClusterRoleBinding vers des rôles privilegiés (persistance), exec dans des pods de production (post-exploitation), accès à des Secrets spécifiques (vol de credentials), modification de politiques de sécurité (OPA/Kyverno policies), et création de ressources non standard dans kube-system (persistance).