Ansible on Mook’s Lab Chronicles

Mon bastion Warpgate : des clés SSH au simple alias

Sat, 19 Sep 2026 16:06:02 +0200

Dans mon terminal, accéder à un serveur tient en une seule ligne :

1

ssh dmz-nextcloud-01

Pas d’adresse IP à chercher, pas de serveur de rebond à saisir, aucune clé personnelle à copier sur la cible. Pourtant, sous la surface, une chaîne complète s’active : OpenSSH, Traefik, mon bastion Warpgate, Authentik et un fichier de configuration alimenté par WarpgateSH.

Dans le billet consacré à WarpgateSH, j’expliquais comment un script lourd à maintenir avait donné naissance à un outil dédié. Il me restait à présenter l’autre pan du système : le bastion lui-même, la gestion des clés SSH et son intégration dans mon système d’information — à l’échelle d’un homelab.

Je vais remonter cette commande étape par étape, depuis mon terminal jusqu’au serveur. Pour en reproduire le principe, je partirais simplement d’une VM et d’une machine de test.

Les exemples s’appuient sur mon infrastructure et le code de WarpgateSH au 19 septembre 2026 ; la version de Warpgate vérifiée le 10 septembre était la 0.27.5. Les valeurs example.net, alice et srv-demo sont fictives et réservées aux démonstrations.

Un bastion, pour quoi faire ?

Un bastion sert de point de passage contrôlé vers les ressources à administrer. Au lieu d’autoriser chaque poste à joindre directement chaque serveur, je centralise les flux sur un service unique. Il contrôle les identités, applique les droits et conserve des journaux d’accès.

Warpgate remplit cette fonction chez moi. Je lui déclare les cibles (les serveurs autorisés) et les rôles (qui a le droit d’y accéder), tout en conservant mon client SSH habituel.

À la différence d’un rebond classique via ProxyJump, la connexion SSH directe depuis mon poste s’arrête au bastion. Warpgate ouvre ensuite sa propre session vers la machine cible avec ses propres identifiants. Je n’ai donc jamais besoin d’y transférer mon agent SSH local.

Vue logique : le réseau et le proxy de transport sont volontairement omis pour faire ressortir les deux authentifications.

Cette étanchéité constitue le point clé du montage : mon identité sur le bastion et le compte Linux de la cible sont deux entités totalement distinctes.

Clé privée, clé publique : qui garde quoi ?

Une paire de clés SSH repose sur deux éléments liés mathématiquement :

la clé privée, gardée secrète par le client qui prouve son identité ;
la clé publique, déposée sur le serveur qui vérifie cette identité.

Lors de la connexion, le client signe le défi d’authentification avec sa clé privée. Le serveur valide cette signature via la clé publique correspondante, sans que la clé privée ne transite sur le réseau.

Sur un serveur OpenSSH standard, les clés autorisées sont listées dans ~/.ssh/authorized_keys au niveau du compte utilisateur Linux (alice, root, etc.).

Pour illustrer la génération manuelle, je prends cette commande :

1

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_bastion -C "poste-perso"

Cette commande produit deux fichiers (décrits dans le manuel ssh-keygen) :

1
2


~/.ssh/id_ed25519_bastion ← Fichier privé local
~/.ssh/id_ed25519_bastion.pub ← Clé publique à déployer côté serveur

Chez moi, les clés passent par l’agent Bitwarden

Je ne définis pas de mot de passe directement sur le fichier de clé : je délègue sa protection au coffre fort de Bitwarden et son utilisation à son agent SSH. OpenSSH sollicite l’agent pour signer l’authentification sans lire de fichier privé sur mon disque. Le guide SSH Bitwarden détaille sa mise en œuvre.

Dans mon inventaire Ansible, la connexion pointe vers le socket de l’agent :

1

-o IdentityAgent=~/.bitwarden-ssh-agent.sock

Une précision importante : stocker une clé non chiffrée dans Bitwarden protège sa copie dans le coffre, mais ne sécurise pas le fichier initial resté sur le disque s’il n’a pas été supprimé.

Pour accéder au bastion via SSH, j’enregistre ma clé publique dans mon profil Warpgate. Mon agent Bitwarden produit la signature ; le bastion la vérifie avec ma clé publique. Une fois authentifié, Warpgate initie la connexion vers la cible finale en utilisant sa propre clé privée. J’autorise donc la clé publique du bastion dans le fichier authorized_keys du serveur, et non ma clé personnelle.

Ce flux par clé sert principalement aux comptes de service. Pour mes sessions d’administration courantes, je valide mon identité dans le navigateur via Authentik.

Ed25519, RSA, ECDSA : trois algorithmes distincts

Ces appellations désignent des algorithmes utilisés pour les signatures d’authentification SSH :

Type	Ce que j’en retiens
Ed25519	C’est mon choix pour les systèmes récents et le type de clé déployé par mon socle Ansible.
RSA	Je le réserverais aux besoins de rétrocompatibilité, avec des signatures SHA-2 comme l’expliquent les notes OpenSSH 8.8.
ECDSA	Variante basée sur des courbes elliptiques standardisées, disponible nativement dans OpenSSH.
`ed25519-sk` / `ecdsa-sk`	Déclinaisons exploitant une clé de sécurité matérielle (FIDO2/YubiKey).

Pour une nouvelle installation, j’écarte les algorithmes obsolètes comme DSA.

Et la clé du serveur ?

SSH contrôle également l’authenticité de l’hôte distant pour éviter les interceptions.

authorized_keys contrôle qui peut entrer ;
known_hosts enregistre les serveurs de confiance.

Le poste client valide l’empreinte du bastion, puis le bastion valide celle du serveur cible. À la première connexion, je recommande de comparer l’empreinte proposée avec celle relevée depuis la console de la VM. Pour afficher cette dernière sur la cible, j’utiliserais cette commande :

1

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Note d’usage : ne pas comparer cette empreinte revient à accepter aveuglément l’identité du serveur. C’est un point d’amélioration que je prévois d’automatiser entièrement dans mon lab.

Déploiement dans le homelab

Mon bastion tourne sur une VM Proxmox dédiée (dmz-bastion-01), provisionnée via Terraform (2 vCPU, 2 Gio de RAM, 30 Gio de stockage).

Ansible déploie Docker et configure l’environnement. Voici un extrait de mon fichier Docker Compose :

1
2
3
4
5
6
7
8
9


services:
 warpgate:
 container_name: warpgate
 restart: unless-stopped
 ports:
 - "2222:2222"
 - "8888:8888"
 volumes:
 - ./data:/data

Le port 2222 reçoit les connexions SSH et le port 8888 héberge l’interface d’administration HTTPS. Le dossier ./data conserve l’état persistant de l’application.

Traefik en frontal : un nom, deux parcours

Traefik écoute sur bastion.int.homeblack.fr et redirige les requêtes vers le bastion :

1
2
3
4
5
6
7
8


Portail HTTPS (SSO)
Navigateur → bastion.int.homeblack.fr:443
 → Traefik → Warpgate:8888 (HTTPS)

Session SSH
OpenSSH → bastion.int.homeblack.fr:2222
 → Traefik (Relais TCP) → Warpgate:2222
 → Serveur cible:22

Traefik achemine le trafic vers Warpgate ; Warpgate gère les accès aux cibles. Traefik ignore tout des machines finales et se contente de relayer les flux.

Reverse proxy HTTPS pour le portail

Le portail web passe par un reverse proxy standard. L’inventaire Ansible définit le routage :

1
2
3


- name: "bastion"
 host: "bastion.int.homeblack.fr"
 upstream_url: "https://10.60.0.17:8888"

Les liens d’approbation et le retour Authentik passent par le navigateur, via l’accès HTTPS du portail.

Relais TCP dédié pour le flux SSH

SSH ne traitant pas le protocole HTTP, Traefik utilise un routeur TCP. La configuration statique déclare d’abord le point d’entrée :

1
2
3


entryPoints:
 warpgate-ssh:
 address: ":2222"

La configuration dynamique (chargée via le provider file) définit ensuite le routage :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


tcp:
 routers:
 warpgate-ssh:
 entryPoints:
 - warpgate-ssh
 rule: "HostSNI(`*`)"
 service: warpgate-ssh

 services:
 warpgate-ssh:
 loadBalancer:
 proxyProtocol:
 version: 2
 servers:
 - address: "10.60.0.17:2222"

La règle HostSNI(`*`) accepte tous les flux TCP bruts sans interception TLS (détails dans la doc Traefik TCP). Le chiffrement SSH reste géré de bout en bout entre le client et Warpgate.

Conservation des IP sources avec PROXY Protocol

Lorsqu’un proxy transfère une connexion, le serveur final ne voit que l’IP du proxy.

L’activation du PROXY protocol v2 permet à Traefik de transmettre l’IP d’origine du client dans un en-tête ajouté au début du flux TCP. Côté Warpgate (ansible/inventory/group_vars/bastion.yml) :

1
2
3
4
5


warpgate_ssh_external_host: "bastion.int.homeblack.fr"
warpgate_ssh_external_port: 2222
warpgate_ssh_proxy_protocol: true
warpgate_ssh_allowed_sources:
 - "10.40.0.28/32" # IP de Traefik autorisée

Segmentation réseau

Dans mon architecture, Traefik réside sur le réseau TRUST et Warpgate sur le réseau DMZ. Le flux traverse le pare-feu inter-vlan. Pour une nouvelle installation, je privilégierais un reverse proxy dans le même segment réseau que le service, afin d’éviter ce passage entre zones.

J’intègre aussi le filtrage des accès directs depuis les postes à la mise en place du bastion, avec l’objectif de faire passer les sessions d’administration par Warpgate.

Comment les serveurs valident le bastion

Une fois authentifié sur Warpgate, ce dernier initie la connexion SSH vers le serveur cible. La cible doit donc connaître la clé publique du bastion.

Mon rôle Ansible ssh-keys déploie automatiquement la clé publique du bastion (warpgate-target) dans le fichier authorized_keys du compte système distant :

1
2
3
4
5
6


- name: Deploy authorized_keys
 ansible.posix.authorized_key:
 user: "{{ ssh_user }}"
 state: present
 key: "{{ item }}"
 loop: "{{ ssh_public_keys }}"

Côté Warpgate, les paramètres de la cible (IP, port, utilisateur Linux) sont injectés via Terraform.

Pour me connecter à Nextcloud, la commande sous-jacente générée équivaut à :

1

ssh -p 2222 -l 'gregory.narcin:dmz-nextcloud-01' bastion.int.homeblack.fr

Le paramètre -l transmet l’instruction : « Connecte l’utilisateur Warpgate gregory.narcin à la cible dmz-nextcloud-01 ». Après validation des droits, Warpgate ouvre la session SSH vers la VM avec son propre compte d’administration.

SSO avec Authentik et accès automatisés

J’utilise Authentik comme fournisseur d’identité via OIDC, OpenID Connect, pour l’authentification unique (SSO).

Pour une connexion humaine, l’option In-browser auth affiche une URL et un code de validation dans le terminal. J’ouvre le lien, compare le code affiché et approuve la demande après authentification auprès d’Authentik. OpenSSH attend cette validation via la méthode keyboard-interactive.

Pour raccorder Warpgate à Authentik, je configure une application cliente et son URL de redirection, par exemple https://bastion.example.net/@warpgate/api/sso/return. Je sélectionne ensuite In-browser auth dans la politique d’authentification SSH de mon compte, comme l’explique le guide SSO Warpgate.

Je gère la correspondance des rôles avec Ansible :

1
2
3


warpgate_oidc_roles_claim: "groups"
warpgate_oidc_role_mappings:
 warpgate-operators: "ops"

Les appartenances aux groupes Authentik sont ainsi converties en rôles d’accès dans Warpgate.

Pour mes automatisations Ansible et mes pipelines CI/CD, je garde des comptes de service avec des clés SSH dédiées, comme svc-ansible : je ne veux pas qu’un traitement attende une validation dans mon navigateur.

Déclaration des cibles avec Terraform

Je déclare mes cibles Warpgate avec Terraform pour éviter de les ajouter manuellement dans l’interface :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


resource "warpgate_target" "ssh" {
 for_each = local.ssh_targets
 name = each.key

 ssh_options {
 host = each.value.ip_address
 port = 22
 username = try(each.value.ssh_username, "root")
 allow_insecure_algos = false
 public_key_auth {}
 }
}

Mon parcours de création suit cet ordre : VM Terraform → Cible Warpgate Terraform → Socle Ansible → Synchronisation du client.

J’exclus le bastion lui-même de cette liste et conserve un accès d’urgence indépendant pour pouvoir intervenir si Warpgate tombe en panne.

Automatisation des alias avec WarpgateSH

WarpgateSH interroge l’API de Warpgate pour générer automatiquement la configuration SSH locale et les alias associés.

Après avoir installé la CLI (guide de démarrage), je configure un profil ; voici les commandes avec les valeurs de démonstration :

1
2
3
4
5
6


warpgatesh profile add lab https://bastion.example.net
warpgatesh profile default lab
warpgatesh profile ssh-auth lab in-browser
warpgatesh agent install
warpgatesh sync
warpgatesh ls

L’outil ajoute un appel d’inclusion dans ~/.ssh/config :

1

Include ~/.ssh/warpgatesh/config

Le fichier généré (~/.ssh/warpgatesh/config) contient les entrées de ce type :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


# Profile lab

Host srv-demo srv-demo.lab
 HostName "bastion.example.net"
 Port 2222
 User "alice:srv-demo"
 UserKnownHostsFile ~/.ssh/warpgatesh/known_hosts/lab
 StrictHostKeyChecking yes
 PreferredAuthentications keyboard-interactive
 KbdInteractiveAuthentication yes
 PasswordAuthentication no
 PubkeyAuthentication no

Explication des directives :

Host : définit l’alias court et l’alias qualifié.
HostName : pointe vers le bastion.
User : passe le sélecteur utilisateur:cible.
PreferredAuthentications : impose l’authentification interactive pour déclencher la validation SSO par navigateur.

Je peux ensuite utiliser la commande raccourcie :

1

ssh srv-demo

Diagnostic et retours d’expérience

J’ai rencontré des incohérences entre mes alias SSH : certains forçaient le mode keyboard-interactive, tandis que d’autres autorisaient aussi les clés publiques.

Pour comprendre ce qu’OpenSSH utilise réellement, je consulte sa configuration effective avec ssh -G, sans ouvrir de connexion :

1

ssh -G srv-demo | awk '/^(hostname|port|user|preferredauthentications|pubkeyauthentication) /'

Je peux ainsi repérer les conflits avec d’éventuelles directives Host * globales.

Pour valider un montage similaire, je vérifierais quatre points :

L’accès aux cibles autorisées.
Le refus d’accès à une cible non attribuée.
Le compte Linux obtenu à l’arrivée, avec whoami.
La présence de la session dans les traces d’audit de Warpgate.

Bilan

Avec ce montage, je centralise mes accès SSH sans intervenir sur chaque serveur à l’arrivée ou au départ d’un utilisateur. Je garde mes accès automatisés séparés grâce aux comptes de service dédiés.

En contrepartie, mon bastion devient un composant critique de l’infrastructure. Je dois sauvegarder régulièrement sa clé privée d’administration et ses données d’audit, et en restreindre strictement les accès. C’est bien ce qui se passe en coulisses, et même un peu plus… mais si je raconte tout ici, ce billet va finir avec un sommaire en trois volumes.

Selon moi, le plus simple est d’avancer par étapes : je commencerais par valider le flux SSH sur une seule cible, puis j’intégrerais le SSO OIDC avant d’automatiser la gestion des cibles et des alias sur mon poste.

Authentik, la porte d’entrée de mon homelab — et le ménage qui lui manquait

Fri, 31 Jul 2026 15:06:16 +0200

Je voulais gagner quelques millisecondes sur mes connexions. En ouvrant la VM d’Authentik, j’ai surtout trouvé un petit musée de son histoire : un conteneur Redis devenu inutile, deux fichiers d’environnement presque identiques et des images Docker accumulées.

Comme le service tournait bien, j’avais laissé cette sédimentation vivre tranquillement. Pas idéal pour celui qui garde la porte de presque tout mon homelab. Cette maintenance était donc l’occasion de faire le ménage, mais aussi de présenter enfin Authentik sur ce blog.

Bien plus qu’une jolie page de connexion

SSO signifie Single Sign-On, ou authentification unique. Le raccourci habituel consiste à dire : « un seul compte pour toutes mes applications ». C’est vrai, mais ce n’est pas le point le plus important.

Une application raccordée à Authentik ne reçoit pas mon mot de passe. Elle délègue l’authentification à un fournisseur d’identité — un Identity Provider ou IdP — puis fait confiance au jeton ou à l’assertion qu’il lui retourne. Je peux donc centraliser la double authentification, les groupes, les règles d’accès et le cycle de vie des comptes sans recopier la même logique dans chaque service.

Au 31 juillet 2026, mon instance contient 21 applications. La majorité utilise OpenID Connect (OIDC), notamment GitLab, Grafana, Warpgate, Technitium et PatchMon. Wazuh passe par SAML. Pour OpenVSCode, qui n’a pas le même raccordement natif, nginx demande directement à l’outpost Proxy d’Authentik si la requête peut continuer.

Cette souplesse est l’une des raisons pour lesquelles Authentik s’est imposé chez moi. Je privilégie OIDC lorsqu’il est disponible, SAML lorsque l’application l’impose et le provider Proxy pour les services qui ne savent rien faire de tout cela.

1
2
3
4
5


GitLab ─────────────── OIDC ──────┐
Grafana ────────────── OIDC ──────┤
Warpgate ───────────── OIDC ──────┤
Wazuh ──────────────── SAML ──────┼──> Authentik ──> identité, MFA, groupes
OpenVSCode ── nginx / forward auth ┘

Le confort est évident : une seule session ouvre plusieurs outils et je n’administre plus une collection de comptes locaux oubliés. Le revers l’est tout autant : Authentik est devenu une dépendance critique. Une panne n’arrête pas forcément les sessions déjà ouvertes, mais elle peut bloquer toute nouvelle connexion. Une compromission aurait, elle, un rayon d’action particulièrement généreux.

Je le traite donc comme une brique de sécurité, pas comme un tableau de bord de plus.

Pourquoi Authentik plutôt que Keycloak ?

J’ai longtemps hésité avec Keycloak. Il avait pour lui l’ancienneté, une documentation abondante et un écosystème déjà installé. Son dépôt public remonte à 2013, alors que le premier commit d’Authentik date de 2018.

Choisir Authentik revenait donc à miser sur le plus jeune. Son interface et ses flows me parlaient davantage, son proxy intégré convenait bien au mélange d’applications modernes et de vieux services de mon homelab, et je me sentais plus à l’aise avec un cœur Python/Django qu’avec une JVM.

Ce n’est pas un verdict contre Java : Keycloak fonctionne sur Quarkus et propose un build optimisé. Authentik n’est pas spécialement léger non plus avec son serveur, son worker, PostgreSQL et ses éventuels outposts. Mon choix était surtout pratique : lequel aurais-je envie de comprendre et de dépanner pendant plusieurs années ? Pour moi, la réponse était Authentik.

Un projet qui a mûri

Les premières versions que j’ai suivies demandaient davantage de prudence : migrations sensibles, interface mouvante et notes de version à lire religieusement. Depuis la création d’Authentik Security en 2022, le projet a changé d’échelle et adopté un modèle open core, avec les protocoles essentiels toujours disponibles dans l’édition open source.

Au 31 juillet 2026, le dépôt GitHub affichait 22 563 étoiles et une activité le jour même. La version 2026.5.6 datait du 22 juillet. Ces chiffres ne prouvent pas la qualité du logiciel, mais ils confirment un développement suivi. Après plusieurs années de mises à jour, c’est surtout cette continuité qui me rassure.

Redis était parti, mon Compose ne le savait pas

Authentik a déplacé ses tâches vers PostgreSQL en 2025.8, puis le cache, les sessions Proxy et les WebSockets en 2025.10. Redis pouvait disparaître. Mon ancien Compose continuait pourtant à lancer ce quatrième conteneur, presque inactif mais toujours présent dans les dépendances et les variables d’environnement.

L’architecture actuelle repose sur trois rôles : PostgreSQL conserve les données, le serveur traite les requêtes et le worker s’occupe des tâches asynchrones. Les notes de version 2025.10 préviennent toutefois que PostgreSQL reçoit environ 50 % de connexions supplémentaires. J’ai supprimé une dépendance, pas sa charge de travail.

Après le ménage, la liste des services est devenue très lisible :

1
2
3
4


$ docker compose -f /opt/authentik/docker-compose.yml config --services
postgresql
server
worker

J’en ai profité pour fusionner .env et authentik.env, retirer les variables Redis, ajouter le montage /data et porter la mémoire partagée du serveur et du worker à 512 Mio. Avant le déploiement Ansible, j’ai vérifié la sauvegarde Proxmox Backup Server et la lisibilité d’un dump PostgreSQL. Le second passage du playbook n’a produit aucun changement.

Les logs avaient aussi besoin d’une limite

La VM ne dispose que d’un disque de 20 Gio. Avant l’intervention, 13 Gio étaient occupés et le stack produisait environ 19 000 lignes de logs par jour sans aucune rotation.

J’ai conservé le pilote json-file. Vector consomme l’API de logs Docker et Wazuh lit les fichiers JSON ; changer de pilote aurait donc cassé silencieusement une partie de l’observabilité. En revanche, chaque conteneur possède maintenant une rotation bornée :

1
2
3
4
5


logging:
 driver: json-file
 options:
 max-size: "20m"
 max-file: "5"

Après inventaire des images actives et nettoyage des seules images inutilisées, l’occupation est passée de 13 Gio à 4,6 Gio : environ 8,4 Gio récupérés, sans toucher aux volumes.

Le vrai goulot n’était pas Docker

J’étais venu chercher quelques millisecondes dans le bridge Docker. Il n’en ajoutait que 0,1 à 0,2, tandis que la route publique répondait autour de 152 ms. Passer en mode host aurait surtout échangé de l’isolation contre un gain invisible.

La piste utile se trouvait un étage plus bas. La VM tournait sur pve-fuji, un nœud Intel déjà chargé, avec parfois 5 à 8 % de temps CPU volé. Je l’ai migrée à chaud vers pve-forum, un nœud AMD plus disponible. La latence a immédiatement chuté… puis la VM a perdu le réseau avant de se figer. À cet instant, mon petit benchmark venait de se transformer en exercice de reprise.

Après retour sur pve-fuji et redémarrage forcé, PostgreSQL et les trois conteneurs sont repartis sans perte. La bonne méthode était une migration à froid : arrêt propre par Proxmox HA, déplacement de la VM éteinte, puis redémarrage sur pve-forum. L’interruption a duré environ 2 min 40.

Étape	Route publique moyenne observée
état initial sur `pve-fuji`	151,6 ms
Compose modernisé, retour sur `pve-fuji`	105,8 ms
migration à froid vers `pve-forum`	68,9 ms

Ces mesures appartiennent à mon environnement, pas à un benchmark universel d’Authentik. Elles montrent surtout que le placement de la VM pesait bien plus que le réseau Docker — rien de très surprenant dans mon homelab bricolé de toutes pièces :D

Une première porte ouverte

Ce billet n’avait pas vocation à devenir un guide d’Authentik. Mon blog vient de démarrer et je n’avais encore jamais présenté le service qui protège pourtant 21 de mes applications. Cette maintenance était simplement la bonne occasion de lui ouvrir la porte.

Je reviendrai dans un autre article sur mon organisation autour d’Authentik : les flows, les groupes, la double authentification, le raccordement des applications et les cas où j’utilise le proxy plutôt qu’OIDC ou SAML. Pour cette fois, je voulais simplement raconter comment un conteneur Redis devenu inutile m’a donné le prétexte de présenter le gardien de mon homelab.

Trop d’alertes, plus aucune confiance : comment j’ai repris en main Checkmk

Wed, 29 Jul 2026 16:00:00 +0200

Une interface réseau disparaît à la fin d’un job. La mémoire du runner grimpe pendant un build. Une sonde mail dépasse son délai une seule fois. Un disque rappelle toutes les quelques minutes qu’il est toujours plein.

Pris séparément, chacun de ces événements mérite d’être observé. Transformés avec la même urgence en notifications, ils finissent surtout par m’apprendre à ne plus les regarder.

C’est le piège classique de la supervision : au début, on veut tout voir. Puis on ajoute des contrôles, des machines et des seuils jusqu’au moment où le système fonctionne techniquement, mais où le signal utile se retrouve noyé dans le bruit.

J’ai donc repris mes règles Checkmk une par une. Mon objectif n’était pas d’obtenir un joli écran entièrement vert. Je voulais qu’une notification signifie de nouveau : « il faut regarder maintenant ».

Le bruit n’a pas une cause unique

La mauvaise solution aurait été de relever tous les seuils ou de désactiver les services pénibles. C’est tentant, rapide et particulièrement efficace pour fabriquer une fausse tranquillité.

À la place, j’ai classé chaque alerte dans l’une de ces familles :

Situation	Exemple dans mon homelab	Réponse
état attendu	interface TAP supprimée avec une VM éphémère	ignorer précisément ce service
incident transitoire	pic de mémoire pendant un job CI	demander une seconde confirmation
problème réel mais répétitif	disque toujours en alerte	conserver l’état, espacer les notifications
seuil mal adapté	résolution DNS correcte mais un peu variable	recalibrer avec une mesure cohérente

Cette distinction paraît évidente après coup. Dans la pratique, elle oblige à répondre à une question parfois inconfortable : qu’est-ce qui justifie réellement de m’interrompre ?

Les interfaces TAP : du bruit parfaitement normal

Mes nœuds Proxmox créent des interfaces TAP pour connecter les interfaces réseau virtuelles des VM. Leur nom suit une forme comme :

1

tap<vmid>i<nic>

Ces interfaces vivent aussi longtemps que la VM ou la charge CI correspondante. Lorsqu’une machine temporaire s’arrête, son interface disparaît. Checkmk peut alors interpréter cette disparition comme un changement d’état à signaler.

Le problème ne venait donc pas d’une panne réseau. Le cycle de vie normal d’une ressource éphémère était traité comme celui d’un port physique.

J’ai commencé par faire découvrir les interfaces Proxmox avec leur description Linux stable plutôt qu’avec un numéro générique du type Interface 12. Cela évite qu’un bridge, un VLAN ou une nouvelle interface récupère le service d’un ancien périphérique.

J’ai ensuite ajouté une règle très ciblée :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "ruleset": "ignored_services",
 "description": "Homeblack - ignore ephemeral Proxmox TAP interfaces",
 "value": True,
 "conditions": {
 "host_name": {
 "match_on": ["pve-dell", "pve-forum", "pve-fuji"],
 "operator": "one_of",
 },
 "service_description": {
 "match_on": [r"Interface tap[0-9]+i[0-9]+$"],
 "operator": "one_of",
 },
 },
}

Je n’ignore pas « les interfaces de Proxmox ». Je retire uniquement les services qui correspondent au motif des TAP éphémères. Les interfaces physiques, les bridges, les VLANs et les interfaces des machines invitées restent surveillés.

C’est une nuance importante : une bonne exception décrit un comportement attendu, pas une catégorie suffisamment large pour faire disparaître le problème.

Un pic n’est pas encore une panne

Le runner GitLab présente un autre cas. Pendant un build, sa consommation mémoire peut monter brutalement pendant un cycle de contrôle, puis revenir à la normale.

Ce pic reste intéressant. S’il dure, je veux le savoir. S’il ne concerne qu’une mesure isolée, je ne veux pas être interrompu.

Checkmk distingue justement les états soft et hard. Un premier échec peut rester transitoire ; il ne devient un problème confirmé qu’après le nombre de tentatives défini.

Pour le service Memory de trust-runner-01, j’ai choisi deux contrôles consécutifs :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


{
 "ruleset": "extra_service_conf:max_check_attempts",
 "description": "Homeblack - retry transient runner memory pressure",
 "value": 2,
 "conditions": {
 "host_name": {
 "match_on": ["trust-runner-01"],
 "operator": "one_of",
 },
 "service_description": {
 "match_on": [r"Memory$"],
 "operator": "one_of",
 },
 },
}

Un pic d’un cycle reste visible dans l’historique, mais ne déclenche pas de notification immédiate. Si la pression persiste au contrôle suivant, l’état devient hard et l’alerte suit son chemin normal. Avec la fréquence actuelle des contrôles, cela représente environ une minute de confirmation.

Les pics courts restent visibles dans le graphe sans transformer automatiquement chaque mesure isolée en notification.

J’ai appliqué le même raisonnement aux contrôles SMTP entrant et IMAP de ma plateforme mail. Un timeout isolé mérite une nouvelle tentative ; deux échecs consécutifs commencent à ressembler à un incident.

En revanche, je n’ai pas ajouté un délai arbitraire de plusieurs heures au test de livraison de bout en bout. Cette sonde possède déjà sa propre notion du temps : avertissement après 120 secondes et état critique après 300 secondes. Ajouter quatre heures de silence par-dessus revenait à rendre le contrôle presque inutile.

Espacer une notification sans effacer le problème

Les disques posent une question différente. Un filesystem plein, une erreur SMART ou une latence d’entrée-sortie ne disparaissent pas parce que j’ai déjà reçu l’alerte.

Mais recevoir continuellement le même message ne rend pas la réparation plus rapide.

J’ai conservé les services SMART, Filesystem et Disk IO visibles dans Checkmk avec leurs états normaux. C’est uniquement la fréquence de leurs notifications sortantes qui est limitée :

1
2


DISK_NOTIFICATION_COOLDOWN_SECONDS = 24 * 60 * 60
DISK_SERVICE_PREFIXES = ("SMART ", "Filesystem ", "Disk IO ")

Le mécanisme garde une réservation par couple hôte/service. Une première notification de problème passe, puis les répétitions sont bloquées pendant 24 heures glissantes. Si le problème reste actif, Checkmk envoie un rappel quotidien.

Les retours à l’état normal restent présents dans l’historique Checkmk, mais ne génèrent pas de nouvelle notification pour ces trois familles de services. Je préfère ouvrir l’interface et retrouver toute la chronologie plutôt que d’être interrompu à chaque oscillation autour d’un seuil disque.

Il y a un détail auquel je tenais : si l’envoi de la notification échoue, la réservation est libérée. Le système pourra donc retenter plus tard au lieu de considérer comme livré un message qui n’est jamais arrivé.

Enfin, cette limitation ne concerne ni les hôtes, ni les autres services. Une machine inaccessible ou un contrôle métier en échec ne profite pas discrètement du même silence.

Un seuil doit représenter un risque

La supervision DNS de Technitium m’a fourni un bon exemple de seuil techniquement valide, mais opérationnellement trop sensible.

Je contrôle deux choses depuis le serveur Checkmk :

une résolution DNS autoritative en UDP, avec vérification de la réponse ;
l’ouverture du transport DNS sur le port TCP 53.

Au départ, les deux contrôles avertissaient au-dessus de 500 millisecondes. J’ai conservé ce seuil pour l’ouverture TCP, mais porté l’avertissement UDP à une seconde. L’état critique reste fixé à 1,5 seconde et le timeout à trois secondes.

Pourquoi séparer les deux ? Une connexion TCP sur le réseau interne doit rester très rapide. Une requête DNS complète traverse davantage d’étapes et peut subir une variation ponctuelle sans que le service soit dégradé.

Le 29 juillet 2026, ma vérification en lecture seule remontait :

Service	État observé	Temps de réponse
résolution DNS Technitium en UDP	OK	65 ms
transport DNS Technitium en TCP	OK	7 ms

Ce sont des mesures prises à un instant donné, pas une promesse de performance. Elles confirment surtout que les contrôles interrogent réellement le service et exposent leur métrique après la modification.

La mesure UDP reste très en dessous du seuil d’avertissement fixé à une seconde ; le seuil critique apparaît à 1,5 seconde.

Ce que je refuse de faire taire

Réduire le bruit n’a d’intérêt que si les vrais problèmes restent bruyants.

Les avertissements critiques NVMe et les erreurs d’intégrité continuent donc d’alerter dès leur première occurrence. Les filesystems restent surveillés avec leurs seuils normaux. Lorsque le disque du runner manque réellement de place, la réponse attendue est un nettoyage ou une augmentation du volume, pas un seuil plus généreux.

Même logique pour les TAP : j’ignore les interfaces éphémères, mais pas les uplinks. Pour la mémoire du runner, j’ajoute une confirmation, mais je ne supprime pas le contrôle. Pour le DNS, je détends seulement le seuil UDP ; le contrôle TCP conserve sa valeur plus stricte.

Je me sers désormais de cette règle simple :

Si l’alerte représente un problème mesuré, je la garde. Si elle décrit un comportement attendu, je corrige son modèle.

Des règles versionnées plutôt que des clics oubliés

Tous ces réglages sont décrits dans le dépôt d’infrastructure et appliqués par un helper qui utilise l’API REST de Checkmk. Cela me permet de relire une exception, de comprendre pourquoi elle existe et de la tester comme le reste du code.

Pour appliquer les règles de calibration :

1

python3 ansible/scripts/checkmk-rest-api.py calibrate-rules

Je rejoue ensuite la commande sans activation :

1

python3 ansible/scripts/checkmk-rest-api.py calibrate-rules --no-activate

La seconde exécution doit annoncer toutes les règles gérées comme inchangées. Pour les modifications de découverte, notamment les interfaces Proxmox, je relance aussi explicitement la découverte des services concernés :

1
2
3
4


python3 ansible/scripts/checkmk-rest-api.py discover \
 --host pve-dell \
 --host pve-forum \
 --host pve-fuji

Les tests automatisés vérifient également la portée des règles : motif exact des TAP, deux tentatives pour la mémoire du runner et intervalle de 1 440 minutes pour les problèmes disque persistants.

Enfin, je contrôle l’état effectif avec Livestatus, directement sur le serveur Checkmk. Lors de la dernière vérification, le service Memory du runner était bien configuré avec deux tentatives maximales. Les deux boucles mail et les contrôles DNS étaient en état OK.

Cette dernière étape est indispensable. Une configuration correcte dans Git ne prouve pas encore que Checkmk l’a activée ni qu’elle s’applique au bon service.

Ce que je retiens

Je pensais au départ qu’une bonne supervision devait tout remonter le plus vite possible. Je la vois maintenant comme un système de décisions : que faut-il conserver dans l’historique, que faut-il confirmer et qu’est-ce qui mérite réellement une interruption ?

Les quatre leviers ne sont pas interchangeables :

ignorer précisément une ressource éphémère ;
confirmer un état transitoire avec une nouvelle tentative ;
espacer le rappel d’un problème déjà connu ;
adapter un seuil à la mesure réellement effectuée.

Je garde volontairement le canal de réception en dehors de cet article. Je raconterai prochainement comment j’achemine ces alertes, où je les reçois et comment je décide lesquelles ont réellement le droit de m’interrompre.

Depuis cette reprise, l’écran vert m’intéresse moins. Ce qui compte, c’est que la prochaine notification inhabituelle récupère immédiatement mon attention — et qu’elle la mérite.