Audit Logs : Suivre les actions sur l'API Server

Voir et savoir : l'importance de la traçabilité

Dans un système aussi dynamique et centralisé que Kubernetes, où toutes les actions de gestion passent par l'API Server, il est fondamental de disposer d'un enregistrement fiable de qui a fait quoi, sur quelle ressource, et quand. C'est précisément le rôle des Logs d'Audit (Audit Logs). Ils fournissent un historique chronologique détaillé des requêtes reçues par l'API Server, offrant une visibilité cruciale pour la sécurité, le dépannage, et la conformité.

Les logs d'audit sont essentiels pour répondre à des questions comme : Qui a supprimé ce Namespace critique ? Quand ce Secret a-t-il été modifié ? Quel ServiceAccount a tenté d'accéder à une ressource non autorisée ? Sans audit, il est extrêmement difficile, voire impossible, de détecter des activités suspectes, d'investiguer des incidents de sécurité, de comprendre les changements de configuration inattendus, ou de prouver la conformité à des réglementations.

Activer et configurer correctement les logs d'audit est donc une composante non négociable d'une stratégie de sécurité Kubernetes robuste. Ils constituent les "yeux" qui surveillent l'activité au coeur du control plane.

Fonctionnement : de la requête à l'enregistrement

Le mécanisme d'audit est intégré à l'API Server. Lorsqu'une requête arrive, elle passe par plusieurs étapes (stages), notamment avant et après les contrôles d'authentification et d'autorisation, et avant et après la persistance dans etcd. A différentes étapes de ce cycle, l'API Server peut générer un événement d'audit.

La décision de générer un événement et le niveau de détail à inclure sont déterminés par une Politique d'Audit (Audit Policy). C'est un fichier (généralement YAML ou JSON) fourni à l'API Server lors de son démarrage (via le flag --audit-policy-file), qui définit des règles précises sur les requêtes à auditer.

Une fois qu'un événement d'audit est généré selon la politique, il est envoyé à un ou plusieurs backends d'audit configurés. Les backends sont les destinations où les logs d'audit sont effectivement stockés ou transmis. Les options courantes incluent l'écriture dans un fichier local sur le noeud de l'API Server ou l'envoi via un webhook à un système externe de collecte de logs.

La Politique d'Audit : définir quoi et comment auditer

La politique d'audit est le coeur de la configuration. Elle est constituée d'une liste de règles (rules) évaluées dans l'ordre. La première règle qui correspond à une requête détermine le niveau d'audit (level) à appliquer pour cette requête.

Chaque règle peut spécifier des critères de correspondance basés sur :

• Les users, groups ou serviceAccounts à l'origine de la requête.
• Les verbs (actions comme `get`, `delete`, `patch`).
• Les resources (type d'objet comme `pods`, `secrets`) et leurs subresources (ex: `status`, `log`).
• Les namespaces ciblés.
• Les nonResourceURLs pour les requêtes ne ciblant pas des objets API spécifiques (ex: `/healthz`, `/metrics`).

Les niveaux d'audit possibles pour une règle sont :

• None : Ne pas enregistrer cet événement. Utile pour exclure le trafic bruyant ou non pertinent (ex: requêtes de health checks par le Kubelet sur lui-même).
• Metadata : Enregistrer uniquement les métadonnées de la requête (qui l'a faite, quand, quelle ressource/verbe, IP source, etc.), mais pas le corps de la requête ni celui de la réponse. C'est un bon niveau par défaut pour avoir une vue d'ensemble sans stocker de données potentiellement sensibles.
• Request : Enregistrer les métadonnées et le corps de la requête. Utile pour voir ce qui a été soumis lors d'une création ou d'une mise à jour, mais attention à la taille des logs et aux données sensibles potentielles dans les requêtes.
• RequestResponse : Le niveau le plus verbeux. Enregistre les métadonnées, le corps de la requête et le corps de la réponse. Fournit le plus de détails mais génère le plus de logs et présente le plus grand risque d'enregistrer des données sensibles (contenu des Secrets, etc.). A utiliser avec parcimonie pour des opérations très spécifiques ou pour le débogage.

Exemple de politique d'audit :

apiVersion: audit.k8s.io/v1 # Utilisez la version API appropriée
kind: Policy
# Ne pas logger les requêtes du système kubelet ou system:node
# (souvent très volumineuses et moins critiques pour l'audit de sécurité utilisateur)
omitStages:
  - "RequestReceived"
rules:
  # Logger les modifications sur les secrets au niveau RequestResponse
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["secrets"]
    verbs: ["create", "update", "patch", "delete"]

  # Logger les accès en lecture aux secrets au niveau Metadata
  - level: Metadata
    resources:
    - group: ""
      resources: ["secrets"]
    verbs: ["get", "list", "watch"]

  # Logger les modifications de configmaps au niveau Request
  - level: Request
    resources:
    - group: ""
      resources: ["configmaps"]
    verbs: ["create", "update", "patch"]

  # Logger les modifications RBAC au niveau RequestResponse
  - level: RequestResponse
    resources:
    - group: "rbac.authorization.k8s.io"
      resources: ["roles", "clusterroles", "rolebindings", "clusterrolebindings"]

  # Ne pas logger les requêtes /healthz, /version, /metrics
  - level: None
    nonResourceURLs:
    - "/healthz*"
    - "/version"
    - "/metrics*"

  # Ne pas logger les status updates par les kubelets
  - level: None
    users: ["system:kubelet"]
    verbs: ["update", "patch"]
    resources:
    - group: ""
      resources: ["nodes/status", "pods/status"]

  # Ne pas logger les requêtes du service account du HPA
  - level: None
    users: ["system:serviceaccount:kube-system:horizontal-pod-autoscaler"]

  # Pour toutes les autres requêtes authentifiées, logger les métadonnées.
  - level: Metadata
    omitStages:
      - "RequestReceived"

Backends d'Audit : où envoyer les logs ?

Une fois la politique définie, l'API Server doit savoir où envoyer les événements générés. Deux backends principaux sont supportés :

• Log Backend : Ecrit les événements d'audit dans un fichier sur le disque local du noeud où s'exécute l'API Server. C'est la configuration la plus simple. Elle est activée via des flags comme :
  • --audit-log-path=/var/log/kubernetes/audit.log : Chemin du fichier log.
  • --audit-log-maxage=30 : Durée maximale (en jours) de conservation des anciens fichiers logs.
  • --audit-log-maxbackup=10 : Nombre maximal d'anciens fichiers logs à conserver.
  • --audit-log-maxsize=100 : Taille maximale (en mégaoctets) avant rotation du fichier log.
  Il est crucial d'avoir un agent de collecte de logs (comme Fluentd, Filebeat) sur les noeuds maîtres pour récupérer ces fichiers et les envoyer vers un système de stockage et d'analyse centralisé. La gestion de l'espace disque et de la rotation est importante.
• Webhook Backend : Envoie les événements d'audit via des requêtes HTTP(S) POST à un ou plusieurs serveurs webhooks externes. C'est la méthode préférée pour une intégration directe avec des systèmes SIEM (Security Information and Event Management) ou des plateformes de log centralisées (Elasticsearch, Splunk, etc.). La configuration se fait via un fichier (référencé par --audit-webhook-config-file) qui spécifie l'URL du webhook, le mode d'envoi, etc.
  • Le mode batch (recommandé) met en mémoire tampon les événements et les envoie par lots pour de meilleures performances.
  • Le mode blocking envoie chaque événement individuellement et attend la réponse, ce qui peut ralentir l'API Server si le webhook est lent.
  La sécurisation de la connexion au webhook (TLS, authentification) est essentielle.

Il est possible de configurer plusieurs backends (par exemple, écrire dans un fichier local ET envoyer à un webhook) pour la redondance ou des besoins différents.

Exploiter les Logs d'Audit : sécurité, conformité et dépannage

Une fois collectés et centralisés, les logs d'audit deviennent une mine d'informations pour :

• Détection d'intrusion : Rechercher des patterns suspects comme des tentatives répétées d'accès non autorisé, la création de Pods privilégiés inattendus, la modification de rôles critiques, etc. Mettre en place des alertes sur ces événements.
• Investigation post-incident (Forensics) : Reconstituer la séquence des actions ayant mené à un incident de sécurité ou à une mauvaise configuration.
• Conformité réglementaire : Fournir la preuve que les accès et les modifications sont tracés, ce qui est souvent une exigence pour des normes comme PCI-DSS, HIPAA, ou SOC2.
• Dépannage : Comprendre qui a modifié une ressource spécifique ayant causé un problème.
• Analyse de comportement : Observer comment les utilisateurs et les systèmes interagissent avec l'API.

L'analyse efficace des logs d'audit nécessite des outils appropriés (plateforme de logs avec capacités de recherche, d'agrégation et d'alerte) et une définition claire de ce qui constitue une activité normale vs suspecte pour votre environnement.

En conclusion, les logs d'audit sont une composante indispensable de la sécurité et de l'opérabilité de Kubernetes. Leur configuration réfléchie, associée à une collecte et une analyse centralisées, fournit une visibilité essentielle pour protéger votre cluster, répondre aux exigences de conformité et investiguer efficacement les problèmes.