Je suis en train de travailler sur le déploiement d'un infra IA FOSS avec les composants suivants :

• openwebui
• dockling
• litellm
• ollama
  l'idée est de déployer tout ça à la demande sur une instance GPU pour économiser des coûts de fonctionnement d'une instance qui serait pas utilisée la nuit et le week-end par exemple, j'y reviendrais.

Dans cet article j'explique donc comment connecter Hermes à cette infra sans passer par openwebui mais en passant directement par litellm.

 On commence par se créer une clé

Cette clé va permettre de s'authentifier sur litellm :

export LITELLM_MASTER_KEY="sk-*******"
export LITELLM_URL="llmurl"

HERMES_KEY=$(curl -s https://$LITELLM_URL/key/generate \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" -H "Content-Type: application/json" \
  -d '{"key_alias":"hermes","max_budget":20}' \
  | jq -r '.key')

echo $HERMES_KEY

 On configure hermes

hermes config set model.provider custom
hermes config set model.base_url https://$LITELLM_URL/v1
hermes config set model.api_key "$HERMES_KEY"
hermes config set model.default qwen3:8b

 Affecter le modèle par défaut à tous les profiles

mkdir -p /etc/hermes

On crée un fichier /etc/hermes/config.yaml :

providers:
  litellm:
    api: https://$LITELLM_URL/v1
    key_env: LITELLM_API_KEY
    transport: chat_completions
    models:
      qwen3:8b:
        context_length: 65536
      mistral-small3.2:
        context_length: 65536

model:
  provider: custom:litellm
  base_url: https://$LITELLM_URL/v1

Mettre à jour les droits :

chmod 0755 /etc/hermes 
chmod 0644 /etc/hermes/config.yaml

Fixer la clé pour le profil par défaut et les autres :

hermes config set LITELLM_API_KEY $HERMES_KEY
hermes -p <profil> config set LITELLM_API_KEY $HERMES_KEY

Vérifier une config d'un profil :

hermes -p metalomane config

 Un petit test depuis Hermes

On passes de 15mn à 1m pour à peut près la même requête, c'est mieux.

Je préfère le résultat avec Mistral Small

L’article Connecter Hermes à LiteLLM est apparu en premier sur Aukfood.

NetBird est un VPN mesh open source basé sur WireGuard, que l’on peut héberger soi-même. Chez AUKFOOD, on l’a déployé pour remplacer Headscale et mieux contrôler qui accède à quoi.

Dans notre comparatif Headscale – Pangolin, Headscale ressortait pourtant comme le bon outil pour relier des sites. Cependant, une limite a pris le dessus à l’usage. Il n’a pas d’interface web officielle, et les règles d’accès s’écrivent à la main dans un fichier.

Dans cet article, on installe donc NetBird pas à pas. D’abord le manager, ensuite les agents sur Centreon et quatre routeurs, puis le routage des VLAN et l’isolation des flux. Chaque étape donne les commandes à lancer et les pièges rencontrés.

« Monter un VPN mesh, c’est rapide. Savoir exactement qui peut joindre quoi, c’est tout le travail. »

Pourquoi passer de Headscale à NetBird ?

NetBird repose sur la même base que Headscale : des tunnels WireGuard directs entre machines, coordonnés par un serveur auto-hébergé. En revanche, la gestion des accès change complètement.

Besoin	Headscale	NetBird
Interface d’administration	Ligne de commande, pas d’interface officielle	Dashboard web intégré
Règles d’accès	Fichier de policy à écrire à la main	Policies par groupe, dans le dashboard
Exposer un VLAN	Subnet router à annoncer puis approuver	Networks + routing peers
Conditions sur l’appareil	—	Posture checks (version, pays, OS…)
Comptes utilisateurs	OIDC externe ou clés	Fournisseur d’identité embarqué

L’architecture mise en place

Le manager NetBird tourne sur une VM avec IP publique. Il ne transporte pas le trafic. En effet, il distribue seulement les clés, les routes et les règles. Ensuite, les machines se parlent en direct.

Manager NetBird

netbird.example.com · TCP 443 + UDP 3478

↑ coordination : clés, routes et policies (control plane)

Peers enrôlés · mesh 100.78.0.0/16

centreon

supervision · accès aux 5 VLAN

Poste utilisateur

groupe acces-vlan-clients · 1 VLAN

Routing peers · Proxmox chez DENVR

rtr-admin

VLAN 211 + 212

rtr-aukfood

VLAN 213

rtr-docker

VLAN 215

rtr-clients

VLAN 217

↔ tunnels WireGuard directs entre les machines (data plane)

Prérequis pour installer NetBird

D’après la documentation officielle, les besoins restent modestes :

Élément	Valeur
Système	Debian 13 (tout Linux récent convient)
Ressources	1 vCPU, 2 Go de RAM
DNS	Un enregistrement A vers l’IP publique de la VM
Ports	TCP 80 et 443, UDP 3478
Logiciels	Docker + Compose, jq, curl

Plage d’adresses

NetBird attribue au mesh une plage dans 100.64.0.0/10, chez nous 100.78.0.0/16. Vérifiez qu’elle ne recoupe pas Headscale ou le VPN de votre hébergeur.

1Déployer le manager NetBird

Installer Docker

D’abord, on installe Docker et on ajoute son utilisateur au groupe docker :

VM managerbash

curl -fsSL https://get.docker.com | sudo shsudo usermod -aG docker $USER

Ouvrir les ports NetBird dans Shorewall

Shorewall protège notre VM, avec une politique DROP par défaut. On ajoute donc une section NetBird dans le fichier des règles :

/etc/shorewall/rulesshorewall

# NetBirdACCEPT net $FW tcp 80,443ACCEPT net $FW udp 3478

Ensuite, on sauvegarde, on vérifie, puis on recharge :

VM managerbash

sudo cp /etc/shorewall/rules /etc/shorewall/rules.bak-$(date +%Y%m%d)sudo shorewall check && sudo shorewall reload

Retour terrain

Un shorewall reload efface les chaînes iptables créées par Docker (DOCKER-*). Résultat : les conteneurs ne répondent plus. C’est le même mécanisme que dans CrowdSec + Shorewall. Vérifiez donc que DOCKER=Yes figure dans /etc/shorewall/shorewall.conf. Puis relancez Docker après chaque rechargement : sudo systemctl restart docker.

Lancer l’installeur NetBird

Le script officiel déploie tout en Docker. Il installe le serveur NetBird, le dashboard, un Traefik avec certificat Let’s Encrypt et le fournisseur d’identité embarqué. Il demande d’abord le domaine, puis le reverse proxy : tapez 0 pour le Traefik intégré.

VM managerbash

curl -fsSL https://github.com/netbirdio/netbird/releases/latest/download/getting-started.sh | bash

Retour terrain

L’installeur génère le certificat et toute la configuration pour le domaine saisi. Un mauvais nom oblige donc à tout démonter (docker compose down --volumes), puis à recommencer. Vérifiez-le avant de lancer.

Créer le premier compte NetBird

On ouvre ensuite https://netbird.example.com et on arrive sur la page /setup. Cette page disparaît dès qu’un compte existe. Le premier compte devient donc propriétaire (Owner) de l’instance.

Vérification

docker ps doit montrer trois conteneurs en Up : Traefik, le serveur NetBird et le dashboard. Enfin, le dashboard s’affiche en HTTPS avec un certificat valide.

2Enrôler les serveurs et les routeurs

Les serveurs s’enrôlent avec une setup key : pas de compte, pas de navigateur, une seule commande par machine. Pour la créer, ouvrez le menu Setup Keys du dashboard. Choisissez une clé réutilisable, limitée au nombre de machines, avec une expiration courte.

Ensuite, sur Centreon et sur chaque routeur :

centreon + chaque routeurbash

curl -fsSL https://pkgs.netbird.io/install.sh | sudo shsudo netbird up --management-url https://netbird.example.com --setup-key <VOTRE_SETUP_KEY>

Sans --management-url, l’agent cherche le cloud NetBird au lieu de votre instance.

vérificationbash

$ netbird statusManagement: Connected to https://netbird.example.com:443Signal: Connected to https://netbird.example.com:443NetBird IP: 100.78.215.253/16

Bonne pratique

Une fois toutes les machines enrôlées, révoquez la setup key. En effet, une clé réutilisable qui traîne permet d’ajouter n’importe quelle machine à votre réseau.

3Déclarer NetBird dans le pare-feu des peers

C’est le piège qui nous a coûté le plus de temps. Toutes nos machines apparaissaient dans le manager, mais aucun tunnel ne montait entre elles :

centreonsymptôme

$ netbird status -d rtr-admin.netbird.selfhosted: Status: Idle Last WireGuard handshake: - Transfer: 0 B/0 BPeers count: 0/4 Connected

La cause se trouvait sur chaque machine. En effet, Shorewall ne connaissait pas wt0, l’interface de NetBird. Or une interface rattachée à aucune zone reste fermée : Shorewall jetait donc les paquets du mesh.

Cas 1 : une zone VPN existe déjà

Si Headscale tourne déjà, la zone vpn existe. Une seule ligne suffit alors, et wt0 hérite des droits de cette zone.

/etc/shorewall/interfacesshorewall

#ZONE INTERFACEvpn tailscale0vpn wt0

Cas 2 : aucune zone VPN

Dans ce cas, on crée la zone, on y rattache wt0, puis on définit ce qu’elle peut joindre. Voici un exemple minimal pour un routeur placé devant un VLAN (zone lan). Les règles de policy se placent avant la ligne net all DROP :

zones · interfaces · policyshorewall

# /etc/shorewall/zonesvpn ipv4# /etc/shorewall/interfacesvpn wt0# /etc/shorewall/policy$FW vpn ACCEPTvpn $FW ACCEPTvpn lan ACCEPT

Appliquer la configuration sans risque

chaque peerbash

sudo cp /etc/shorewall/interfaces /etc/shorewall/interfaces.bak-$(date +%Y%m%d)sudo shorewall checksudo shorewall safe-reload

safe-reload applique la configuration, puis demande confirmation. Sans réponse, il revient seul à l’ancienne version. Ainsi, impossible de se couper l’accès par erreur.

4Router les VLAN avec NetBird

Un routeur équipé de l’agent suffit pour exposer tout un VLAN. Les VM derrière lui n’ont donc rien à installer. Notre règle : un routeur = un network, avec une resource par VLAN qu’il dessert.

Notion	Ce que c’est	Chez nous
Network	Les réseaux joignables par un même routeur	VLAN - Clients
Resource	Un sous-réseau, une IP ou un domaine	192.168.17.0/24
Routing peer	La machine qui fait passer le trafic	rtr-clients
Policy	Qui a le droit de joindre la resource	centreon → VLAN-Clients-217

Dans le dashboard, ouvrez Network Routing → Networks :

1. Add Network : un nom et une description qui cite le routeur.
2. Add Resource : le CIDR du VLAN.
3. Onglet Access Control : la policy, avec en source la machine ou le groupe autorisé.
4. Add Routing Peer : le routeur, avec Masquerade activé. Ainsi, les VM répondent au routeur sans route supplémentaire.

centreonvérification

$ ip route get 192.168.12.10192.168.12.10 dev wt0 table netbird src 100.78.215.253$ ping -c 3 192.168.12.1064 bytes from 192.168.12.10: icmp_seq=1 ttl=63 time=51.6 ms3 packets transmitted, 3 received, 0% packet loss

Ce qu’il faut lire

La route sort par wt0, dans la table netbird. De plus, le ttl=63 montre qu’un seul routeur sépare Centreon de la VM. Attention : le premier paquet peut arriver en retard, voire se perdre, le temps que le tunnel se monte.

5Isoler les flux avec les policies NetBird

Tant que la policy Default reste active, l’isolation n’existe pas. En effet, elle autorise toutes les machines à se joindre, sur tous les ports.

Désactiver Default et passer par des groupes

1. Dans Access Control → Policies, désactivez Default sans la supprimer : vous pourrez ainsi revenir en arrière. Centreon garde ses VLAN grâce à ses propres policies.
2. Dans Team → Users, ajoutez à l’utilisateur le groupe acces-vlan-clients. NetBird l’attribue ensuite à chaque appareil qu’il connecte.
3. Enfin, créez la policy : groupe acces-vlan-clients → resource VLAN-Clients-217.

Connecter un poste utilisateur à NetBird

Sans setup key, l’agent ouvre une page de connexion dans le navigateur :

poste utilisateurbash

netbird up --management-url https://netbird.example.com

Tester l’isolation avant et après

Pour le test, on a utilisé un compte jetable, sur un laptop sans aucun autre VPN :

Cible depuis le poste	Avec Default	Sans Default
VM du VLAN 217 (autorisé)	joignable	joignable
VM du VLAN 211	bloquée	bloquée
Centreon	joignable	bloqué
Un autre routeur	joignable	bloqué
Le routeur du VLAN 217 lui-même	—	bloqué

poste utilisateursans Default

$ ip route get 192.168.11.33192.168.11.33 via 192.168.10.254 dev wlp5s0 # pas de route NetBird$ ping -c 2 100.78.215.253ping: sendmsg: Clé requise non disponible # "Required key not available"$ netbird status | grep PeersPeers count: 0/1 Connected # seul rtr-clients est connu

Au final, l’isolation repose sur trois mécanismes :

Couche 1

Pas de route

Un réseau non autorisé n’apparaît pas dans la table de routage. Le paquet part donc par la box.

Couche 2

Pas de clé

Une machine non autorisée manque dans la config WireGuard. Le paquet ne quitte même pas le poste.

Couche 3

Filtrage au routeur

Le routeur refuse ce qui le vise lui-même, même dans le /24 autorisé.

6Exiger un client NetBird à jour

Un posture check ajoute une condition sur l’appareil, en plus de la policy. NetBird en propose cinq types :

On a choisi NetBird Client Version, avec un minimum 0.80.0, puis on l’a attaché à la policy des utilisateurs. Pour le tester, on a ensuite rétrogradé l’agent du poste de test :

poste de test (Debian / Ubuntu / Mint)bash

sudo apt install -y --allow-downgrades netbird=0.79.0 netbird-ui=0.79.0sudo apt-mark hold netbird netbird-ui # bloque la mise à jour pendant le test

Client 0.79.0

sans posture check

accès OK

→

Check ≥ 0.80.0

plus de route ni de peer

accès coupé

→

Client 0.80.0

aucune action côté dashboard

accès rétabli

Le poste non conforme reste connecté au manager. Cependant, il n’obtient plus rien de la policy. Puis il retrouve l’accès tout seul dès sa mise à jour. Pensez enfin à lancer apt-mark unhold après le test.

Cohabiter avec Headscale pendant la migration

Les routes NetBird passent devant Headscale

NetBird installe ses routes dans sa propre table, prioritaire. Or on a créé notre première route avant que les tunnels fonctionnent. Centreon a alors perdu un serveur, jusqu’à ce qu’on désactive la policy. Validez donc un ping entre adresses mesh avant de créer une route. Ensuite, regardez votre supervision.

Un tunnel NetBird peut passer par Headscale

Sur un routeur, netbird status -d montrait un candidat distant prflx sur son adresse Headscale. Autrement dit, le tunnel NetBird circulait dans le tunnel Headscale. Ce chemin disparaîtra avec Headscale : revérifiez-le au moment de le retirer.

Le mode lazy et la supervision

NetBird ne monte un tunnel qu’au premier paquet, puis le referme s’il reste inactif. Or le remontage nous a coûté de 300 ms à 6 secondes. Pour un serveur de supervision, c’est donc un risque de fausses alertes.

Ce que NetBird n’isole pas

NetBird contrôle qui atteint quoi depuis son appareil. En revanche, il ne contrôle pas ce qui se passe une fois arrivé. Par exemple, un utilisateur avec un shell SSH sur une VM peut rebondir vers ses voisines du même VLAN.

• Ouvrir le port de l’application plutôt que SSH, vers une resource par machine (/32).
• Passer les accès SSH par un bastion comme Teleport : rôles par serveur, sessions enregistrées.
• Cloisonner les VM : un VLAN par client, ou le pare-feu Proxmox sur chaque VM.

Conclusion : ce que NetBird nous apporte

Étape	Ce qu’on a validé
Manager	Stack auto-hébergée, certificat valide, comptes locaux
Peers	Centreon et 4 routeurs enrôlés, tunnels directs après déclaration de wt0
Routage	5 VLAN supervisés à travers le mesh
Isolation	Un utilisateur ne voit que son VLAN, ni Centreon ni les routeurs
Posture check	Accès coupé, puis rétabli selon la version du client

Avec Headscale, il fallait écrire les règles à la main. Avec NetBird, on donne à chacun exactement l’accès dont il a besoin, depuis une interface. Prochaine étape pour nous : migrer les derniers accès, puis retirer Headscale.

L’article NetBird : déployer un VPN mesh et isoler ses VLAN est apparu en premier sur Aukfood.

 Isolement

Pour le moment je prends pas le risque de déployer sur ma machine du quotidiens, je préfère cloisonner dans une VM, je pars donc sur une VM Debian 13 basisque.

 Installation

L'installation peut-se faire de différentes façon :

• en local
• en conteneurs

Ma première installation à été fait en local avec la commande suivante :

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash 

Définir un provider

On peut définir un provider par profile :

hermes -p aukfood model

Par exemple pour Claude il faut créer une clé d'api (et bien sûr payer en plus).

 Provider local

Pour mes premiers test je vais utiliser un llm local, j'installe donc déjà Ollama pour gérer les llms.

curl -fsSL https://ollama.com/install.sh | sh

Je charge le modèle :

ollama pull qwen3:1.7b

Hermes demande au minimum 64K tokens, or Ollama sert de base :

qwen3:1.7b
context window = 40960
Hermes minimum = 64000
``` 

Il faut modifier le démarrage de Ollama :
```bash
systemctl edit ollama

Ajoute :

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=65536"

Puis :

systemctl daemon-reload
systemctl restart ollama

 Définition du provider pour Hermes

On configure un provider par défaut :

hermes model

Choisir "Custom endpoint" et suivre les questions :

Custom OpenAI-compatible endpoint configuration:

API base URL [e.g. https://api.example.com/v1]: http://127.0.0.1:11434
API key [optional]: 

  Hint: Did you mean to add /v1 at the end?
  Most local model servers (Ollama, vLLM, llama.cpp) require it.
  e.g. http://127.0.0.1:11434/v1
  Add /v1? [Y/n]: 
  Updated URL: http://127.0.0.1:11434/v1

Verified endpoint via http://127.0.0.1:11434/v1/models (1 model(s) visible)

Select API compatibility mode:
  1. Auto-detect [current]
     Use Hermes URL heuristics; best for standard OpenAI-compatible endpoints.
  2. Chat Completions
     Use /chat/completions for standard OpenAI-compatible servers.
  3. Responses / Codex
     Use /responses for Codex-compatible tool-calling backends.
  4. Anthropic Messages
     Use /v1/messages for Anthropic-compatible endpoints.
Choice [1-4, Enter to keep current/detected]: 1
  API mode: auto-detect
  Detected model: qwen3:1.7b
  Use this model? [Y/n]: y
Context length in tokens [leave blank for auto-detect]:
Display name [Local (127.0.0.1:11434)]: Ollama Local
  Context length auto-detected: 41K tokens
Default model set to: qwen3:1.7b (via http://127.0.0.1:11434/v1)
  💾 Saved to custom providers as "Ollama Local" (edit in config.yaml)

Et adapter le contexte pour le modèle

hermes config set model.ollama_num_ctx 64000

 Création de profiles

J'ai plusieurs casquettes et j'aimerais pouvoir utiliser un agent pour mes différents environnements de travail : aukfood, zythometal, metalomane, personnel, je crée donc les profiles :

hermes profile create aukfood
hermes profile create zythometal
hermes profile create guillaume
hermes profile create metalomane
hermes profile list

 Le dashboard

Plusieurs solutions pour utiliser Hermes, la première est locale en lançant un tchat :

metalomane chat

Il est aussi possible de l'intégrer avec Open Web Ui on verra plus tard et là on va déclencher le dashboard pour accéder à Hermes depuis mon poste de travail :

hermes dashboard --host 0.0.0.0 --port 9119 --no-open &

Il va vous demander de mettre en place une authentification :

  How do you want to authenticate the dashboard?
    [1] Username & password (quickest; for a trusted LAN / VPN)
    [2] OAuth via Nous Portal (run `hermes dashboard register`)
    [3] Cancel

Vu que je suis en local sur ma machine je vais prendre le choix 1 Jean-Pierre.

Ce qui donne ceci :

Bon en local c'est pas très performant :

L’article Premiers pas avec Hermes et LLM en local est apparu en premier sur Aukfood.

 Prérequis

Cet article suppose que vous ayez les informations nécessaires sur

• longhorn
• alloy et mimir sur un cluster kubernetes

 Les métriques de longhorn

Longhorn expose ses métriques Prometheus, directement depuis le service longhorn-backend dans le namespace longhorn-system, sur le port manager (9500) : Longhorn expose des métriques sur http://longhorn-backend.longhorn-system.svc.cluster.local:9500/metrics. Ça couvre la santé des volumes, statut des replicas, backups, capacité par nœud.

ConfigMap

On rajoute dans le configmap de alloy les paramètres pour le scrapping des données

discovery.kubernetes "longhorn" {
  role = "endpoints"

  namespaces {
    names = ["longhorn-system"]
  }

  selectors {
    role  = "endpoints"
    label = "app=longhorn-manager"
  }
}

prometheus.scrape "longhorn" {
  targets         = discovery.kubernetes.longhorn.targets
  forward_to      = [prometheus.remote_write.mimir.receiver]
  scrape_interval = "30s"
  job_name        = "integrations/longhorn"
}

On met à jour Alloy :

helm upgrade alloy grafana/alloy -n monitoring -f alloy-values.yaml

 Le Dashboard

Le dashboard officiel Longhorn (maintenu par l'équipe SUSE/Longhorn) est le "Longhorn" — ID 16888 sur grafana.com. Il couvre : santé des volumes (healthy/degraded/faulted), capacité disque par nœud, I/O des volumes, statut des backups.

C'est fini

L’article Les métriques de Longhorn dans Grafana est apparu en premier sur Aukfood.

L'installation de Mimir va être effectuée sur le même serveur que Grafana et Prometheus, de la même façon on va mettre en place une authentification basic_auth et un certificat TLS.

Je vous renvoi vers les articles précédents sur le blog sur Grafana Alloy pour les métriques et les logs.

 Mimir

Mimir, c'est le backend de stockage long terme pour métriques Prometheus développé par Grafana dans la suite LGTM.

La page officielle de Grafana.

 Mise en place de Mimir

Installation des paquets

apt install mimir

Le fichier de configuration /etc/mimir/config.yml pour une configuration locale simple :

target: all
multitenancy_enabled: false

server:
  http_listen_address: 127.0.0.1
  http_listen_port: 9009
  grpc_listen_address: 127.0.0.1
  grpc_listen_port: 9095
  log_level: info

memberlist:
  bind_addr: ["127.0.0.1"]
  advertise_addr: "127.0.0.1"

common:
  storage:
    backend: filesystem
    filesystem:
      dir: /var/lib/mimir/data

blocks_storage:
  filesystem:
    dir: /var/lib/mimir/blocks
  bucket_store:
    sync_dir: /var/lib/mimir/tsdb-sync

compactor:
  data_dir: /var/lib/mimir/compactor
  compaction_interval: 30m
  sharding_ring:
    instance_addr: 127.0.0.1

ruler_storage:
  filesystem:
    dir: /var/lib/mimir/ruler

ruler:
  ring:
    instance_addr: 127.0.0.1

ingester:
  ring:
    instance_addr: 127.0.0.1
    replication_factor: 1

distributor:
  ring:
    instance_addr: 127.0.0.1

querier:
  ring:
    instance_addr: 127.0.0.1

query_scheduler:
  ring:
    instance_addr: 127.0.0.1

frontend:
  address: 127.0.0.1

alertmanager:
  sharding_ring:
    instance_addr: 127.0.0.1

store_gateway:
  sharding_ring:
    instance_addr: 127.0.0.1
    replication_factor: 1

Mimir étant disponible sur le port 9009 pour la production on mettra une authentification basic auth et un certificat TLS.

 Déploiement de alloy sur Kubernetes

Je me base sur l'infrastructure Kubernetes mise en place dans les articles précédents.

Création du namespace et du secret secret

kubectl create namespace monitoring
kubectl create secret generic mimir-basic-auth -n monitoring --from-literal=password='**************'

 Fichier pour helm

Fichier alloy-values.yml pour configurer le chart Helm de Alloy :

# alloy-values.yaml

controller:
  type: daemonset
  hostPID: true
  tolerations:
    - key: node-role.kubernetes.io/control-plane
      effect: NoSchedule
      operator: Exists
  volumes:
    extra:
      - name: rootfs
        hostPath:
          path: /
      - name: procfs
        hostPath:
          path: /proc
      - name: sysfs
        hostPath:
          path: /sys
      - name: mimir-secret
        secret:
          secretName: mimir-basic-auth
          items:
            - key: password
              path: mimir-password

alloy:
  extraEnv:
    - name: NODE_NAME
      valueFrom:
        fieldRef:
          fieldPath: spec.nodeName

  mounts:
    extra:
      - name: rootfs
        mountPath: /host/root
        readOnly: true
      - name: procfs
        mountPath: /host/proc
        readOnly: true
      - name: sysfs
        mountPath: /host/sys
        readOnly: true
      - name: mimir-secret
        mountPath: /etc/alloy/secrets
        readOnly: true

  configMap:
    content: |-
      prometheus.exporter.unix "nodes" {
        rootfs_path = "/host/root"
        procfs_path = "/host/proc"
        sysfs_path  = "/host/sys"
        include_exporter_metrics = true
      }

      discovery.relabel "nodes" {
        targets = prometheus.exporter.unix.nodes.targets

        rule {
          target_label = "instance"
          replacement  = sys.env("NODE_NAME")
        }
      }

      prometheus.scrape "nodes" {
        targets         = discovery.relabel.nodes.output
        forward_to      = [prometheus.remote_write.mimir.receiver]
        scrape_interval = "30s"
        job_name        = "integrations/node_exporter"
      }

      prometheus.remote_write "mimir" {
        endpoint {
          url = "https://url_mimir/api/v1/push"

          basic_auth {
            username      = "myuser"
            password_file = "/etc/alloy/secrets/mimir-password"
          }
        }
      }

 Déploiement de alloy

On déploie maintenant alloy avec Helm :

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update
helm install alloy grafana/alloy -n monitoring -f alloy-values.yaml

Dashboard

On peut utiliser le dashboard habituel de Node Exporter. On dois alors paramétrer les dashboard pour chaque noeuds.

 Kube State Metrics

Allons plus loin en remontant les métriques de l'api Kubernetes, pour cela on va devoir installer kube-state-metrics, rajouter un export pour alloy vers mimir et créer un nouveau tableau de bord.

 Mise en place de kube-state-metrics

On déploie ksm avec Heml :

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
helm install kube-state-metrics prometheus-community/kube-state-metrics -n monitoring

 On modifie le configmap

Dans le fichier alloy-values.yml on rajoute les infos suivantes dans la partie configmap

discovery.kubernetes "ksm" {
  role = "endpoints"

  namespaces {
    names = ["monitoring"]
  }

  selectors {
    role  = "endpoints"
    label = "app.kubernetes.io/name=kube-state-metrics"
  }
}

prometheus.scrape "ksm" {
  targets         = discovery.kubernetes.ksm.targets
  forward_to      = [prometheus.remote_write.mimir.receiver]
  scrape_interval = "30s"
  job_name        = "integrations/kubernetes/kube-state-metrics"
}

Et on met à jour alloy

helm upgrade alloy grafana/alloy -n monitoring -f alloy-values.yaml

 Le dashboard

J'ai installé [ce dashboard ](https://grafana.com/grafana/dashboards/15757-kubernetes-views-global/"ce dashboard ")pour avoir une visualisation des informations de Kubernetes.

 Conclusion

Comme pour les installations sur vm la configuration d'Alloy se fait très bien sur un cluster Kubernetes et tout remonte dans Mimir.

L’article Observabilité k8s : de Alloy à Mimir est apparu en premier sur Aukfood.

On attaque dans cet article une modernisation de cet article et la mise en place sur mon k8s on-pemise.

Pour cet article je vous conseille d'écouter le groupe "buffalo_farm"

 Les prérequis.

• cluster kubeadm Debian 13
• 3 nodes
• 1 disque dédié de 100 Go par node (/dev/sdb).
• Stack ingress : Traefik (Gateway API) + cert-manager + MetalLB, voir article de mise en place
• Exposition de l'UI : HTTPS (Let's Encrypt HTTP-01) + authentification basique.

Préparation sur chaque node

Paquets à installer

apt install -y open-iscsi nfs-common cryptsetup jq apache2-utils
systemctl enable --now iscsid

Préparation du disque dédié

mkfs.ext4 /dev/sdb
mkdir -p /var/lib/longhorn-disk
echo '/dev/sdb /var/lib/longhorn-disk ext4 defaults 0 2' >> /etc/fstab
systemctl daemon-reload
mount -a

Installation de Longhorn (Helm)

helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --set defaultSettings.defaultDataPath="/var/lib/longhorn-disk" \
  --set persistence.defaultClassReplicaCount=3

Vérifications

kubectl -n longhorn-system get pods
kubectl get storageclass

Tous les pods doivent passer Running, et la StorageClass longhorn doit apparaître (par défaut).

Test de la StorageClass

Fichier test-storage.yml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: test-longhorn
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: longhorn
  resources:
    requests:
      storage: 2Gi

Le PVC doit passer Bound, et le volume apparaît dans l'UI avec 3 réplicas (1 par node).

Exposition de l'UI Longhorn (HTTPS + basic auth)

Secret d'authentification

htpasswd -nb admin 'CHANGER_MOI' > auth
kubectl -n longhorn-system create secret generic longhorn-basic-auth --from-file=users=auth
rm auth

Middleware Traefik (basic auth)

Fichier traefik-auth-longhorn.yml :

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: longhorn-auth
  namespace: longhorn-system
spec:
  basicAuth:
    secret: longhorn-basic-auth
    removeHeader: true

kubectl apply -f traefik-auth-longhorn.yml

Certificat TLS (HTTP-01)

Fichier cert-longhorn-ui.yml :

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: longhorn-tls
  namespace: traefik            # namespace de la Gateway
spec:
  secretName: longhorn-tls
  issuerRef:
    name: letsencrypt-prod      # ClusterIssuer HTTP-01 existant
    kind: ClusterIssuer
  dnsNames:
    - url-longhorn

kubectl apply -f cert-longhorn-ui.yml
kubectl -n traefik get certificate longhorn-tls    # attendre Ready=True

Mise à jour de la Gateway

Fichier application-gateway.yml

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: traefik
spec:
  gatewayClassName: traefik
  listeners:
    - name: web
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
    - name: websecure
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: placeholder-tls
            namespace: traefik
    # UI Longhorn
    - name: https-longhorn
      hostname: url-longhorn
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: longhorn-tls
            namespace: traefik

kubectl apply -f application-gateway.yml

HTTPRoute avec le middleware

Fichier longhorn-httproute.yml :

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: longhorn-ui
  namespace: longhorn-system
spec:
  parentRefs:
    - name: main-gateway
      namespace: traefik
      sectionName: https-longhorn
  hostnames:
    - url-longhorn
  rules:
    - filters:
        - type: ExtensionRef
          extensionRef:
            group: traefik.io
            kind: Middleware
            name: longhorn-auth
      backendRefs:
        - name: longhorn-frontend
          port: 80

kubectl apply -f longhorn-httproute.yml

Vérifications finales

kubectl -n traefik get gateway main-gateway \
  -o jsonpath='{range .status.listeners[*]}{.name}{"\t"}{.attachedRoutes}{"\t"}{.conditions[?(@.type=="Programmed")].status}{"\n"}{end}'

kubectl -n longhorn-system get httproute longhorn-ui -o yaml | grep -A3 'type: Accepted'

kubectl -n traefik get certificate longhorn-tls

Tests HTTP

curl -I https://url-longhorn                    
# 401 attendu (auth active)
curl -I -u admin:LE_MOT_DE_PASSE https://url-longhorn  
# 200 attendu

 Backups S3

Mettre en place les credentials S3, fichier s3-backup-cred.yml

apiVersion: v1
kind: Secret
metadata:
  name: s3-backup-credentials
  namespace: longhorn-system
type: Opaque
stringData:
  AWS_ACCESS_KEY_ID: "TON_ACCESS_KEY"
  AWS_SECRET_ACCESS_KEY: "TA_SECRET_KEY"
  AWS_ENDPOINTS: "https://s3.ton-provider.fr" 

kubectl apply -f s3-backup-cred.yml

Le backup target s3-backup-target.yaml

apiVersion: longhorn.io/v1beta2
kind: BackupTarget
metadata:
  name: default
  namespace: longhorn-system
spec:
  backupTargetURL: "s3://longhorn-backups@eu-west-1/"
  credentialSecret: "s3-backup-credentials"
  pollInterval: "5m0s"

kubectl apply -f s3-backup-target.yaml 

Mise en place du cron s3-recurring.yml

apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: backup-daily
  namespace: longhorn-system
spec:
  cron: "0 2 * * *"          # tous les jours à 2h
  task: "backup"
  groups:
    - default                 # s'applique à tous les volumes du groupe default
  retain: 14                  # garde 14 backups
  concurrency: 1              # 1 volume à la fois (ménage le réseau/S3)
  labels:
    cluster: k8s-denvr
---
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: snapshot-6h
  namespace: longhorn-system
spec:
  cron: "0 */6 * * *"         # snapshot local toutes les 6h
  task: "snapshot"
  groups:
    - default
  retain: 4
  concurrency: 2

L’article Stockage persistant sur un kubernetes on-premise est apparu en premier sur Aukfood.

Je vous présente mon idée d'infrastructure, j'ai une ip publique avec une vm qui fait office de protection en amont du cluster et de proxy avec haproxy.

Un petit schéma de mon objectif final, dans cet article on ne parlera que de la partie laisons http/https :

Avant de commencer je préviens c'est assez long, je vous conseille en fond sonore un morceau de Dream Theater - A change of Seasons qui dure 25 minutes

 Prérequis

Les prérequis sont les suivants

• cluster kubernetes
• kubectl utilisable
• helm en place

 La configuration HaProxy

Haproxy va recevoir les requêtes sur les ports 80 et 443 et les forwardé niveau TCP à l'IP qui sera affectée par le load balancer. Voir mes articles précédents sur HaProxy.

Configuration d'exemple :

...
frontend kube-http
  bind *:80
  default_backend kube-http-backend

frontend kube-https
  bind *:443
  default_backend kube-https-backend

backend kube-api-backend
  mode tcp
  server cp01 192.168.15.11:6443 check

backend kube-https-backend
  mode tcp
  option tcp-check
  timeout check 2s
  server traefik 192.168.15.100:443 send-proxy-v2 check inter 3s fall 2 rise 2

backend kube-http-backend
    mode tcp
    option tcp-check
    timeout check 2s
    server traefik 192.168.15.100:80 send-proxy-v2 check inter 3s fall 2 rise 2

Mise en place des CRDs gateway api :

Mettre en place les CRD gateway api :

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml

Pour vérifier :

kubectl get crd |grep gateway

 Mise en place de MetalLB

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.9/config/manifests/metallb-native.yaml

Vérifier que ça démarre :

kubectl get pods -n metallb-system -w

Fichier metallb.yml avec l'affectation de la plage d'ips LB

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: local-pool
  namespace: metallb-system
spec:
  addresses:
    - 192.168.15.100-192.168.15.110
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2adv
  namespace: metallb-system
spec:
  ipAddressPools:
    - local-pool

Déploiement et vérification

kubectl apply -f metallb.yml 
kubectl get ipaddresspool -n metallb-system

 Mise en place de Traefik

 Repos helm

helm repo add traefik https://traefik.github.io/charts
helm repo update

Configuration de Traefik

Fichier values-traefik.yaml

deployment:
  kind: Deployment
  replicas: 3

gateway:
  enabled: false

providers:
  kubernetesGateway:
    enabled: true
  kubernetesIngress:
    enabled: true

ingressClass:
  enabled: true
  isDefaultClass: true

service:
  type: LoadBalancer
  annotations:
    metallb.universe.tf/address-pool: local-pool

ports:
  traefik:
    port: 9000
    protocol: TCP
  web:
    port: 80
    exposedPort: 80
    protocol: TCP
    proxyProtocol:
      trustedIPs:
        - "192.168.15.0/24"
    forwardedHeaders:
      trustedIPs:
        - "192.168.15.0/24"
  websecure:
    port: 443
    exposedPort: 443
    protocol: TCP
    proxyProtocol:
      trustedIPs:
        - "192.168.15.0/24"
    forwardedHeaders:
      trustedIPs:
        - "192.168.15.0/24"
  metrics:
    port: 9100
    protocol: TCP

additionalArguments:
  - "--providers.kubernetesgateway.entrypoints=web,websecure"

logs:
  general:
    level: INFO
  access:
    enabled: true

Installation

helm install traefik traefik/traefik -n traefik --create-namespace -f values-traefik.yaml

 Vérification

Une ip doit être affectée pour le load balancer :

kubectl get svc -n traefik

 Mise en place cert-manager

Installation

helm repo add jetstack https://charts.jetstack.io
helm repo update

helm install cert-manager jetstack/cert-manager -n cert-manager --create-namespace --set crds.enabled=true

ClusterIssuer Let's Encrypt

Fichier clusterissuer.yaml :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: toi@exemple.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            ingressClassName: traefik

kubectl apply -f clusterissuer.yaml
kubectl get clusterissuer

 Resources gateway et gatewayclass

Mettre en place les ressources suivantes certificat par défaut, gateway et gateway class, fichier gateway.yml

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: traefik-default-tls
  namespace: traefik
spec:
  secretName: placeholder-tls
  issuerRef:
    name: selfsigned
    kind: ClusterIssuer
  dnsNames:
    - mondomaine.com
---
apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: traefik
spec:
  gatewayClassName: traefik
  listeners:
    - name: web
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
    - name: websecure
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: placeholder-tls
            namespace: traefik

kubectl apply -f gateway.yaml

Vérifications :

kubectl get certificate -n traefik
kubectl get gateway main-gateway -n traefik

Les deux doivent être Ready: True et PROGRAMMED: True

 Application de test

 Déployer ghost

Fichier ghost.yml :

apiVersion: v1
kind: Namespace
metadata:
  name: ghost
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ghost
  namespace: ghost
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ghost
  template:
    metadata:
      labels:
        app: ghost
    spec:
      containers:
        - name: ghost
          image: ghost:latest
          env:
            - name: url
              value: "https://ghost.mondomaine.com"
            - name: database__client
              value: sqlite3
            - name: database__connection__filename
              value: /var/lib/ghost/content/data/ghost.db
          ports:
            - containerPort: 2368
          volumeMounts:
            - name: ghost-data
              mountPath: /var/lib/ghost/content
      volumes:
        - name: ghost-data
          emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: ghost
  namespace: ghost
spec:
  selector:
    app: ghost
  ports:
    - port: 80
      targetPort: 2368
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ghost-tls
  namespace: ghost
spec:
  secretName: ghost-tls
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  dnsNames:
    - ghost.mondomaine.com
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: traefik-tls-access
  namespace: ghost
spec:
  from:
    - group: gateway.networking.k8s.io
      kind: Gateway
      namespace: traefik
  to:
    - group: ""
      kind: Secret
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: ghost
  namespace: ghost
spec:
  parentRefs:
    - name: main-gateway
      namespace: traefik
      sectionName: websecure
  hostnames:
    - "ghost.mondomaine.com"
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /
      backendRefs:
        - name: ghost
          port: 80

Le application-gateway.yml correspondant :

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: traefik
spec:
  controllerName: traefik.io/gateway-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: traefik
spec:
  gatewayClassName: traefik
  listeners:
    - name: web
      port: 80
      protocol: HTTP
      allowedRoutes:
        namespaces:
          from: All
    - name: websecure
      port: 443
      protocol: HTTPS
      allowedRoutes:
        namespaces:
          from: All
      tls:
        mode: Terminate
        certificateRefs:
          - kind: Secret
            name: placeholder-tls
            namespace: traefik
         - kind: Secret
            name: ghost-tls  
            namespace: ghost

C'est pas simple tout ça mais ça fonctionne.

La suite sera de mettre en place Longhorn pour le stockage persistant sur cette infra.

L’article Traefik derrière HaProxy sur une infra managée est apparu en premier sur Aukfood.

Maquette Proxmox multi-cluster : retour d’expérience R&D autour de Headscale, PDM et PBS

Pendant mon stage d’Administrateur d’Infrastructures Sécurisées chez AUKFOOD, j’ai monté une maquette R&D Proxmox multi-cluster, hébergée dans le datacenter DENVR à Nantes. L’objectif n’était pas de livrer une production, mais de découvrir, tester et documenter plusieurs outils utiles dans un contexte d’infogérance Proxmox : Headscale, Proxmox Datacenter Manager et Proxmox Backup Server.

Ce projet n’avait pas vocation à produire une architecture finale clé en main. Sa valeur vient surtout de la démarche : construire un environnement de test, réaliser des validations concrètes, identifier les limites et documenter ce qui pourrait être réutilisable plus tard.

« Une maquette ne sert pas à prouver que ça marche en production — elle sert à savoir ce qui mérite d’aller plus loin. »

Pourquoi une maquette multi-cluster ?

En infogérance, gérer plusieurs clusters Proxmox devient vite pénible : interfaces multiples, sauvegardes éparpillées, visibilité partielle, accès distants à sécuriser. Pour tester des solutions sans mobiliser plusieurs serveurs physiques, j’ai utilisé la virtualisation nested — du Proxmox dans du Proxmox — afin de simuler deux clusters indépendants sur le même socle.

Le tout a été déployé dans un VLAN de test unique (le VLAN 213). C’est une contrainte de laboratoire : en production, on segmenterait proprement (administration, sauvegarde, supervision, production…). Cette contrainte a aussi un intérêt : comme toutes les machines partageaient déjà le même VLAN, il fallait prouver que Headscale transportait réellement du trafic, et pas seulement de la configuration déclarative.

L’architecture, simplement

Un cluster physique pve-denvr (Proxmox VE 9.1.9, Ceph HEALTH_OK) héberge quatre VM de service et deux clusters Proxmox imbriqués de trois nœuds chacun.

Cluster physique — pve-denvr · DENVR Nantes

Proxmox VE 9.1.9 · 3 nœuds · Ceph HEALTH_OK · stockage partagé ceph-store

Services transverses · VLAN 213 (192.168.13.0/24)

vm-NAT

bastion d’accès

vm-headscale

plan de contrôle overlay

vm-pdm

centralisation

vm-pbs

sauvegarde

cluster-A · 3 nœuds

192.168.13.101–103 · overlay 100.64.0.2–4

pve-a1

pve-a2

pve-a3

cluster-B · 3 nœuds

192.168.13.201–203 · overlay 100.64.0.5–7

pve-b1

pve-b2

pve-b3

Overlay Headscale (WireGuard) · 100.64.0.0/24 — adressage stable entre tous les nœuds

Headscale : valider le flux overlay

Headscale est un serveur de contrôle auto-hébergé compatible Tailscale/WireGuard. Son rôle n’est pas de faire transiter tout le trafic : il coordonne les nœuds et distribue les clés, puis les machines communiquent directement entre elles en WireGuard. Dans la maquette, chaque nœud reçoit une IP overlay en 100.64.0.x.

Headscale

plan de contrôle · distribue les clés

↑ coordination & échange des clés (control plane)

Cluster Proxmox A

pve-a1 / a2 / a3

Poste admin

accès via bastion

Cluster Proxmox B

pve-b1 / b2 / b3

↔ trafic direct WireGuard entre les machines (data plane)

Le point clé de la validation : prouver que l’overlay est réellement emprunté. Depuis vm-pdm (100.64.0.8), un ping vers pve-b1 (100.64.0.5) a été lancé pendant une capture tcpdump sur l’interface tailscale0.

nate@vm-pdm:~$ ping -c 4 100.64.0.5
64 bytes from 100.64.0.5: icmp_seq=1 ttl=64 time=0.917 ms
--- 100.64.0.5 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss

nate@vm-pdm:~$ tcpdump -ni tailscale0 'icmp and host 100.64.0.5'
IP 100.64.0.8 > 100.64.0.5: ICMP echo request
IP 100.64.0.5 > 100.64.0.8: ICMP echo reply
…
8 packets captured · 8 received by filter · 0 dropped by kernel

PDM : centraliser la visibilité

Proxmox Datacenter Manager (PDM 1.0.3) ne remplace pas l’administration de chaque cluster. Il apporte une vue consolidée : état des remotes, nœuds, VM, tâches, et même le serveur de sauvegarde. Dans la maquette, les remotes ont été déclarés sur les adresses overlay 100.64.0.x — ce qui reste cohérent avec la preuve réseau précédente.

Là où il fallait sinon ouvrir trois interfaces séparées, PDM voit d’un coup cluster-A, cluster-B et le serveur PBS. Pour une société d’infogérance, c’est exactement le genre de gain de temps recherché.

PBS : sauvegarder et restaurer

Proxmox Backup Server (PBS 4.2.0) est la brique la plus concrète du projet. Le datastore datastore-maquette héberge la sauvegarde de la VM de test et affiche un bon facteur de déduplication.

Le principe que je voulais surtout vérifier : une sauvegarde « OK » ne vaut rien tant qu’on n’a pas testé la restauration. La sauvegarde vm/1001 a donc été restaurée vers une nouvelle VM (1099), sans écraser l’originale.

Backup vm/1001

datastore-maquette · vérifié OK

→

Restauration

vers local-lvm, sans écrasement

→

VM 1099

visible dans cluster-A · TASK OK

La restauration s’est terminée avec succès et la VM est réapparue dans le cluster. C’est cette étape qui transforme une sauvegarde théorique en sauvegarde réellement exploitable.

Une limite de dimensionnement repérée au passage. Une première migration entre nœuds nested a échoué (No space left on device) : le stockage local du nœud cible était trop juste pour copier le disque. Rien à voir avec le réseau ou Headscale — juste un rappel que les migrations sur stockage local dépendent fortement de la capacité disponible.

Limites et trajectoire production

La maquette valide des usages, pas une production. Avant toute industrialisation, plusieurs points seraient à renforcer :

• Réseau : remplacer le VLAN unique par une vraie segmentation (administration, sauvegarde, supervision, production).
• Accès : durcir l’exposition de PDM (bastion/VPN, MFA, comptes dédiés, journalisation).
• Sauvegarde : activer le chiffrement PBS, définir rétention et réplication hors site, viser une stratégie 3-2-1 avec tests réguliers de restauration.
• Supervision : PDM donne une visibilité, mais ne remplace pas une supervision dédiée.

Conclusion

Outil	Ce qui a été validé	Pour AUKFOOD
Headscale	Flux overlay prouvé via tcpdump	Interconnexion / multi-sites
PDM	Vue centralisée multi-cluster	Visibilité, à surveiller
PBS	Sauvegarde + restauration réelle	Candidat prioritaire

Headscale s’est montré pertinent pour l’interconnexion et le réseau overlay, PDM pour la visibilité multi-cluster, et PBS pour la sauvegarde/restauration. La maquette a permis de valider ces usages dans un cadre de laboratoire, tout en identifiant les points à renforcer avant toute trajectoire de production.

L’article R&D PDM, PBS, Headscale est apparu en premier sur Aukfood.

Securite OpenSource

Par Killian Prin-Abeil - Aukfood
⭐ Wazuh Ambassador

Wazuh est au coeur de notre stack SOC open source. On l'utilise au quotidien pour surveiller nos endpoints, centraliser nos logs, gerer la conformite. Mais une question simple restait sans reponse simple : qui peut faire quoi, sur quoi, dans notre deploiement Wazuh ? WazuhHound est ne de cette question.

13 types de noeuds

21 types de relations

50 requêtes Cypher incluses

MIT open source

Le problème : Wazuh répond aux questions, pas aux relations

On utilise Wazuh depuis un moment. On connaît bien l'API, on sait chercher un agent, lister des groupes, inspecter des permissions. Mais à un moment, face à une question d'audit interne - qui a réellement accès à quoi dans notre déploiement ? - on a réalisé que l'API ne répondait pas à ce type de question. Pas parce qu'elle manque de données, mais parce qu'elle ne pense pas en termes de relations entre ces données.

Un utilisateur a des rôles. Un rôle a des politiques. Une politique a des actions sur des ressources. Des agents sont dans des groupes, gérés par un cluster, connectés à un noeud. Tout ça existe dans l'API - mais éparpillé sur des dizaines d'endpoints, sans vue d'ensemble. Pour comprendre le chemin complet, il fallait croiser les réponses à la main. Pas scalable, pas auditabie, pas visualisable.

La question qu'on s'est posée : et si on traitait l'infrastructure Wazuh comme un graphe ?

BloodHound CE comme moteur de cartographie

BloodHound est un outil bien connu dans la communaute securite - initialement concu pour cartographier les relations dans Active Directory. Mais son moteur - un graphe Neo4j requetable en Cypher, avec une interface visuelle - est exactement ce dont on avait besoin pour Wazuh.

BloodHound CE (Community Edition) supporte les extensions OpenGraph : des schemas personnalises qui permettent de definir ses propres types de noeuds et de relations, completement independants d'Active Directory. On a concu WazuhHound comme une extension native de cette architecture.

Le principe : collecter l'ensemble des donnees Wazuh via l'API, les transformer en graphe OpenGraph, et les injecter dans BloodHound CE pour les explorer visuellement et les interroger en Cypher.

Ce que WazuhHound cartographie

WazuhHound definit 12 types de noeuds qui couvrent l'integralite d'un deploiement Wazuh :

Infrastructure WZ_Cluster WZ_ClusterNode WZ_IndexerCluster WZ_IndexerNode

Agents et reseau WZ_Agent WZ_AgentGroup WZ_NetworkSegment

Securite RBAC + Indexer WZ_User WZ_Role WZ_Policy WZ_IndexerUser WZ_IndexerRole WZ_RoleMapping

Chaque noeud est enrichi avec les proprietes collectees depuis l'API : statut, version, IP, configuration RBAC, scores de vulnerabilite, ports en ecoute, nombre de packages installes. Les 19 types de relations permettent d'interroger le graphe avec precision - et les 48 requetes Cypher pre-integrees couvrent les cas d'usage les plus courants.

Les permissions RBAC visualisees comme un graphe

La partie la plus utile au quotidien, c'est la cartographie RBAC. Wazuh utilise un modele Utilisateurs -> Roles -> Politiques. Chaque politique definit des actions et des ressources. WazuhHound traduit ce modele en edges traversables dans BloodHound CE - ce qui permet de visualiser d'un coup d'oeil qui a acces a quoi, et via quel chemin.

Une requete simple pour voir le chemin complet de permissions depuis les utilisateurs :

-- Chemin complet : utilisateur -> role -> politique -> ressource
MATCH p=(u:WZ_User)
  -[:WZ_HasRole]->(:WZ_Role)
  -[:WZ_HasPolicy]->(:WZ_Policy)
  -[:WZ_CanControlAgent|WZ_CanManageSecurity]->()
RETURN p ORDER BY u.name

L'indexer OpenSearch aussi est cartographie

WazuhHound ne se limite pas au manager Wazuh. Avec le parametre --indexer-url, il interroge directement l'API OpenSearch Security pour collecter les utilisateurs internes, les roles, et leurs mappings. Les droits de lecture et d'ecriture sur les index de logs sont modelises comme des edges traversables dans le graphe.

Enrichissement des agents

Chaque agent est enrichi en parallele avec les donnees syscollector :

• Vulnerabilites : comptages critical/high/medium depuis l'index OpenSearch wazuh-states-vulnerabilities-* ou l'API legacy Wazuh <= 4.7
• Score de risque 0-10 : calcule automatiquement a partir des CVE, du statut de l'agent, et d'heuristiques de version OS
• Ports en ecoute : services exposes sur chaque agent via syscollector/ports
• Packages installes : nombre de packages pour evaluer la surface exposee
• Segments reseau : sous-reseaux derives depuis syscollector/netaddr, avec identification des agents multi-homes

-- Agents avec les scores de risque les plus eleves
MATCH (a:WZ_Agent)
WHERE a.risk_score >= 5
RETURN a.name, a.vuln_critical, a.vuln_high, a.risk_score
ORDER BY a.risk_score DESC

name             vuln_critical   vuln_high   risk_score
srv-prod-02      4               7           8.7
desktop-rh-01    2               3           6.1
laptop-dev-03    1               2           5.3

Installation en 3 etapes

# 1. Cloner et installer
$ git clone https://github.com/0xbbuddha/WazuhHound.git
cd WazuhHound && pip install -e .

# 2. Uploader le schema dans BloodHound CE (une seule fois)
$ python3 helper-scripts/upload_schema.py \
  --url http://localhost:8080 \
  --username admin --secret "$BH_SECRET"
python3 helper-scripts/upload_custom_icons.py \
  --url http://localhost:8080 \
  --username admin --secret "$BH_SECRET"
python3 helper-scripts/upload_saved_queries.py \
  --url http://localhost:8080 \
  --username admin --secret "$BH_SECRET"

# 3. Lancer la collecte
$ wazuhhound \
  --wazuh-url https://wazuh:55000 \
  --wazuh-user admin --wazuh-password secret \
  --indexer-url https://wazuh:9200 \
  --output ./output --insecure

[+] Collected:
    Agents   : 29
    Groups   : 13
    Cluster  : wazuh-manager (1 node(s), standalone)
    Indexer  : wazuh-cluster (2 node(s))
    Users    : 6 (manager API)
    Segments : 4 network segment(s)
    Vulns    : 8 agent(s) with vulnerabilities
[+] OpenGraph exported:
    Nodes : 87
    Edges : 214
    File  : ./output/wazuhhound_20260529143201.json

Pourquoi Python ?

🐍 Ecosysteme Wazuh Python est le langage de l'ecosysteme Wazuh. Les outils, les scripts d'integration, les exemples de documentation - tout est en Python.

📦 bhopengraph La librairie BloodHound OpenGraph est disponible en Python et gere nativement le format d'export compatible BloodHound CE.

🔧 Extensible Ajouter un nouveau type de noeud ou une nouvelle source d'enrichissement prend quelques lignes. Pas de compilation, pas de toolchain.

Compatibilite : WazuhHound fonctionne avec Wazuh 4.x. Il s'appuie sur l'API Manager (port 55000) et optionnellement sur l'API OpenSearch Security (port 9200) pour les utilisateurs internes, les roles indexer, et les donnees de vulnerabilite Wazuh 4.8+.

Et maintenant ?

WazuhHound tourne en production chez nous. On l'utilise concrètement pour auditer les permissions RBAC, vérifier la topologie de nos déploiements, et identifier rapidement les agents mal configurés ou exposés. C'est devenu un réflexe avant chaque revue de sécurité.

En tant qu'ambassadeur Wazuh, je vois ce projet comme une brique complémentaire à l'écosystème - pas un fork, pas un concurrent, juste un outil qui exploite ce que Wazuh expose déjà via son API et le rend visible d'une façon différente. Si vous administrez un déploiement Wazuh et que vous n'avez jamais eu une vue graphe de votre infrastructure, c'est le bon moment pour essayer.

WazuhHound est open source

Libre, sous licence MIT. Schema BloodHound CE, icones personnalisees, 48 requetes Cypher pre-integrees
et scripts helper pour l'upload - tout est inclus. Si vous utilisez Wazuh et qu'il vous manque
un type de noeud ou une relation, ouvrez une issue ou une PR -
c'est exactement comme ca que le logiciel libre avance.

Voir sur GitHub
Ambassadors Program

• Wazuh
• BloodHound CE
• Ambassadors Program

L’article WazuhHound – Cartographier votre infrastructure Wazuh avec BloodHound CE est apparu en premier sur Aukfood.

Bon premier réflexe, redémarrer, et bien sûr même cause, même conséquence ...

Et donc il faut matter ce grub ...

Avec un peu de musique : Lordi Le Papa Pinguin

Dis moi papa pinguin c'est quoi GRUB ?

GRUB (Grand Unified Bootloader) est le chargeur d'amorçage le plus utilisé sur les systèmes Linux. C'est le premier programme qui s'exécute au démarrage de l'ordinateur, juste après le BIOS/UEFI. Son rôle est de localiser le noyau Linux (ou un autre système d'exploitation) et de le charger en mémoire pour démarrer la machine.

Il permet notamment de :

• Choisir entre plusieurs systèmes d'exploitation au démarrage (dual boot)
• Passer des paramètres au noyau Linux
• Démarrer en mode de récupération en cas de problème

Passage en mode rescue

La première étape, le boot de l’instance/vm/serveur en mode rescue.

Analyse des disques

Une fois démarré, on analyse les disques pour reprendre le montage du système :

fdisk -l
lsblk -f

Identifier :

• le disque système (/dev/sda, /dev/vda, /dev/xvda, etc.)
• la partition root.

Montage du système

On monte ensuite le disque système (et si besoins les autres disques pour reconstituer le système de fichiers) :

mount /dev/sdXN /mnt/tmp1

Exemple :

mount /dev/sda1 /mnt/tmp1

Préparation du chroot

Eh oui même en 2026 il faut savoir faire un chroot.

Dis moi papa pinguin c'est quoi un chroot ?

Un chroot (change root) est une opération Unix qui modifie le répertoire racine apparent d'un processus. Tout processus lancé dans un chroot ne peut accéder qu'aux fichiers situés sous ce nouveau répertoire racine, ce qui l'isole du reste du système.

mount --bind /proc /mnt/tmp1/proc
mount --bind /sys /mnt/tmp1/sys
mount --bind /dev /mnt/tmp1/dev
mount --bind /run /mnt/tmp1/run

Puis :

chroot /mnt/tmp1 /bin/bash

Vérification du disque de boot

Une fois dans le chroot on va vérifier le nom du disque :

lsblk

Confirmer le disque système complet :

• /dev/sda
• /dev/vda
• /dev/xvda

Réinstallation GRUB

On réinstalle Grub sur le bon disque :

grub-install /dev/sdX

Exemple :

grub-install /dev/sda

Régénération initramfs

On regénère l'initramfs :

Dis moi papa pinguin c'est quoi initramfs ?

initramfs (Initial RAM File System) est un système de fichiers temporaire chargé en mémoire vive au démarrage, juste après GRUB. Il contient un mini-environnement Linux minimal qui permet au noyau de préparer le vrai démarrage du système.

Il sert notamment à :

• Charger les pilotes (drivers) nécessaires pour accéder au disque dur
• Déverrouiller un disque chiffré (LUKS) avant de monter la partition racine
• Assembler un RAID ou un volume LVM avant le montage
• Monter la vraie partition / et passer la main au système définitif

Une fois son travail terminé, initramfs disparaît de la mémoire et le système démarre normalement.

update-initramfs -u -k all

Mise à jour du menu GRUB

On fini en mettant à jour le menu de démarrage :

update-grub

Vérifications importantes

Quelques petites vérifications :

ls -lh /boot

Présence obligatoire :

• vmlinuz-*
• initrd.img-*

Vérifier aussi l’espace disque :

df -h /boot

Redémarrage

On reboot en mode normal :

exit
reboot

L’article Le travail de papa pinguin : comment matter un grub qui redémarre pas est apparu en premier sur Aukfood.