Kubernetes Monitoring Security

Définition

Le monitoring sécurité Kubernetes couvre la surveillance des composants du cluster, des workloads, et du trafic réseau pour détecter les anomalies et les incidents de sécurité. Il combine l'observabilité technique (métriques, logs, traces) avec les signaux de sécurité (Kubernetes Audit Logs, alertes Falco, anomalies réseau) pour une visibilité complète sur la sécurité du cluster. Les sources de données clés pour le monitoring sécurité Kubernetes incluent : les Kubernetes Audit Logs (toutes les actions sur l'API server, source principale pour la forensique), les logs des conteneurs (stdout/stderr de chaque conteneur, collectés par DaemonSet comme Fluentd, Fluent Bit, ou Vector), les métriques Prometheus (CPU, mémoire, erreurs, latence par pod et par namespace), les logs du plan de contrôle (kube-apiserver, etcd, kube-scheduler), et les alertes Falco/Sysdig (détection comportementale runtime). La stack de monitoring Kubernetes la plus commune est la Prometheus/Grafana stack : kube-prometheus-stack (Helm chart) déploie Prometheus (collecte de métriques), AlertManager (routing des alertes), et Grafana (visualisation). Des dashboards Grafana prêts à l'emploi (Kubernetes cluster monitoring, Node Exporter Full) visualisent les métriques de sécurité : consommation CPU/mémoire par pod (spike indiquant potentiellement du cryptomining), nombre d'erreurs 403/401 sur l'API server (tentatives d'accès non autorisés), et métriques de NetworkPolicies (connexions refusées). L'intégration du monitoring sécurité avec les SIEMs se fait via plusieurs mécanismes : les logs conteneurs via Fluentd/Fluent Bit vers Elasticsearch (Elastic Stack) ou vers le SIEM, les alertes Falco via le channel gRPC vers Falcosidekick (qui les route vers Slack, Teams, PagerDuty, SIEM), et les Kubernetes Events (événements normaux et anormaux du cluster) vers CloudWatch Logs ou Log Analytics. Les métriques de sécurité clés à monitorer dans Kubernetes incluent : le nombre de pods en état CrashLoopBackOff (peut indiquer des conteneurs compromis incapables de démarrer normalement après modification), le nombre de pods privilegiés (devrait être 0 hors composants système), les modifications de ClusterRoleBindings (alerter sur chaque modification), et les volumes de trafic réseau par pod (spike anormal pouvant indiquer une exfiltration ou un C2).