Sécuriser un homelab Kubernetes avec TLS wildcard et sans ports ouverts

Les auto-hébergeurs qui exploitent des clusters Kubernetes sont souvent confrontés à un dilemme entre sécurité et praticité lors de la configuration HTTPS. Un nouveau guide technique démontre comment utiliser k3s, Traefik et cert-manager pour émettre des certificats wildcard fiables via des défis DNS-01, éliminant ainsi le besoin d'ouvrir des ports entrants depuis Internet.

Ce qui s'est passé

L'article décrit une méthode pour sécuriser les applications web internes dans un environnement homelab sans recourir à des certificats auto-signés ni exposer le réseau aux scanners externes. En tirant parti du protocole de défi DNS-01, les administrateurs peuvent prouver la propriété du domaine aux autorités de certification comme Let's Encrypt via des appels API à leur fournisseur DNS. Cette approche permet à chaque application routée par le cluster de recevoir automatiquement des certificats HTTPS valides et approuvés par les navigateurs.

Le processus commence par la vérification du contrôleur d'ingress Traefik installé par défaut avec k3s. Au lieu de modifier directement les manifests générés, le guide recommande d'utiliser une ressource HelmChartConfig pour modifier les paramètres de Traefik, tels que l'imposition des redirections HTTP vers HTTPS. Il note également qu'il faut éviter les anciens tutoriels suggérant l'installation d'ingress-nginx, ce projet ayant été retiré en novembre 2025, avec une fin de maintenance prévue en mars 2026. Les utilisateurs de k3s sont invités à migrer toute configuration existante vers la classe Traefik native.

Ensuite, le guide détaille l'installation de cert-manager, un outil qui automatise la gestion et l'émission de certificats TLS. Une fois installé, les administrateurs configurent un ClusterIssuer qui interagit avec leur fournisseur DNS, tel que Cloudflare, en utilisant des jetons API à périmètre limité plutôt que des clés globales. La dernière étape consiste à demander un seul certificat wildcard pour le domaine interne, que Traefik sert ensuite par défaut pour toutes les connexions TLS non correspondantes, simplifiant ainsi la configuration des applications individuelles.

Détails clés

• Aucun port ouvert requis : Le défi DNS-01 valide la propriété du domaine via des enregistrements DNS, aucun trafic entrant depuis Internet n'est donc nécessaire pour l'émission du certificat.
• Efficacité du wildcard : Un seul certificat pour *.home.example.com couvre toutes les applications internes, réduisant la charge de gestion et limitant l'exposition dans les journaux publics Certificate Transparency.
• Configuration de Traefik : Les paramètres doivent être appliqués via HelmChartConfig dans l'espace de noms kube-system, en utilisant service.spec.type au lieu de la clé obsolète service.type.
• Bonnes pratiques de sécurité : Utilisez des jetons API à périmètre limité pour les fournisseurs DNS et stockez les secrets dans l'espace de noms cert-manager, et non dans les espaces de noms des applications.
• Test en préproduction d'abord : Testez toujours la configuration de l'émetteur avec les serveurs de staging de Let's Encrypt pour éviter d'atteindre les limites de débit avant de passer en production.
• Résolution interne : Les noms d'hôtes internes ne se résolvent que via des substitutions DNS LAN, garantissant que les services restent inaccessibles depuis l'extérieur du réseau local, même si le domaine est public.

Contexte

La configuration HTTPS traditionnelle pour les home labs implique souvent deux voies problématiques. L'une consiste à utiliser des certificats auto-signés, qui déclenchent des avertissements du navigateur et perturbent les gestionnaires de mots de passe, habituant les utilisateurs à ignorer les alertes de sécurité. L'autre consiste à ouvrir le port 80 pour permettre les défis HTTP-01, ce qui expose le réseau interne à des attaques potentielles. Le défi DNS-01 résout ce problème en permettant à l'autorité de certification de vérifier le contrôle d'un domaine en recherchant un enregistrement TXT spécifique dans la zone DNS, un processus qui se déroule entièrement hors bande par rapport au serveur web.

Dans Kubernetes, un contrôleur d'ingress agit comme point d'entrée pour le trafic externe, dirigeant les requêtes vers les services appropriés. Traefik, inclus avec k3s, gère ce routage et la terminaison TLS. En définissant un magasin TLS par défaut dans Traefik, les administrateurs peuvent s'assurer que toute requête correspondant au domaine interne reçoit le certificat wildcard correct sans avoir à spécifier des références de secret dans chaque ressource Ingress individuelle. Cela découple la gestion des certificats du déploiement des applications.

Pourquoi c'est important

Pour les équipes et les individus gérant une infrastructure auto-hébergée, maintenir la confiance dans les outils internes est crucial. Les avertissements du navigateur érodent la confiance des utilisateurs et créent des angles morts de sécurité où les attaques de phishing pourraient réussir parce que les utilisateurs ont pris l'habitude de contourner les erreurs de certificat. L'automatisation de l'émission de certificats valides garantit que les tableaux de bord internes, les environnements de développement et les outils d'administration se comportent exactement comme des systèmes de production, favorisant une meilleure hygiène de sécurité.

De plus, la réduction de la surface d'attaque est une préoccupation majeure pour tout responsable informatique. En évitant les redirections de ports pour la validation des certificats, le homelab reste invisible aux scanners à l'échelle d'Internet. Cette configuration s'aligne sur les principes du zero-trust, où l'accès est accordé via des VPN plutôt que des règles de pare-feu ouvertes. Elle simplifie également les opérations ; l'ajout d'un nouveau service ne nécessite qu'une définition standard d'Ingress, le TLS étant géré globalement par le certificat wildcard.

Le retrait d'ingress-nginx souligne également l'importance de rester à jour avec les changements de l'écosystème. S'appuyer sur des composants natifs pris en charge comme Traefik dans k3s réduit la dette technique et assure la continuité des mises à jour de sécurité. Cette approche fournit une base robuste et maintenable pour les services internes qui évolue à mesure que davantage d'applications sont ajoutées au cluster.

Ce que vous pouvez faire

• Vérifiez votre version de Traefik pour k3s et mettez à jour la configuration en utilisant HelmChartConfig pour imposer les redirections HTTPS.
• Installez cert-manager avec les CRDs activés et configurez un ClusterIssuer pour votre fournisseur DNS en utilisant des jetons API à périmètre limité.
• Demandez un certificat wildcard pour votre domaine interne en utilisant d'abord l'émetteur de staging pour valider le processus de défi DNS.
• Configurez un TLSStore Traefik pour définir le certificat wildcard comme valeur par défaut pour toutes les connexions TLS entrantes.
• Assurez-vous que le DNS interne résout votre domaine privé vers l'IP du LoadBalancer Traefik, gardant les services inaccessibles depuis Internet.
• Remplacez toute configuration ingress-nginx restante par des ressources Ingress compatibles avec Traefik, en supprimant les annotations obsolètes.