blabla

étude_wazuh.md

@@ -1,4 +1,4 @@
-# Wazuh
+# Étude Wazuh
 
 ## But
 
@@ -29,10 +29,10 @@ L'audit de l'apiserver a plusieurs objectifs :
 ### Solutions explorées
 
 2 solutions ont été explorées :
-1. Installer sur chaque noeud le client wazuh et créer un objet k8s de type audit policy ;
+1. Installer sur chaque noeud VCP l'agent wazuh et créer un objet k8s de type audit policy ;
 2. Installer sur le serveur wazuh un listener et créer un objet k8s de type audit policy.
 
-La solution 1 n'est pas envisageable, les noeuds étant immutables.
+La solution 1 n'est pas envisageable, les noeuds étant immutables. Un contournement serait de déployer un pod avec l'agent Wazuh dedans et de lui donner accès aux ressources nécessaire pour interroger l'apiserver ou recevoir des données.
 
 Après recherches et discussion sur le slack de Wazuh, il semblerait qu'aucun agent wazuh ne supporte un environnement k8s et que la solution 2 soit la meilleure solution.
 
@@ -397,7 +397,7 @@ kind create cluster --config wazuh.yaml
 Comme indiqué en introduction, cette méthode permet de recevoir dans Wazuh toutes les activités passant par l'apiserver. Cependant :
 - il faut prendre en compte une augmentation de la consommation mémoire sur les controle-plane ;
 - il faut customizer audit-policy.yaml afin de filtrer les appels à l'apiserver réellement important et éviter de se retrouver avec trop de logs ;
-- il faut trouver un moyen de filtrer par cluster (prod et pp)
+- il faut trouver un moyen de filtrer par cluster (prod et pp).
 
 > The audit logging feature increases the memory consumption of the API server because some context required for auditing is stored for each request. Memory consumption depends on the audit logging configuration.
 
@@ -409,7 +409,7 @@ Pour le moment, cette source de log est mise de coté.
 
 D'après la documentation [kubernetes](https://kubernetes.io/docs/concepts/cluster-administration/logging/#cluster-level-logging-architectures), la meilleure solution dans notre cas est d'installer un DaemonSet dans le cluster ayant accès au dossier /var/log/pods.
 
-C'est ce qui a été fait et mis en place. Les détails de cette solution sont dans la documentation "Wazuh".
+Cette solution a été testée et mise en place. Les détails de cette solution sont dans la documentation "Wazuh".
 
 ### DaemonSet
 
@@ -468,6 +468,12 @@ GET /agents/003/stats/logcollector
 These are useful to confirm whether Wazuh is actively reading and processing the logs as expected. For more details: https://documentation.wazuh.com/current/user-manual/reference/statistics-files/wazuh-logcollector-state.htmlLet me know if you need help with testing or creating rules.
 ```
 
+Les logs ne sont donc pas stockés sur le serveur par défaut (et la doc Wazuh déconseille de stocker les logs).
+
+### Plugin pour Docker
+
+Il existe un "plugin" (ou "wodle") pour Docker ajoutable à la configuration des agents. La [documentation](https://documentation.wazuh.com/current/proof-of-concept-guide/monitoring-docker.html) semble prometteuse. Cependant, cette piste n'a pas été explorée pour le moment, en particulier parce que son installation nécessite un redémarrage de Docker et un accès depuis le pod wazuh-agent à des fichiers non clairement identifiés dans la documentation.
+
 ### Gestion coté serveur
 
 Coté serveur, les logs passent dans des décodeurs puis dans des règles.