Tunneling natif Kubernetes : l'approche CRD et Operator pour un Ingress automatisé

Les développeurs cloud-native n’exécutent pas de binaires CLI impératifs ; ils écrivent du YAML déclaratif. Gérer l’accès externe à des clusters privés, edge ou locaux avec des reverse proxies manuels est une mauvaise pratique dans un workflow d’ingénierie plateforme. Des outils comme l’Operator Kubernetes Webhook Relay ou celui de Tailscale permettent aux développeurs de gérer l’accès réseau externe entièrement via des Custom Resource Definitions (CRD) standard Kubernetes et l’API Ingress native. En traitant les tunnels comme des ressources gérées par GitOps, les équipes plateforme peuvent exposer en toute sécurité des services internes, automatiser le routage des webhooks entrants, et gérer l’ingress des edge-clusters sans toucher à un processus CLI détaché.

Le problème des tunnels impératifs dans un écosystème déclaratif

Les développeurs utilisant une infrastructure locale ou privée ont historiquement utilisé des outils comme ngrok, localtunnel ou des reverse proxies SSH pour exposer des services à Internet. Utile pour une débogage rapide, mais intrinsèquement impératif : on ouvre un terminal, on exécute une commande, et on laisse tourner.

Dans Kubernetes, cela ne tient pas longtemps. Kubernetes est une machine à états déclarative — si un nœud tombe, un pod est évincé, ou le cluster scale, un tunnel impératif tournant dans un processus détaché n’a aucune relation avec cette boucle de reconciliation. L’orchestrateur n’a aucune connaissance du tunnel, aucun moyen de surveiller sa santé, ni de le recréer.

Provisionner des IP statiques, règles de firewall, et LoadBalancers cloud pour chaque microservice ou récepteur webhook est aussi coûteux et lourd opérationnellement — surtout pour des déploiements on-premise, réseaux edge/IoT, ou clusters de développement locaux où les IP publiques ne sont tout simplement pas disponibles. C’est le cas pour traiter les tunnels comme des objets Kubernetes versionnés, continuellement reconciliés, gérés comme un Deployment ou un ConfigMap.

La transition vers un réseau piloté par operator

Le pattern Kubernetes Operator est un contrôleur personnalisé qui surveille des Resources Personnalisées et reconcilie l’état du cluster pour qu’il corresponde à ce qui est déclaré. Appliqué au réseau, un operator tourne dans votre cluster, surveille un CRD spécifique, et — lorsqu’un développeur commit un nouveau CR dans Git — s’authentifie auprès d’un service de tunneling externe et ouvre une connexion persistante, sécurisée et sortante. Comme la connexion est initiée de l’extérieur, cela ne nécessite pas d’ouvrir des ports d’entrée dans le firewall, de configurer la traversée NAT, ou de faire tourner un contrôleur Ingress public.

Cela offre trois avantages concrets aux équipes plateforme :

• Reconciliation d’état — si le tunnel se déconnecte, l’operator voit que l’état actuel ne correspond plus à l’état désiré du CR et reconstruit la connexion.
• Aucune exposition entrante — le cluster n’ouvre pas de ports entrants ; l’operator agit comme une passerelle authentifiée, uniquement sortante.
• Compatibilité GitOps — la configuration du tunnel vit dans Git à côté des manifests d’application, permettant à des outils comme ArgoCD ou Flux de déployer une application et sa route publique dans la même synchronisation.

Webhook Relay Kubernetes Operator : routage du trafic webhook et API

Recevoir des webhooks (de GitHub, Stripe ou Slack) dans un cluster privé implique généralement de mettre en place une passerelle API publique et de percer un trou dans le firewall d’entreprise. Webhook Relay Kubernetes Operator résout cela sans IP publique ni load balancer, et cible spécifiquement la réception et le routage des webhooks/demandes API — cas d’usage pour déploiements on-premise, edge K3s, et IoT.

L’installation se fait via Helm, et l’operator est configuré à l’échelle du cluster avec une clé d’accès et un secret au moment de l’installation — pas par CR :

helm repo add webhookrelay https://charts.webhookrelay.com
helm repo update

export RELAY_KEY=*****-****-****-****-*********
export RELAY_SECRET=**********

helm upgrade --install webhookrelay-operator --namespace=default webhookrelay/webhookrelay-operator \
  --set credentials.key=$RELAY_KEY --set credentials.secret=$RELAY_SECRET

Une fois l’operator en marche, un Custom Resource WebhookRelayForward décrit le point d’entrée public et où le router. Notez que les deux — une entrée (le point d’accès public) et une sortie (la destination interne) — sont nécessaires — un CR avec seulement une entrée n’a nulle part où envoyer le trafic :

# cr.yaml
apiVersion: forward.webhookrelay.com/v1
kind: WebhookRelayForward
metadata:
  name: stripe-webhook-forwarder
  namespace: payment-services
spec:
  buckets:
    - name: k8s-operator
      inputs:
        - name: public-endpoint
          description: "Récepteur Webhook Stripe"
          responseBody: "OK"
          responseStatusCode: 200
      outputs:
        - name: webhook-receiver
          destination: http://destination:5050/webhooks

kubectl apply -f cr.yaml

L’operator provisionne le bucket, ouvre le point d’entrée public, et route le trafic correspondant vers le service de destination ; supprimer le CR (kubectl delete -f cr.yaml) déconnecte à nouveau le routage. Il émet aussi des événements Kubernetes et met à jour les champs de statut du CR, pour que kubectl describe webhookrelayforward affiche l’état de livraison en temps réel.

Il est important d’être précis sur le périmètre : cet operator est spécifiquement pour le routage webhook/API. Webhook Relay propose un produit séparé — le Webhook Relay Ingress Controller (relay ingress init, manifests de déploiement sur github.com/webrelay/ingress) — pour des tunnels bidirectionnels exposant un service complet comme Grafana ou Prometheus via un sous-domaine *.webrelay.io avec des ressources Ingress standards. Les deux s’installent différemment et résolvent des problèmes différents ; ne pas attendre du CRD de l’operator webhook qu’il proxy une application web entière.

Une nouveauté à signaler pour les équipes intégrant déjà des agents IA : Webhook Relay expose désormais un serveur MCP (https://my.webhookrelay.com/v1/mcp) permettant à un agent de lister les buckets, créer ou mettre à jour des entrées/sorties, inspecter les logs de livraison webhook, et même envoyer des webhooks de test synthétiques — utile pour déboguer “pourquoi ce webhook GitHub n’a pas atteint mon cluster” plutôt que de le faire manuellement.

La lacune de KubeSail — et ce qui le remplace aujourd’hui

KubeSail était, pendant plusieurs années, l’exemple le plus cité de “surveiller une ressource Ingress standard et provisionner automatiquement un sous-domaine public avec TLS” pour les clusters home-lab et bare-metal. Il est important d’être clair : KubeSail a fermé ses services hébergés en septembre 2025. La page de farewell de l’entreprise le confirme : “Après six années merveilleuses, nous avons pris la difficile décision d’arrêter nos services hébergés… KubeSail n’accepte plus de nouveaux utilisateurs ni ne vend du matériel.” Ses fondateurs recommandent explicitement Tailscale Funnel et Cloudflare Tunnel comme alternatives. Tout article — ou brouillon — décrivant l’operator KubeSail comme une option disponible est une description d’un produit discontinu.

La bonne nouvelle, c’est que le pattern popularisé par KubeSail est toujours vivant et, en fait, plus mature aujourd’hui via le Tailscale Kubernetes Operator.

Tailscale Kubernetes Operator

Installé via Helm avec des credentials OAuth, l’operator peut exposer une charge de travail du cluster à votre tailnet privé — et, optionnellement, à Internet — de façon déclarative, en surveillant une ressource Ingress standard. Aucun type spécifique au fournisseur n’est même requis pour le cas courant.

# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  namespace: dev
  annotations:
    tailscale.com/funnel: "true"
spec:
  defaultBackend:
    service:
      name: my-app
      port:
        number: 80
  ingressClassName: tailscale
  tls:
    - hosts:
        - my-app

kubectl apply -f ingress.yaml
kubectl get ingress my-app -n dev   # surveiller le nom d’hôte attribué

Configurer ingressClassName: tailscale indique à l’operator de prendre en charge l’Ingress : il provisionne un nouveau nœud Tailscale, délivre un certificat TLS pour son nom MagicDNS, et proxy le trafic vers le Service backend — aucune règle de firewall côté cluster requise. Restant tel quel, la charge de travail est accessible uniquement depuis d’autres appareils sur votre tailnet (réseau privé), ce qui est déjà utile pour des dashboards internes ou des runners CI. Ajouter l’annotation tailscale.com/funnel: "true" la rend accessible publiquement depuis Internet, ce qui est l’analogue plus proche de ce que faisait KubeSail automatiquement.

Pour des déploiements en production, une ressource ProxyGroup permet de faire tourner plusieurs réplicas de proxy d’ingress afin que la route survive à un redémarrage du pod proxy, et la documentation Tailscale mentionne explicitement la gestion de déploiements multi-clusters avec ArgoCD — ce qui s’intègre dans le même modèle GitOps décrit ci-dessous. La suppression propre de l’Ingress supprime aussi le nœud Tailscale correspondant, garantissant l’absence de connexions orphelines, comme le prévoit l’approche CRD.

Option auto-hébergée : Helm chart Newt de Pangolin

Pour les équipes souhaitant le même pattern sortant uniquement, mais en auto-hébergement plutôt que via un réseau edge tiers, Pangolin — reverse proxy tunnélisé basé sur WireGuard (Traefik pour TLS, Gerbil pour WireGuard, et un connecteur léger appelé Newt qui diale depuis le réseau privé) — publie désormais un Helm chart officiel pour Kubernetes, distinct de l’installation Docker Compose utilisée par beaucoup jusqu’à récemment. La version du chart est 1.4.0, compatible avec Newt 1.12.3, et requiert Kubernetes 1.30 minimum. Il supporte les namespaces par instance et la lecture des credentials depuis un Secret Kubernetes existant plutôt que des valeurs en clair, ce qui est pertinent pour déployer via la même pipeline GitOps.

Exposer des workloads Minikube locaux à Internet

Minikube est la méthode standard pour faire tourner un cluster à nœud unique sur un portable, mais tester des fonctionnalités publiques — callbacks OAuth, webhooks tiers, intégrations API externes — a toujours été compliqué.

Les options traditionnelles sont :

1. kubectl expose + minikube service. Cela expose un Deployment via un NodePort, puis minikube service <nom> ouvre une fenêtre de navigateur pointée dessus. Sur le driver Docker — par défaut sur macOS et Windows, où Docker Desktop ne peut pas router directement vers les IP des containers — cette commande ouvre en réalité un tunnel SSH du host vers le nœud minikube pour atteindre le service, plutôt que d’accéder directement au NodePort. C’est un mécanisme réel (le kic.ServiceTunnel de minikube utilise SSH), pas une simple recherche de port, et cela reste ouvert tant que la commande tourne.
2. L’addon Ingress (minikube addons enable ingress) + minikube tunnel. minikube tunnel expose les Services de type LoadBalancer et doit souvent être lancé avec des privilèges élevés, car il modifie le routage du host ; il tourne en premier plan jusqu’à ce qu’on l’arrête (Ctrl-C). Oublier un terminal en train de l’exécuter est une source fréquente d’ennuis. Ces deux approches ne sont pas idéales pour partager l’environnement local avec un collègue ou un fournisseur externe.

Parce que l’operator Tailscale (ci-dessus) ne concerne que l’API Ingress standard, il fonctionne sur Minikube comme sur tout autre cluster — installer avec Helm, puis appliquer le même ingress.yaml montré plus haut, avec ingressClassName: tailscale et tout, directement dans le contexte Minikube :

minikube start
helm install tailscale-operator tailscale/tailscale-operator \
  --namespace=tailscale --create-namespace \
  --set-string oauth.clientId=<CLIENT_ID> \
  --set-string oauth.clientSecret=<CLIENT_SECRET>

kubectl apply -f ingress.yaml   # même manifeste, annotation funnel incluse

Cela vous donne une URL HTTPS publique réelle à laquelle GitHub ou Google OAuth peuvent envoyer des callbacks, provenant d’un workload tournant dans Minikube sur votre portable — sans processus minikube tunnel détaché, et sans modifier /etc/hosts. Supprimer l’Ingress déconnecte le nœud et son certificat de la même façon qu’un cluster classique, sans laisser d’endpoint public orphelin après test.

Intégration GitOps et livraison continue

L’approche CRD/operator trouve tout son sens dans un workflow GitOps, où Git est la seule source de vérité pour l’état de l’infrastructure et des applications. Dans une configuration classique, une pipeline CI/CD déploie le code, puis un humain configure manuellement le reverse proxy ou le tunnel pour l’exposer — créant un décalage entre ce qui est en version et ce qui est accessible.

Avec des définitions de tunnels exprimées en CRD ou objets Ingress standards, la configuration du routage devient un fichier YAML supplémentaire à côté des manifests de Deployment, Service, et ConfigMap :

1. Un développeur pousse une branche feature contenant un nouveau microservice et un CR WebhookRelayForward (ou un Ingress annoté Tailscale) dans Git.
2. ArgoCD ou Flux détecte le commit et synchronise l’état du cluster, appliquant le microservice et l’objet de routage ensemble.
3. L’operator concerné récupère le nouvel objet, contacte son service externe, et établit la route.
4. Le service est accessible — publiquement ou via le tailnet — sans intervention manuelle sur la configuration du proxy.

Si le cluster est reconstruit, ArgoCD réapplique le dépôt sur le nouveau cluster, et les operators reprovisionnent chaque route à partir des objets existants, sans intervention humaine. C’est exactement le pattern multi-clusters qu’ArgoCD documente pour son propre operator.

Avantages sécuritaires architecturaux

Passer du port-forwarding et des load balancers cloud à des tunnels sortants gérés par l’operator renforce la posture de sécurité du cluster. Comme la connexion est initiée de l’extérieur, il n’est pas nécessaire d’ouvrir des ports entrants dans le firewall ou les groupes de sécurité du cluster — le cluster reste invisible sur Internet, inatteignable par scan de ports ou DDoS direct sur son IP.

Les RBAC Kubernetes standards s’appliquent à ces CRD et ressources Ingress comme à toute autre ressource : un admin peut limiter les rôles pour que seules certaines namespaces puissent créer des CR de tunneling ou des Ingress avec ingressClassName: tailscale, permettant à dev et staging de gérer leurs endpoints publics, tandis que production passe par une voie plus contrôlée. Ce n’est pas une fonctionnalité spécifique à un opérateur — c’est du RBAC namespace classique appliqué à un nouveau type d’objet.

La terminaison TLS et, dans les cas de Tailscale et Webhook Relay, l’authentification se font à la périphérie, avant même que le trafic n’atteigne le cluster — ce qui signifie que ce qui arrive au service interne est déjà chiffré en transit, et dans certains cas, déjà authentifié.

Où en sommes-nous

L’évolution va vers une abstraction : les développeurs écrivent la logique applicative et un manifest Deployment, pas des tunnels CLI impératifs ou des règles NAT gérées à la main. Pour le routage webhook et API, l’Operator Webhook Relay reste une solution solide et ciblée. Pour l’ingress général — le rôle que KubeSail remplissait — l’option standard Ingress API de Tailscale Kubernetes Operator est aujourd’hui la solution maintenue, avec le Helm chart Newt de Pangolin comme alternative auto-hébergée pour ceux qui veulent le même pattern sans passer par un réseau edge tiers. Ces trois approches partagent la même architecture : CRD ou objet standard annoté, reconcilié en continu, supprimé proprement à la suppression, déployable via la même pipeline Git que tout le reste du cluster.

---

Vérification factuelle et journal de révision

• KubeSail est discontinué (correction majeure). La section initiale sur “KubeSail Reverse Proxy” était écrite au présent pour un service actif. La page officielle montre maintenant un avis de fin de service : arrêt en septembre 2025, la société n’accepte plus de nouveaux utilisateurs ni ne vend du matériel. Ses fondateurs recommandent Tailscale Funnel et Cloudflare Tunnel comme alternatives. La section a été réécrite pour mettre en avant le Tailscale Kubernetes Operator, qui remplit le même rôle et est maintenu, ainsi que le Helm chart Newt de Pangolin comme solution auto-hébergée.
• L’exemple CR WebhookRelayForward initial était incomplet et comportait un champ fictif. La YAML initiale comprenait un secretRefName: whr-credentials qui n’est pas dans le schema CRD (les credentials sont fournis via Helm avec --set credentials.key/secret lors de l’installation, créant un Secret cluster-scoped — pas référencé par CR) et omettait la section outputs, ce qui signifiait que l’exemple avait un endpoint public mais pas de destination pour le routage. La version corrigée s’appuie sur la documentation officielle webhookrelay.com/docs/installation/kubernetes/, ajoutant le champ outputs, responseStatusCode, et la procédure d’installation Helm correcte.
• Ajout d’une distinction claire : Webhook Relay propose deux produits séparés — l’operator de forwarding webhook (WebhookRelayForward CRD) et un Ingress Controller séparé (relay ingress init) pour des tunnels bidirectionnels exposant un service complet comme Grafana ou Prometheus via un sous-domaine *.webrelay.io. La version initiale mélangeait implicitement ces deux, la version corrigée explicite leur scope.
• Ajout d’un détail vérifié non présent dans le brouillon : le serveur MCP de Webhook Relay pour la gestion par agents IA des buckets/inputs/outputs/logs, pertinent pour la couverture MCP/agents IA de ce blog.
• La vérification du tunnel SSH sur Minikube a été faite, pas supposée. La source officielle de minikube (kic.ServiceTunnel) confirme que minikube service sur le driver Docker ouvre bien un tunnel SSH plutôt que d’accéder directement au NodePort — la déclaration était correcte — et la clarification a été ajoutée pour préciser que cela est particulièrement vrai sur macOS/Windows avec Docker Desktop, où le driver ne peut pas router directement vers les IP des containers.
• Remplacement du faux exemple tunneling.example.com/v1alpha1 / LocalTunnel par un manifeste réel et vérifié : un Ingress Kubernetes standard avec ingressClassName: tailscale et l’annotation tailscale.com/funnel: "true", appliqué directement dans un contexte Minikube avec l’Operator Tailscale — provenant du guide rapide de Tailscale et de la documentation Ingress.
• Atténuation de la déclaration RBAC/production : ce n’est pas une fonctionnalité spécifique à un opérateur, mais une application standard du RBAC namespace, que ces opérateurs héritent plutôt qu’implémentent.
• Les affirmations sur le pattern Operator, la réconciliation GitOps, et les commandes Helm Webhook Relay ont été vérifiées et conservées avec légers ajustements de style.