Surveillance de la sécurité des clusters Kubernetes et alertes : guide pratique de mise en œuvre

Introduction

La surveillance de la sécurité pour Kubernetes est une discipline, pas un produit que l'on installe une fois pour toutes. Les clusters sont dynamiques, les attaques évoluent, et une alerte qui se déclenche sans procédure claire n'est que du bruit. Ce guide s'adresse aux ingénieurs plateforme, consultants DevOps et équipes de startup qui doivent passer de « nous avons vu quelque chose de bizarre » à « nous avons observé, vérifié et récupéré ».

Nous couvrirons les quatre piliers de la surveillance de la sécurité Kubernetes : quoi collecter (métriques, journaux, événements d'audit), comment générer des alertes, comment visualiser les données et comment réagir lorsqu'une alerte se déclenche. Pour chaque recommandation, vous trouverez des commandes concrètes, les sorties attendues et les points de décision. L'objectif est la sécurité opérationnelle : observer avant de modifier, limiter le rayon d'impact, utiliser des espaces réservés au lieu de secrets et vérifier avant de clore un incident.

Ce guide suppose un cluster Kubernetes (version 1.24 ou ultérieure) avec un accès kubectl et une pile de surveillance telle que Prometheus et Grafana. Si vous utilisez un service géré comme EKS, GKE ou AKS, la plupart des principes s'appliquent encore, mais certains détails de configuration différeront.

Inventaire des versions et de l'environnement

Avant de pouvoir surveiller la sécurité, vous devez savoir ce que vous exécutez. Un nombre surprenant d'incidents de sécurité commencent par un composant non corrigé ou un drapeau du serveur d'API mal configuré que personne n'a remarqué pendant des mois.

Liste de vérification de l'inventaire

Exécutez ces commandes et enregistrez la sortie dans votre journal des opérations ou votre dépôt Git :

# Version du cluster
kubectl version --short

# Versions des nœuds et système d'exploitation
kubectl get nodes -o wide

# Pods du plan de contrôle (si autogéré)
kubectl get pods -n kube-system -l tier=control-plane

# Plugin CNI et version
kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel|weave'

La sortie attendue pour un cluster sain en version 1.26 pourrait ressembler à :

Client Version: v1.26.3
Server Version: v1.26.3
NAME            STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
worker-node-1   Ready    <none>          34d   v1.26.3   10.0.1.5      <none>        Ubuntu 22.04.2 LTS   5.15.0-1031-aws     containerd://1.6.18

Pourquoi c'est important pour la surveillance de la sécurité

Décalage de version : un nœud exécutant la version 1.24 alors que le serveur d'API exécute la version 1.26 peut manquer des correctifs de sécurité ou se comporter de manière inattendue.
Système d'exploitation du nœud : si vous voyez Ubuntu 20.04 sur un nœud et 22.04 sur un autre, vos bases de sécurité sont incohérentes.
Plugin CNI : l'application des politiques réseau dépend du CNI. Calico, Cilium et d'autres ont des capacités et des formats de journalisation différents.

Plus petit changement justifié

Si vous constatez une incompatibilité de version, ne mettez pas tout à niveau en une seule fois. Mettez à niveau un nœud, vérifiez qu'il rejoint le cluster et que les pods sont replanifiés, puis continuez. Documentez le chemin de retour en arrière (par exemple, kubectl cordon et kubectl drain avant la mise à niveau).

Question rapide 1 sur 2

D'après le passage 1, que fournit la journalisation d'audit de Kubernetes ?

Le passage 1 indique que la journalisation d'audit fournit un ensemble chronologique d'enregistrements pertinents pour la sécurité documentant la séquence d'actions dans un cluster.

Chemin de configuration sécurisé

La configuration de la surveillance de la sécurité doit suivre les mêmes principes que tout changement d'infrastructure : petit, testé et réversible.

Politique réseau de refus par défaut

L'une des améliorations de sécurité à plus fort impact est une politique réseau de refus par défaut. Mais l'appliquer aveuglément peut casser les applications. Suivez ce chemin sûr :

Observez le trafic actuel avec un outil d'observabilité réseau (par exemple, Cilium Hubble, Calico Enterprise ou un maillage de services).
Écrivez une politique qui autorise le trafic nécessaire connu.
Appliquez d'abord en mode audit si votre CNI le prend en charge.
Appliquez la politique dans un espace de noms de test avant de l'étendre à tout le cluster.

Exemple de politique de refus par défaut pour un espace de noms :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Ajoutez ensuite des règles d'autorisation pour des flux spécifiques. Par exemple, autoriser les pods payments-api à communiquer avec la base de données :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-payments-to-db
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payments-api
  policyTypes:
  - Egress
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: postgres
    ports:
    - protocol: TCP
      port: 5432

Vérifiez avec kubectl describe networkpolicy et en testant la connectivité depuis un pod avec et sans le libellé.

Politique d'audit du serveur d'API

Les journaux d'audit Kubernetes sont votre source principale pour « qui a fait quoi et quand ». Activez la journalisation d'audit avec un fichier de politique qui capture les événements pertinents pour la sécurité sans se noyer dans le bruit.

Exemple de fichier de politique d'audit (audit-policy.yaml) :

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]
- level: RequestResponse
  verbs: ["create", "update", "patch"]
  resources:
  - group: "rbac.authorization.k8s.io"
    resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]
- level: Metadata
  userGroups: ["system:authenticated"]
  omitStages: ["RequestReceived"]

Cette politique journalise les métadonnées pour les modifications de secrets et de configmaps, la requête et la réponse complètes pour les changements RBAC, et les métadonnées pour toutes les autres requêtes authentifiées. Ajustez les niveaux en fonction de votre tolérance au risque et de votre budget de stockage des journaux.

Testez d'abord la politique d'audit dans un cluster de staging, puis déployez-la en production avec un pipeline d'expédition des journaux (par exemple, Fluentd vers Elasticsearch ou Loki).

Vérification et diagnostic

Une fois la surveillance de la sécurité configurée, vous devez vérifier qu'elle fonctionne comme prévu. Cette section couvre les diagnostics pratiques.

Vérification des cibles Prometheus

Si Prometheus est votre backend de métriques, commencez par confirmer que les cibles sont actives :

kubectl port-forward -n monitoring svc/prometheus-k8s 9090:9090
# Ouvrez ensuite http://localhost:9090/targets

Toutes les cibles doivent afficher l'état UP avec des barres vertes. Si une cible est hors service, vérifiez le message d'erreur et les journaux de collecte.

Validation des règles d'alerte

Utilisez promtool pour vérifier la syntaxe des règles avant de les appliquer :

promtool check rules /etc/prometheus/rules/*.yaml

Sortie attendue : Checking /etc/prometheus/rules/alerts.yaml SUCCESS pour chaque fichier.

Ensuite, dans l'interface Prometheus, allez dans Alertes et voyez si des règles sont en état inactive ou pending. Vous pouvez également utiliser le navigateur d'expressions pour simuler une condition d'alerte. Par exemple, si vous avez une alerte pour un taux de requêtes élevé du serveur d'API :

rate(apiserver_request_total{job="apiserver"}[5m]) > 100

Collez cette expression dans le navigateur et voyez si des séries apparaissent. Si aucune, soit le nom de la métrique est incorrect, soit la condition est trop stricte.

Test du routage d'Alertmanager

Créez une alerte de test et envoyez-la à Alertmanager pour confirmer les étiquettes de routage et les récepteurs :

amtool alert add alertname=TestAlert severity=critical --endpoint=localhost:9093

Vérifiez ensuite avec amtool alert query si elle a été traitée et routée. Vérifiez que le récepteur prévu (par exemple, Slack, PagerDuty) a reçu une notification.

Modes de défaillance et récupération

La surveillance de la sécurité elle-même peut échouer. Voici les modes de défaillance courants et comment s'en remettre.

Fatigue des alertes

Symptôme : trop d'alertes de faible priorité, l'équipe commence à ignorer toutes les alertes.

Récupération : examinez les règles d'alerte trimestriellement. Supprimez ou ajustez les seuils des alertes qui n'ont pas conduit à une action au cours des 90 derniers jours. Ajoutez des règles d'inhibition pour qu'une alerte de haut niveau (par exemple, cluster hors service) supprime les alertes de niveau inférieur (par exemple, pod hors service).

Journaux d'audit manquants

Symptôme : les journaux d'audit cessent d'apparaître dans votre SIEM.

Récupération : vérifiez le backend des journaux d'audit. Si vous utilisez un backend fichier, assurez-vous que la taille du fichier ne dépasse pas les limites de rotation. Si vous utilisez un backend webhook, vérifiez que le point de terminaison est accessible et ne limite pas le débit. Exécutez kubectl get --raw /healthz sur le serveur d'API pour vérifier la santé.

Disque Prometheus plein

Symptôme : Prometheus cesse d'ingérer des métriques, les règles d'alerte cessent d'être évaluées.

Récupération : augmentez la taille du disque ou la rétention, ou réduisez l'intervalle de collecte. Si le disque est plein, supprimez soigneusement les anciens blocs à l'aide des commandes promtool tsdb ou étendez le volume. Configurez des alertes pour une utilisation du disque supérieure à 80 %.

Tableau de bord Grafana cassé

Symptôme : le tableau de bord n'affiche aucune donnée ou des erreurs.

Récupération : vérifiez la configuration de la source de données dans Grafana. Vérifiez l'URL de Prometheus et les identifiants. Testez avec une requête simple comme up. Si la requête fonctionne, le problème peut venir des variables du tableau de bord ou des requêtes des panneaux.

Question rapide 2 sur 2

Le passage 1 énumère quelles activités comme étant auditées par le cluster ?

Le passage 1 indique que le cluster audite les activités générées par les utilisateurs, les applications qui utilisent l'API Kubernetes et le plan de contrôle lui-même.

Liste de contrôle des opérations

Utilisez cette liste de contrôle comme point de départ pour vos opérations de surveillance de la sécurité. Attribuez un propriétaire et une fréquence de révision pour chaque élément.

#	Élément	Propriétaire	Fréquence	Vérification
1	Examiner et mettre à jour l'inventaire des versions du cluster	Responsable plateforme (ex. Priya Shah)	Mensuelle	La sortie de `kubectl version --short` correspond à la matrice attendue dans le runbook
2	Tester les politiques réseau de refus par défaut en staging	Ingénieur réseau (ex. Alex Chen)	Après tout changement d'application ou de politique	Les tests de connectivité en staging passent sans coupures inattendues
3	Valider les règles d'alerte Prometheus	SRE de garde (ex. rotation)	Hebdomadaire	`promtool check rules` réussit, aucune alerte en cours sans runbook
4	Simuler un incident de sécurité (exercice sur table)	Ingénieur sécurité (ex. Maria Garcia)	Trimestrielle	L'équipe termine la réponse dans le SLO défini (ex. 30 min pour accuser réception)
5	Examiner les journaux d'audit pour détecter des anomalies	Analyste sécurité (ex. John Doe)	Hebdomadaire	Aucun changement RBAC ou accès aux secrets inexpliqué
6	Tester le routage d'Alertmanager vers tous les récepteurs	Responsable SRE (ex. David Kim)	Mensuelle	L'alerte de test atteint Slack, e-mail et PagerDuty
7	Vérifier que les tableaux de bord Grafana se chargent et affichent des données	Propriétaire du tableau de bord (ex. Emily Brown)	Hebdomadaire	Tous les panneaux s'affichent sans erreur, les données sont fraîches (<5 min)

Pièges courants et comment les éviter

Piège 1 : Tout collecter, alerter sur tout

Pourquoi cela arrive : la peur de manquer une attaque conduit à une collecte et des alertes excessives.

Comment éviter : commencez par les quatre signaux d'or de la sécurité : taux de requêtes du serveur d'API, taux d'erreurs, latence et saturation. Ajoutez la collecte des journaux d'audit pour RBAC et les secrets. N'alertez que sur les conditions qui nécessitent une action humaine. Pour tout le reste, créez des tableaux de bord pour un examen ultérieur.

Piège 2 : Ignorer le plan de contrôle

Pourquoi cela arrive : les services Kubernetes gérés masquent le plan de contrôle, les équipes se concentrent donc uniquement sur les charges de travail.

Comment éviter : même dans les services gérés, vous pouvez activer les journaux d'audit et les métriques pour le serveur d'API (par exemple, la journalisation du plan de contrôle EKS, la journalisation d'audit GKE). Surveillez les composants du plan de contrôle pour détecter les redémarrages inhabituels, une utilisation élevée du processeur ou l'expiration des certificats.

Piège 3 : Coder en dur les secrets dans les configurations de surveillance

Pourquoi cela arrive : les scripts de configuration rapides intègrent les identifiants pour Prometheus, Grafana ou Alertmanager.

Comment éviter : utilisez les secrets Kubernetes ou une gestion externe des secrets (par exemple, Vault). Référencez les secrets via des variables d'environnement ou des fichiers montés. Ne committez jamais de secrets dans Git.

Piège 4 : Pas de runbooks pour les alertes

Pourquoi cela arrive : les équipes configurent des alertes mais ne documentent jamais quoi faire lorsqu'elles se déclenchent.

Comment éviter : pour chaque règle d'alerte, écrivez un runbook qui comprend : ce que signifie l'alerte, comment effectuer le triage (commandes à exécuter), comment atténuer et comment vérifier la résolution. Stockez les runbooks dans le même dépôt que les définitions d'alerte.

Piège 5 : Ne pas tester la récupération

Pourquoi cela arrive : les procédures de récupération sont supposées fonctionner parce qu'elles ont été écrites une fois.

Comment éviter : planifiez des exercices réguliers. Par exemple, tuez intentionnellement un nœud, déclenchez une alerte de CPU élevé ou révoquez une autorisation RBAC, puis suivez le runbook et chronométrez la récupération. Enregistrez les lacunes et mettez à jour les runbooks.

Conclusion

La surveillance de la sécurité Kubernetes est une pratique continue. Les outils et configurations décrits ici fournissent une base, mais ils doivent être adaptés à votre environnement et à votre profil de risque. Commencez par un inventaire des versions et de l'environnement, puis mettez en œuvre des chemins de configuration sécurisés pour les politiques réseau et la journalisation d'audit, vérifiez votre pile de surveillance et préparez-vous aux modes de défaillance.

Privilégiez les alertes qui signalent un véritable incident de sécurité plutôt que le bruit informationnel. Attribuez une propriété claire pour les opérations de surveillance et examinez régulièrement votre configuration. Un cluster bien surveillé n'est pas celui avec le plus de tableaux de bord ; c'est celui où l'équipe peut rapidement détecter, comprendre et répondre aux événements de sécurité.

Comme prochaine étape, choisissez une vérification à faible risque de ce guide, comme vérifier votre politique de journalisation d'audit ou tester une politique réseau de refus par défaut dans un espace de noms de staging. Exécutez-la, enregistrez le résultat, puis développez à partir de là.