9 articles tagués avec « Réseau »

Un cluster Kubernetes sans IP publique expose souvent ses services par un VPN maillé comme Tailscale : le reverse proxy reçoit une adresse sur le réseau privé virtuel, et le DNS public de *.apps.example.com pointe vers cette adresse. Seuls les postes membres du VPN atteignent les services, y compris ceux qui se trouvent physiquement sur le même réseau local que les serveurs. Ouvrir un accès direct depuis ce réseau local se heurte à des contraintes fréquentes en entreprise : le DNS et le DHCP de l'organisation sont gérés par une autre équipe, aucune adresse fixe n'est réservable, et le DNS public doit rester inchangé pour les utilisateurs du VPN. Cet article décrit une solution qui combine des externalIPs sur le Service du reverse proxy et un CoreDNS dédié, interrogé uniquement par les postes configurés à cet effet.

Sur un cluster Kubernetes, chaque application exposée par l'ingress controller pose la même question d'authentification : certaines n'en ont aucune (tableau de bord, interface de supervision, outil interne), d'autres gèrent leurs propres comptes et ignorent ceux des autres. Un fournisseur d'identité unique, interrogé par Traefik en forward-auth pour les premières et en OpenID Connect par les secondes, ramène ces décisions à un seul annuaire. Authentik remplit ce rôle avec deux capacités absentes d'une configuration minimale : l'inscription en libre-service et les connexions par fournisseur externe (GitHub, LDAP, SAML). Son déploiement sur Kubernetes ajoute des pièges propres à Traefik en mode CRD : priorité des routers, références entre namespaces et route de callback de l'outpost.

Un forward-auth décide au niveau du reverse proxy si une requête peut atteindre un service, mais l'application protégée n'en apprend rien : elle affiche son propre formulaire de connexion, gère ses propres comptes et ignore les groupes définis dans l'annuaire central. OpenID Connect (OIDC) résout ce problème au niveau applicatif. L'application délègue l'authentification à un fournisseur d'identité, reçoit en retour un jeton signé qui décrit l'utilisateur et ses groupes, et crée sa session locale à partir de ces informations. Authelia peut jouer ce rôle de fournisseur pour toute application compatible.

Chaque application web auto-hébergée embarque sa propre gestion des comptes, ou n'en embarque aucune : un tableau de bord d'administration, une interface de supervision ou un outil interne se retrouvent exposés avec autant de formulaires de connexion, de politiques de mot de passe et de bases d'utilisateurs que de services. Le forward-auth déplace cette décision au niveau du reverse proxy : avant de transmettre une requête à l'application, le proxy interroge un service d'authentification central et ne laisse passer que les requêtes que ce dernier valide. Authelia implémente ce rôle, et Traefik le consomme via son middleware forwardAuth.

TLS chiffre les communications entre client et serveur, vérifie l'identité du serveur via un certificat signé par une autorité de certification (CA), et garantit l'intégrité des données échangées. Comprendre la chaîne de certification et le handshake TLS est nécessaire pour configurer correctement HTTPS et diagnostiquer les erreurs de certificat en production.

La configuration d'un reverse proxy traditionnel comme Nginx exige une intervention manuelle à chaque ajout ou modification d'un service : éditer un fichier de configuration, tester la syntaxe, recharger le process. Dans un environnement conteneurisé où les services démarrent et s'arrêtent fréquemment, cette approche ne tient pas. Traefik lit la liste des services directement dans Docker ou Kubernetes et régénère sa configuration à la volée, sans interruption de service.

Configurer Nginx manuellement demande de maîtriser sa syntaxe et de gérer les certificats SSL à la main. Nginx Proxy Manager expose une interface web qui automatise ces deux aspects : création de règles de routage via une UI, et renouvellement automatique des certificats Let's Encrypt. Il génère du vrai Nginx sous le capot : les configurations avancées restent accessibles via des blocs personnalisés.

Nginx est un serveur web événementiel conçu pour gérer un grand nombre de connexions simultanées avec une faible empreinte mémoire. Contrairement aux serveurs qui dédient un processus ou un thread à chaque connexion (Apache avec les MPM prefork ou worker), il utilise un modèle non-bloquant à base de boucle d'événements : chaque worker process gère des milliers de connexions sans créer un thread par connexion. Cette architecture en fait un choix courant comme reverse proxy en frontal d'une infrastructure.

Un proxy et un reverse proxy remplissent tous les deux un rôle d'intermédiaire réseau, mais ils se positionnent de chaque côté de la connexion : l'un représente le client, l'autre protège le serveur. Confondre les deux mène à des architectures mal configurées et à des règles de sécurité inefficaces.