Journaux d’audit Kubernetes : guide de détection

L’API server est la porte d’entrée du control plane Kubernetes. Déploiements, lectures de secrets, role bindings et exec interactifs y passent. Les journaux d’audit Kubernetes préservent la séquence qui répond à qui a fait quoi, où et quand.

Le volume brut ne constitue pas une détection. Il faut une politique volontaire, une protection des champs sensibles et des analyses liées à l’identité et au risque du workload.

Ce que fournit l’audit Kubernetes

La documentation officielle Kubernetes décrit un enregistrement chronologique des actions des utilisateurs, applications et du control plane :

• Metadata : acteur, verbe, ressource et temps sans body ;
• Request : métadonnées et corps de requête ;
• RequestResponse : requête et réponse ;
• None : événement exclu.

Les bodies peuvent contenir secrets ou données personnelles. Collectez le minimum utile et protégez le backend.

Concevoir la politique

Commencez par une couverture Metadata large et ne supprimez que le bruit compris. Augmentez le détail pour les changements sensibles comme role bindings, admission ou namespaces critiques.

Couvrez :

• échecs d’authentification et autorisation ;
• accès et modification des secrets ;
• roles et cluster roles ;
• service accounts et tokens ;
• exec, attach et port-forward ;
• webhooks et admission ;
• workloads privilégiés ;
• changements des contrôles de sécurité.

Envoyez vers un backend distant et protégé afin que la compromission du cluster n’efface pas facilement les preuves.

Motifs de détection

Élévation de privilèges

Alertez sur cluster-admin, permissions wildcard, pods privilégiés, hostPath, namespaces hôte et usage inattendu d’un service account.

Accès aux secrets

Détectez list ou get sur de nombreux secrets, depuis une nouvelle identité ou hors du namespace habituel.

Accès interactif

Surveillez exec et attach en production, surtout depuis un utilisateur, une IP ou un horaire inhabituel. Joignez commande et runtime.

Persistance

Recherchez nouveaux webhooks, daemon sets, cron jobs, service accounts, tokens et workloads dans les namespaces système.

Évasion

Alertez sur suppression d’agents, changement de logs, retrait de webhooks et accès à la configuration d’audit.

Enrichir l’événement

Mappez identité humaine et service account à équipe, privilège et namespaces normaux. Ajoutez réputation de l’IP, contexte appareil ou VPN et criticité. Résolvez le digest de l’image avec signature, provenance, SBOM et vulnérabilités.

Un admin créant un rôle pendant un changement prévu diffère d’un compte dormant accordant cluster-admin depuis une IP hostile.

Corréler control plane et runtime

L’audit montre les actions demandées ; le runtime montre les processus, fichiers et sockets ensuite. Reliez :

• création du pod et exécution de l’image ;
• exec et shell lancé ;
• lecture de secret et connexion sortante ;
• role binding et changement privilégié ;
• update et nouveau digest.

La corrélation avec la sécurité runtime eBPF transforme l’anomalie en récit d’incident.

Réponse à incident

Préservez les événements dans l’ordre et trouvez la première requête malveillante. Révoquez les credentials, retirez les ressources et isolez les workloads sans perdre les preuves. Revoyez toutes les actions de l’identité et de l’IP.

Comparez l’état à l’infrastructure-as-code et vérifiez les digests. Recherchez identité, IP, user agent et motif dans les autres clusters.

Métriques

Suivez clusters audités, couverture, délai d’ingestion, événements perdus, exposition de bodies, détections, faux positifs et temps de reconstruction. Testez par exercices contrôlés.

Conclusion

Les journaux d’audit racontent l’activité de l’API. Collectez le bon détail, enrichissez l’identité et corrélez le runtime. Associez-les au guide des attaques contre le control plane cloud pour transformer une requête dangereuse en occasion de confinement.