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.

Docker on Mook’s Lab Chronicles