Un bastion SSH pour 43 machines : pourquoi Warpgate, et comment on l'a mis en place

Posez la question à n'importe quel administrateur : « qui s'est connecté à ce serveur mardi dernier, et qu'y a-t-il fait ? ». Si la réponse commence par « il faudrait regarder le journal d'authentification de la machine », vous n'avez pas de bastion. Et si la machine a été compromise, ce journal ne vaut plus rien. Nous étions dans ce cas, avec un parc de plus de quarante machines. Voici comment nous en sommes sortis, en une journée, avec Warpgate.

Le problème n'était pas l'accès, c'était la trace #

Notre accès était propre sur le papier : clés uniquement, pas de mot de passe, fail2ban partout. Mais en auditant les clés autorisées du parc, nous avons compté trois clés d'outils sur chaque machine (la nôtre, celle de la console, celle de l'agent d'automatisation), avec jusqu'à six copies de la même clé sur un hyperviseur, déposées au fil des ans. Chaque clé ouvrait quarante-deux portes. Et aucune trace centrale : savoir ce qu'avait fait une session exigeait de faire confiance au journal de la machine elle-même. Les mesures d'hygiène de l'ANSSI que nous nous étions imposées sont explicites là-dessus : administration par un point dédié, journalisation centralisée, comptes nominatifs. Nous cochions la moitié.

Pourquoi Warpgate #

Warpgate est un bastion open source écrit en Rust, par l'auteur de Tabby. Sa qualité première : il est sans client. Rien à installer sur les postes, aucun agent sur les serveurs. Il se place dans le chemin de données : on se connecte à lui, il relaie vers la cible avec ses propres clés, et enregistre chaque session de façon rejouable. L'adressage tient dans le nom d'utilisateur SSH : ssh moi:cible@bastion -p 2222. Il parle OIDC, donc notre IdP Authentik ; il gère des rôles d'accès par cible ; il expose une API complète. Et il est léger : un conteneur, une base SQLite, quelques dizaines de mégaoctets. Les alternatives que nous avons regardées étaient soit des produits commerciaux surdimensionnés pour quarante machines, soit des rebonds SSH classiques qui ne tracent rien.

Un bastion ne doit pas être sur ce qu'il administre #

Nous l'avons d'abord installé sur une VM de notre réseau d'administration privé. Le soir même, il déménageait sur un VPS dédié, sous son propre nom. Deux raisons. La première est pratique : un bastion joignable seulement depuis un réseau local interdit tout accès nomade, et fait de la ligne de ce réseau un point unique de défaillance. La seconde est de principe : le bastion ne doit pas dépendre de l'infrastructure qu'il administre. S'il vit sur le cluster qu'il ouvre, la panne du cluster vous coupe l'accès dont vous avez besoin pour la réparer. Migration à chaud pour les enregistrements, à froid pour la base : trois minutes de coupure, et la clé d'hôte SSH voyage avec les données, donc aucun avertissement côté clients.

⟷ faites défiler

Rôles : refuser le fourre-tout #

Warpgate distingue deux choses que l'on confond souvent : les groupes de cibles (de l'organisation : nom, couleur, description) et les rôles (des droits). Notre premier réflexe fut un rôle unique donnant accès à tout. Nous l'avons supprimé : un rôle fourre-tout annule toute granularité. Le parc est découpé en cinq rôles : infra-pure (les trois hyperviseurs et le serveur de sauvegarde), service (23 machines de socle : edge, DNS, IdP, coffres, mail), app (11 applications hébergées) et deux rôles d'infogérance pour les machines clientes. Un collaborateur qui n'intervient que sur les hyperviseurs reçoit infra-pure, et rien d'autre. Notez le paradoxe : c'est le rôle le plus petit en nombre et le plus étendu en portée, puisque root sur un hyperviseur contrôle tous ses invités.

Les agents d'automatisation ont leur propre compte #

Nous administrons ce parc avec l'aide d'un agent IA, et il utilisait au départ le jeton d'un humain : tout ce qu'il faisait était attribué à cet humain, un recul par rapport au SSH direct où sa clé était distincte. Il a donc reçu son propre compte dans Warpgate : authentification par clé uniquement (ce qui lui ferme de fait l'interface web), une seule adresse IP source autorisée, aucun rôle d'administration, et des rôles d'accès élargis cible par cible, jamais en bloc. L'audit distingue désormais l'agent de l'humain. Et quand l'utilisateur a tranché que « l'agent n'a pas à être la voie de secours du parc », sa clé directe a été retirée des quarante-deux machines. Puis son accès au bastion lui-même, jugé trop sensible : c'est la machine qui porte l'identité de tout le reste.

La consolidation des clés, dans le bon ordre #

Le bénéfice réel n'arrive qu'à la fin : tant que les anciennes clés restent sur les serveurs, le bastion n'est qu'une troisième clé de plus. Nous avons donc retiré, machine par machine et avec sauvegarde, la clé de la console (elle ne sert plus qu'à se présenter au bastion), puis celle de l'agent : 66 lignes supprimées. Vérification dans les deux sens à chaque étape : accès direct refusé, 42 connexions sur 42 par le bastion. Il reste sur la flotte la clé client de Warpgate, celle de notre serveur de déploiement, et une clé de secours hors ligne sur les machines publiques, dont l'usage déclenche une alerte de niveau maximal dans notre SIEM. Le filet, désormais : le compte local du bastion, la console des hyperviseurs, et la carte de gestion des serveurs dédiés.

Les pièges qui ont chacun coûté un aller-retour #

• L'image tourne avec l'utilisateur 1000. Un dossier de données possédé par root fait échouer l'installation sur un « permission denied » qui ne dit pas que c'est un problème de propriété.
• Le tag d'image est 0.28.6, pas v0.28.6 ; le dépôt git porte le v, pas le registre. Et la commande d'installation non interactive existe bien qu'elle ne soit pas documentée : c'est elle qu'il faut pour une installation reproductible.
• L'hôte externe ne doit pas contenir le port, contrairement à ce qu'affirme la documentation : le binaire l'ignore en silence et l'URL de retour SSO part sans port, d'où un 400 de l'IdP. Le port a son propre paramètre, et laissé vide il retombe sur le port d'écoute interne, pas sur 443.
• L'URL d'émetteur OIDC doit être identique au caractère près, barre oblique finale comprise, à celle du document de découverte. L'outil de vérification intégré ne voit pas cette erreur : seul un test au navigateur la révèle.
• Warpgate exige un e-mail vérifié de l'IdP. Un compte neuf sans cet attribut est refusé sans explication utile. À poser avant d'inviter quelqu'un.
• Un compte créé par le SSO n'a aucun droit d'administration. Le jeton est valide, l'API répond 401 sur tout : il faut attribuer le rôle admin explicitement. Et sachez qu'un jeton d'API n'est jamais « lecture seule » : il permet d'ajouter une clé au compte ou d'en retirer le second facteur. Détenir le jeton, c'est détenir le compte.
• La vérification de clé d'hôte exige un terminal. Une connexion non interactive vers une cible inconnue rend la main sans sortie ni code d'erreur, ce qui ressemble à un problème réseau. La bonne voie est l'API d'administration, après avoir comparé la clé à une source indépendante : c'est un moment de confiance aveugle, ne l'enregistrez pas sans recoupement.
• Pas d'ACME intégré : un certbot autonome et un script de déploiement qui recopie le certificat et redémarre le conteneur.

Vivre avec : supervision, croissance, angles morts #

Le bastion est devenu le point le plus critique du parc, il est donc surveillé comme tel : sondes de disponibilité, métriques, un tableau de bord dédié à la chaîne d'authentification (bastion et IdP), et un agent SIEM, le plus utile de tous puisqu'il porte la trace de tous les accès. Les enregistrements grossissent d'environ 5 Mo et 380 fichiers par jour, avec une rétention d'audit d'un an intégrée : le disque de 40 Go tient plus de deux ans. Un angle mort assumé : deux machines de notre réseau d'administration privé restent structurellement injoignables depuis un bastion sur Internet, et gardent un accès direct, hors trace. Nous préférons le dire que le cacher.

« Qui a fait quoi, où, et quand » est la première question qu'un client, un assureur ou un auditeur pose après un incident. Y répondre en rejouant la session plutôt qu'en fouillant des journaux dispersés fait partie de ce que nous appelons une infogérance sérieuse. Si votre réponse actuelle tient dans un fichier authorized_keys que personne n'a relu depuis deux ans, parlons-en.