¶ Introduction
La mise en oeuvre de Wazuh, nécessite de travailler en veillant aux mesures de sécurité.
Au niveau matériel, nous retrouvons 2 serveurs physiques épaulés par 2 baies de disques.
Les serveurs sont
¶ Linux Debian
Une installation de Linux Debian est réalisée sur la machine physique. Lors de l’installation, la machine dispose de 2 grappes de disques :
- une grappe système de 278 Go montée en RAID 1
- une grappe data de 6 705 Go montée en RAID 0.
Les mots de passe utilisés pour l’accès aux modules IDRAC se trouve dans PPS
NB: lors de l’écriture de ce document, aucun stockage adapté n’était disponible, il fut donc décidé, collégialement, de démarrer temporairement sur 3 disques de 2To en RAID 0
L’installation de Debian est partie sur une installation classique, un partitionnement LVM est choisi, avec une utilisation de 128Go lors de l’installation.
Le nom de machine est répertorié dans phpIpam : ast-awz-01.pmxwaz.asten et ast-awz-01.pmxwaz.asten
Deux comptes sont créés : root et installer. Les mots de passe sont disponible sous PPS
L’attribution des adresses IP suit le schéma ci-dessous.
| Adresse | Rôle |
|---|---|
| 10.7.7.x/29 | Materiel IDRAC |
| 172.17.15.198/29 | Management Proxmox |
| 172.17.15.200/29 | Production |
NB: sur demande de la cyber, les machines ne sont pas
hardenisée, seules les étapes devant être faire lors de l’installation sont faites. Il conviendra de réaliser la mise en sécurité plus tard
¶ Hardenisation
Les systèmes de fichiers doivent être séparés, suite à l’installation classique, il est donc nécessaire de créer 3 volumes logiques : var-tmp, var-log, var-log-audit. Nous retrouvons les schéma de partition suivant:
| Device | Point de montage | options |
|---|---|---|
| /dev/mapper/ast–waz–01–vg-root | / | errors=remount-ro |
| /dev/mapper/ast–waz–01–vg-home | /home | nosuid,nodev,noexec |
| /dev/mapper/ast–waz–01–vg-tmp | /tmp | nosuid,nodev,noexec |
| /dev/mapper/ast–waz–01–vg-var | /var | nosuid,nodev,noexec |
| /dev/mapper/ast–waz–01–vg-var–tmp | /var/tmp | nosuid,nodev,noexec |
| /dev/mapper/ast–waz–01–vg-var–log | /var/log | nosuid,nodev,noexec |
| /dev/mapper/ast–waz–01–vg-var–log–audit | /var/log/audit | nosuid,nodev,noexec |
NB: lors des mises à jour système, /var doit être en
defaults
- Il faut dès lors faire un
mount /var -o remount,defaultspuis après la mise à jour- penser à refaire un
mount /var -o remount,nodev,nosuid,noexecafin de rétablir les restriction de sécurité
- Créer les logicals volumes
- Partitionner ces volumes
- modifier /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
# /boot was on /dev/sda2 during installation
UUID=32797926-41bf-4d3f-904e-9b5d8a707733 /boot ext2 defaults 0 2
# /boot/efi was on /dev/sda1 during installation
UUID=1CE4-FAB3 /boot/efi vfat umask=0077 0 1
/dev/mapper/ast--waz--01--vg-root / ext4 errors=remount-ro 0 1
/dev/mapper/ast--waz--01--vg-home /home ext4 nodev,nosuid,noexec 0 2
/dev/mapper/ast--waz--01--vg-tmp /tmp ext4 nodev,nosuid,noexec 0 2
/dev/mapper/ast--waz--01--vg-var /var ext4 nodev,nosuid,noexec 0 2
/dev/mapper/ast--waz--01--vg-var--tmp /var/tmp ext4 nodev,nosuid,noexec 0 2
/dev/mapper/ast--waz--01--vg-var--log /var/log ext4 nodev,nosuid,noexec 0 2
/dev/mapper/ast--waz--01--vg-var--log--audit /var/log/audit ext4 nodev,nosuid,noexec 0 2
/dev/mapper/ast--waz--01--vg-swap_1 none swap sw 0 0
#/dev/sr1 /media/cdrom0 udf,iso9660 user,noauto 0 0
#/dev/sr0 /media/cdrom1 udf,iso9660 user,noauto 0 0
Relancer le serveur pour prendre en compte les nouvelles partitions, puis valider :
df -h
¶ Mise à jour préliminaire
Valider le fichier /etc/apt/sources.list
# deb cdrom:[Debian GNU/Linux 12.6.0 _Bookworm_ - Official amd64 DVD Binary-1 with firmware 20240629-10:19]/ bookworm contrib main non-free-firmware
deb http://deb.debian.org/debian/ bookworm main non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm main non-free-firmware
deb http://security.debian.org/debian-security bookworm-security main non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main non-free-firmware
# bookworm-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://deb.debian.org/debian/ bookworm-updates main non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main non-free-firmware
# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.
Faire une mise à jour manuelle
apt update
apt upgrade -y
Ajouter sudo
apt install sudo
Ajouter l’utilisateur installer dans le groupe sudo
¶ Ouverture de flux
| De | Port | Vers | Rôle |
|---|---|---|---|
| Web bastion | 443 | 10.7.7.56-57 | Gestion matérielle IDRAC |
| Bastion Linux | 22 | 172.17.15.192/29 | Accès serveurs hyperviseur Proxmox |
| Web bastion | 443 | 172.17.15.192/29 | Accès interfaces web |
| 172.17.15.192/29 | dns / 53 | 10.143.1.1 10.143.2.1 | Accès DNS asten |
| 172.17.15.192/29 | ntp | 10.143.1.1 10.143.2.1 | Accès serveur de temps |
| 172.17.15.192/29 | 443 | internet | Temporaire - installation |
Cette section montre le processus d’installation, de mise à niveau et de nettoyage de Wazuh sur Kubernetes.
Dans cette section de la documentation, vous verrez comment cloner le référentiel Wazuh Kubernetes, configurer des certificats, appliquer les manifestes et déployer les pods et services nécessaires pour installer Wazuh sur Kubernetes dans les environnements cloud et locaux. De plus, vous trouverez la sous-section de configuration de Kubernetes et vous apprendrez à mettre à niveau votre implémentation dans la sous-section Mettre à niveau Wazuh installé dans Kubernetes. Enfin, vous verrez comment nettoyer les clusters et les volumes dans la sous-section Nettoyer.
¶ Pré-requis
- Un cluster
- Pour les déploiements
Amazon EKSutilisant Kubernetes version 1.23 et ultérieure, un rôle IAM de pilote Amazon EBS CSI. Le pilote CSI nécessite que vous attribuiez un rôle IAM pour fonctionner correctement. Lisez la documentation AWS pour trouver des instructions sur la création du rôle IAM du pilote Amazon EBS CSI. Vous devez installer le pilote CSI pour les déploiements nouveaux et anciens. Le pilote CSI est une fonctionnalité essentielle de Kubernetes.
Ressources :
- 2 CPU units
- 3 Gi of memory
- 2 Gi of storage
¶ StatefulSet et deployment controllers
En tant que déploiement, un StatefulSet gère des pods basés sur une spécification de conteneur identique, mais il conserve une identité attachée à chacun de ses pods. Ces pods sont créés à partir de la même spécification, mais ils ne sont pas interchangeables : chacun possède un identifiant persistant conservé lors de toute replanification.
Il est utile pour les applications avec état telles que les bases de données qui enregistrent les données sur un stockage persistant. Les états de chaque gestionnaire Wazuh et de chaque indexeur Wazuh doivent être conservés, nous les déclarons donc à l’aide de StatefulSet pour garantir qu’ils conservent leurs états à chaque démarrage.
Les déploiements sont destinés à une utilisation sans état et sont assez légers, et semblent appropriés pour le tableau de bord Wazuh, où il n’est pas nécessaire de maintenir les états.
Les volumes persistants (PV) sont des éléments de stockage dans le cluster provisionné. C’est une ressource dans le cluster, tout comme un nœud est une ressource de cluster. Les volumes persistants sont des plugins de volume comme Volumes mais ont un cycle de vie indépendant de tout pod individuel qui utilise le PV. Cet objet API capture les détails de la mise en œuvre du stockage, qu’il s’agisse de NFS, d’iSCSI ou d’un système de stockage spécifique au fournisseur de cloud.
Ici, nous utilisons des volumes persistants pour stocker les données du gestionnaire Wazuh et de l’indexeur Wazuh.
Vous pouvez vérifier comment les conteneurs Docker Wazuh sont construits dans le dépôt Wazuh.
¶ Wazuh master
Ce pod contient le nœud maître du cluster Wazuh. Le nœud maître centralise et coordonne les nœuds de travail, en garantissant que les données critiques et requises sont cohérentes sur tous les nœuds. La gestion est effectuée uniquement dans ce nœud, le service d’inscription d’agent (authd) est donc placé ici.
| Image | Controller |
|---|---|
| wazuh/wazuh-manager | StatefulSet |
¶ Wazuh worker 0 / 1
Ces pods contiennent un nœud de travail du cluster Wazuh. Ils recevront les événements de l’agent.
| Image | Controller |
|---|---|
| wazuh/wazuh-manager | StatefulSet |
¶ Wazuh indexer
Le pod de l’indexeur Wazuh ingère les événements reçus de Filebeat
| Image | Controller |
|---|---|
| wazuh/wazuh-indexer | StatefulSet |
¶ Wazuh dashboard
Le module du tableau de bord Wazuh vous permet de visualiser les données de votre indexeur Wazuh, ainsi que d’autres fonctionnalités telles que l’application Wazuh.
| Image | Controller |
|---|---|
| wazuh/wazuh-dashboard | Deployment |
¶ Services
¶ Wazuh indexer et dashboard
| Name | Description |
|---|---|
| wazuh-indexer | Communications pour les indexers |
| indexer | Il s’agit de l’API de l’indexeur Wazuh utilisée par le tableau de bord Wazuh pour lire/écrire les alertes. |
| dashboard | Service pour le dashboard. https://wazuh.your-domain.com:443 |
¶ Wazuh
| Name | Description |
|---|---|
| wazuh | Wazuh API: wazuh-master.your-domain.com:55000 |
| wazuh | Agent registration service (authd): wazuh-master.your-domain.com:1515 |
| wazuh-workers | Reporting service: wazuh-manager.your-domain.com:1514 |
| wazuh-cluster | Communication for Wazuh manager nodes. |
¶ Installation
¶ Cloner le dépot :
git clone https://github.com/wazuh/wazuh-kubernetes.git -b v4.7.4 --depth=1
cd wazuh-kubernetes
¶ Configurer les certificats SSL
Générer des certificats auto-signés pour le cluster d’indexeur Wazuh à l’aide du script disponible sur wazuh/certs/indexer_cluster/generate_certs.sh ou fournir les vôtres.
Générer des certificats auto-signés pour le cluster de tableaux de bord Wazuh à l’aide du script disponible sur wazuh/certs/dashboard_http/generate_certs.sh ou fournir les vôtres.
Les certificats requis sont importés via secretGenerator sur le fichier kustomization.yml :
secretGenerator:
- name: indexer-certs
files:
- certs/indexer_cluster/root-ca.pem
- certs/indexer_cluster/node.pem
- certs/indexer_cluster/node-key.pem
- certs/indexer_cluster/dashboard.pem
- certs/indexer_cluster/dashboard-key.pem
- certs/indexer_cluster/admin.pem
- certs/indexer_cluster/admin-key.pem
- certs/indexer_cluster/filebeat.pem
- certs/indexer_cluster/filebeat-key.pem
- name: dashboard-certs
files:
- certs/dashboard_http/cert.pem
- certs/dashboard_http/key.pem
- certs/indexer_cluster/root-ca.pem
¶ Setup storage class (optionel pour les clusters non-EKS)
Selon le type de cluster que vous exécutez, la classe de stockage peut avoir un fournisseur différent.
Vérifier les vôtres en exécutant kubectl get sc.
kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
elk-gp2 microk8s.io/hostpath Delete Immediate false 67d
microk8s-hostpath (default) microk8s.io/hostpath Delete Immediate false 54d
La colonne PROVISIONER affiche microk8s.io/hostpath, éditer le fichier envs/local-env/storage-class.yaml et configurer ce provisionneur.
¶ Appliquer tous les manifestes à l’aide de kustomize
Il existe deux variantes du manifeste : eks et local-env. Le manifeste eks doit être utilisé si vous utilisez le cluster EKS, tandis que le manifeste local-env doit être utilisé pour d’autres types de cluster.
Il est possible d’ajuster les ressources du cluster en modifiant les correctifs sur envs/eks/ ou envs/local-env/, selon le manifeste que vous souhaitez déployer. Vous pouvez régler le processeur, la mémoire ainsi que le stockage pour les volumes persistants de chacun des objets du cluster. Cela pourrait être annulé en supprimant ces correctifs de kustomization.yaml ou en modifiant les correctifs eux-mêmes avec des valeurs différentes.
Nous pouvons déployer le cluster avec une seule commande en utilisant le fichier de personnalisation :
¶ EKS cluster
kubectl apply -k envs/eks/
¶ Autres clusters
kubectl apply -k envs/local-env/
¶ Vérifications
Vérifier que le namespace existe :
kubectl get namespaces | grep wazuh
...
wazuh Active 12m
Services actifs
kubectl get services -n wazuh
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
indexer ClusterIP xxx.yy.zzz.24 <none> 9200/TCP 12m
dashboard ClusterIP xxx.yy.zzz.76 <none> 5601/TCP 11m
wazuh LoadBalancer xxx.yy.zzz.209 internal-a7a8... 1515:32623/TCP,55000:30283/TCP 9m
wazuh-cluster ClusterIP None <none> 1516/TCP 9m
Wazuh-indexer ClusterIP None <none> 9300/TCP 12m
wazuh-workers LoadBalancer xxx.yy.zzz.26 internal-a7f9... 1514:31593/TCP 9m
Deployments
kubectl get deployments -n wazuh
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
wazuh-dashboard 1 1 1 1 11m
Statefulset
kubectl get statefulsets -n wazuh
NAME READY AGE
wazuh-indexer 3/3 15m
wazuh-manager-master 1/1 15m
wazuh-manager-worker 2/2 15m
Pods
kubectl get pods -n wazuh
NAME READY STATUS RESTARTS AGE
wazuh-indexer-0 1/1 Running 0 15m
wazuh-dashboard-f4d9c7944-httsd 1/1 Running 0 14m
wazuh-manager-master-0 1/1 Running 0 12m
wazuh-manager-worker-0-0 1/1 Running 0 11m
wazuh-manager-worker-1-0 1/1 Running 0 11m
¶ Accès au dashboard
Dans le cas où vous avez créé des noms de domaine pour les services, vous devriez pouvoir accéder au tableau de bord en utilisant le nom de domaine proposé : https://wazuh.your-domain.com. Les fournisseurs de cloud fournissent généralement une adresse IP ou un nom d’hôte externe pour un accès direct au tableau de bord. Ceci peut être consulté en vérifiant les services :
kubectl get services -o wide -n wazuh
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
dashboard LoadBalancer xxx.xx.xxx.xxx xxx.xx.xxx.xxx 80:31831/TCP,443:30974/TCP 15m app=wazuh-dashboard
Optionnel: sur un lien local, il est possible d’utiliser un
port-forward:
kubectl -n wazuh port-forward --address <INTERFACE_IP_ADDRESS> service/dashboard 8443:443
Où <INTERFACE_IP_ADDRESS> est l’adresse du hôte Kubernetes
Le dashboard Wazuh est accessible sur https://<INTERFACE_IP_ADDRESS>:8443
Compte et mot de passe par défaut : admin:SecretPassword.
¶ Changement du mot de passe
Pour améliorer la sécurité, vous devez modifier le mot de passe par défaut des utilisateurs Wazuh. Il existe deux types d’utilisateurs Wazuh :
- Wazuh indexer users
- Wazuh API users
¶ Wazuh indexer users
Pour modifier le mot de passe des utilisateurs admin et kibanaserver par défaut, procédez comme suit.
Attention : Si vous avez des utilisateurs personnalisés, ajoutez-les au fichier
internal_users.yml. Dans le cas contraire, l’exécution de cette procédure les supprime.
Démarrez un shell Bash dans wazuh-indexer-0.
kubectl exec -it wazuh-indexer-0 -n wazuh -- /bin/bash
export JAVA_HOME=/usr/share/wazuh-indexer/jdk
bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/hash.sh
Copier le hash généré, puis quitter le shell.
Ouvrir le fichier wazuh/indexer_stack/wazuh-indexer/indexer_conf/internal_users.yml. Rechercher le block de l’utilisateur concerné.
Remplacer le hash.
admin user
...
admin:
hash: "$2y$12$K/SpwjtB.wOHJ/Nc6GVRDuc1h0rM1DfvziFRNPtk27P.c4yDr9njO"
reserved: true
backend_roles:
- "admin"
description: "Demo admin user"
...
kibanaserver user
...
kibanaserver:
hash: "$2a$12$4AcgAt3xwOWadA5s5blL6ev39OXDNhmOesEoo33eZtrq2N0YrU3H."
reserved: true
description: "Demo kibanaserver user"
...
¶ Changer de mot de passe
Encoder le mot de passe au format base64. Éviter d’insérer un caractère \n
# echo -n "NewPassword" | base64
Modifier le fichier de configuration des secrets de l’indexeur ou du tableau de bord comme suit.
Remplacer la valeur du champ mot de passe par votre nouveau mot de passe codé.
Pour modifier le mot de passe de l’utilisateur administrateur, modifiez le fichier wazuh/secrets/indexer-cred-secret.yaml.
...
apiVersion: v1
kind: Secret
metadata:
name: indexer-cred
data:
username: YWRtaW4= # string "admin" base64 encoded
password: U2VjcmV0UGFzc3dvcmQ= # string "SecretPassword" base64 encoded
...
To change the kibanaserver user password, edit the wazuh/secrets/dashboard-cred-secret.yaml file.
...
apiVersion: v1
kind: Secret
metadata:
name: dashboard-cred
data:
username: a2liYW5hc2VydmVy # string "kibanaserver" base64 encoded
password: a2liYW5hc2VydmVy # string "kibanaserver" base64 encoded
...
¶ Appliquer les changements
¶ EKS cluster
kubectl apply -k envs/eks/
¶ Autres clusters
kubectl apply -k envs/local-env/
Relancer un shell dans wazuh-indexer-0.
kubectl exec -it wazuh-indexer-0 -n wazuh -- /bin/bash
Positionner les variables
export INSTALLATION_DIR=/usr/share/wazuh-indexer
CACERT=$INSTALLATION_DIR/certs/root-ca.pem
KEY=$INSTALLATION_DIR/certs/admin-key.pem
CERT=$INSTALLATION_DIR/certs/admin.pem
export JAVA_HOME=/usr/share/wazuh-indexer/jdk
Attendre que l’indexeur Wazuh s’initialise correctement. Le temps d’attente peut varier de deux à cinq minutes. Cela dépend de la taille du cluster, des ressources attribuées et de la vitesse du réseau. Ensuite, exécuter le script securityadmin.sh pour appliquer toutes les modifications.
bash /usr/share/wazuh-indexer/plugins/opensearch-security/tools/securityadmin.sh -cd /usr/share/wazuh-indexer/opensearch-security/ -nhnv -cacert $CACERT -cert $CERT -key $KEY -p 9200 -icl -h $NODE_NAME
Se connecter au dashboard avec les nouveaux identifiants.
¶ Utilisateur API Wazuh
L’utilisateur wazuh-wui est l’utilisateur qui se connecte par défaut à l’API Wazuh. Suivez ces étapes pour modifier le mot de passe.
Note : Le mot de passe des utilisateurs de l’API Wazuh doit comporter entre 8 et 64 caractères. Il doit contenir au moins une lettre majuscule et une lettre minuscule, un chiffre et un symbole.
Encoder le mot de passe au format base64.
# echo -n "NewPassword" | base64
Editer le fichier wazuh/secrets/wazuh-api-cred-secret.yaml et remplacer la valeur du champs password.
apiVersion: v1
kind: Secret
metadata:
name: wazuh-api-cred
namespace: wazuh
data:
username: d2F6dWgtd3Vp # string "wazuh-wui" base64 encoded
password: UGFzc3dvcmQxMjM0LmE= # string "MyS3cr37P450r.*-" base64 encoded
Appliquer les changements
kubectl apply -k envs/eks/
Relancer les pods du Wazuh dashboardet de Wazuh manager master.
¶ Agents
Les agents Wazuh sont conçus pour surveiller les hôtes. Pour commencer à les utiliser :
¶ Installez l’agent.
Enregistrez l’agent en modifiant le fichier /var/ossec/etc/ossec.conf. Changez le « protocole de transport » en TCP et remplacez MANAGER_IP par l’adresse IP externe du service pointant vers le port 1514 ou par le nom d’hôte fourni par le fournisseur de cloud.
Pour en savoir plus sur l’enregistrement des agents, consultez la section Inscription des agents Wazuh de la documentation.
¶ Mise à jour
Fichiers exportés dans les volumes
Le déploiement Kubernetes utilise les images Wazuh de Docker. Si nous examinons le code suivant extrait de la configuration Wazuh à l’aide de Docker, nous pouvons voir quels répertoires et fichiers sont utilisés dans la mise à niveau.
/var/ossec/api/configuration
/var/ossec/etc
/var/ossec/logs
/var/ossec/queue
/var/ossec/var/multigroups
/var/ossec/integrations
/var/ossec/active-response/bin
/var/ossec/agentless
/var/ossec/wodles
/etc/filebeat
/var/lib/filebeat
/usr/share/wazuh-dashboard/config/
/usr/share/wazuh-dashboard/certs/
/var/lib/wazuh-indexer
/usr/share/wazuh-indexer/certs/
/usr/share/wazuh-indexer/opensearch.yml
/usr/share/wazuh-indexer/opensearch-security/internal_users.yml
Toute modification liée à ces fichiers sera également effectuée dans le volume associé. Lorsque le pod de réplique est créé, il récupère ces fichiers du volume, en conservant les modifications précédentes.
¶ Configuration de la mise à niveau
Pour passer à la version x.y, vous pouvez suivre l’une des deux stratégies suivantes.
Utilisation des manifestes par défaut : Cette stratégie utilise les manifestes par défaut pour Wazuh x.y. Il remplace les manifestes wazuh-kubernetes de votre version de Wazuh.
Conserver les manifestes personnalisés : cette stratégie préserve les manifestes wazuh-kubernetes de votre déploiement Wazuh. Il ignore les manifestes de la dernière version de Wazuh.
¶ Utilisation des manifestes par défaut
Découvrez la balise pour la version actuelle de wazuh-kubernetes :
git checkout vx.y.z
puis appliquer pour la mise à jour
¶ Conserver les manifestes personnalisés
Note : Dans Wazuh 4.4, certains chemins étaient différents de ceux des versions précédentes. > Vous devez mettre à jour les anciens chemins avec les nouveaux si vous conservez vos manifestes personnalisés.
Cette partie doit être adaptée à votre configuration.
mv /usr/share/wazuh-dashboard/config/certs/ -> /usr/share/wazuh-dashboard/certs/
mv /usr/share/wazuh-indexer/config/certs/ -> /usr/share/wazuh-indexer/certs/
mv /usr/share/wazuh-indexer/plugins/opensearch-security/securityconfig/ -> /usr/share/wazuh-indexer/opensearch-security/
...
…
¶ Appliquer la nouvelle version
La dernière étape consiste à appliquer les changements :
¶ EKS cluster
kubectl apply -k envs/eks/
Autres clusters
kubectl apply -k envs/local-env/
statefulset.apps "wazuh-manager-master" configured
Ce processus mettra fin à l’ancien pod tout en en créant un nouveau avec la nouvelle version, lié au même volume. Une fois les Pods démarrés, la mise à jour sera prête et nous pourrons vérifier la nouvelle version de Wazuh installée, le cluster et les modifications qui ont été maintenues grâce à l’utilisation des volumes.
¶ Suppression
Étapes pour effectuer un nettoyage complet de tous les déploiements, services et volumes.
¶ Supprimer le cluster
Le déploiement du cluster de gestionnaires Wazuh implique l’utilisation de différents éléments StatefulSet ainsi que de cartes et de services de configuration.
Pour supprimer votre cluster Wazuh, exécutez simplement la commande suivante à partir de ce répertoire de référentiel.
¶ EKS cluster
kubectl delete -k envs/eks/
¶ Autre cluster
kubectl delete -k envs/local-env/
Cela supprimera toutes les ressources définies dans le fichier kustomization.yml.
¶ Supprimer les volumes persistents
kubectl get persistentvolume
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-024466da-f7c5-11e8-b9b8-022ada63b4ac 10Gi RWO Retain Released wazuh/wazuh-manager-worker-wazuh-manager-worker-1-0 gp2-encrypted-retained 6d
pvc-b3226ad3-f7c4-11e8-b9b8-022ada63b4ac 30Gi RWO Retain Bound wazuh/wazuh-indexer-wazuh-indexer-0 gp2-encrypted-retained 6d
pvc-fb821971-f7c4-11e8-b9b8-022ada63b4ac 10Gi RWO Retain Released wazuh/wazuh-manager-master-wazuh-manager-master-0 gp2-encrypted-retained 6d
pvc-ffe7bf66-f7c4-11e8-b9b8-022ada63b4ac 10Gi RWO Retain Released wazuh/wazuh-manager-worker-wazuh-manager-worker-0-0 gp2-encrypted-retained 6d
kubectl delete persistentvolume pvc-b3226ad3-f7c4-11e8-b9b8-022ada63b4ac ...
Attention : N’oubliez pas de supprimer les volumes manuellement si nécessaire.