Tunneling natif Kubernetes : Ingress déclaratif avec opérateurs et CRDs

Les équipes cloud-native décrivent l’infrastructure en YAML et laissent les contrôleurs la rendre réelle. Pourtant, la plupart des développeurs mettent encore en place un cluster privé sur internet de manière impérative : ouvrir un terminal, lancer un binaire de tunnel, le laisser tourner.

Un ensemble croissant d’outils comble cette lacune. Un contrôleur dans votre cluster surveille des objets Kubernetes (une ressource personnalisée, un Ingress, une route Gateway API, ou un Service annoté), se connecte à l’edge du fournisseur, et maintient le tunnel synchronisé avec ce que vos manifests indiquent. Supprimez l’objet et le tunnel disparaît.

Ce guide couvre ce qui existe aujourd’hui, avec des manifests fonctionnels, des avertissements honnêtes, et les détails GitOps qui peuvent poser problème. Il présente aussi un projet qui était autrefois sur toutes les listes d’“opérateurs de tunnels Kubernetes” et qui n’existe plus.

---

Pourquoi les tunnels impératifs ne conviennent pas à Kubernetes

Des outils comme la CLI ngrok, localtunnel, ou un proxy SSH inversé fait maison sont suffisants pour une session de débogage de dix minutes. En cluster, ils présentent trois problèmes :

• Pas de cycle de vie. Si un nœud est drainé ou un pod évincé, un tunnel lancé en processus détaché ou en sidecar non géré meurt avec lui. Kubernetes ne sait pas que le tunnel existe, donc rien ne le recrée.
• Pas de source de vérité. Le tunnel vit dans l’historique de shell de quelqu’un, pas dans Git. Le cluster et le dépôt s’écartent.
• Pas de visibilité. Vous ne pouvez pas kubectl get pour vérifier la santé d’un tunnel.

Exposer chaque service de façon traditionnelle (un LoadBalancer cloud, IP statiques, règles de firewall) est coûteux et souvent impossible sur des labs maison, clusters on-premises, sites en edge, ou laptops derrière NAT. C’est là que les tunnels gérés par opérateur comblent le vide.

Comment fonctionnent les tunnels gérés par opérateur

Le pattern partagé est simple :

1. Un agent ou un opérateur tourne dans votre cluster.
2. Il ouvre une connexion sortante vers l’edge du fournisseur, évitant ainsi une règle firewall entrante ou une IP publique.
3. Un contrôleur surveille des objets Kubernetes et configure le fournisseur via son API.
4. Si la connexion tombe ou si l’objet change, le contrôleur reconcilie. Si l’objet est supprimé, il nettoie.

Selon ce pattern, les outils diffèrent par ce que vous écrivez :

Outil	Ce que vous écrivez	Idéal pour	Avertissement
Webhook Relay Operator	ressource personnalisée WebhookRelayForward	Webhooks et callbacks API dans un cluster privé	Webhooks uniquement ; dernière version taguée 0.6.0 (novembre 2022)
Webhook Relay Ingress Controller	ressources de style Ingress (produit séparé)	Tunnels bidirectionnels vers des services comme Grafana ou Prometheus	Produit différent de l’Operator
ngrok Kubernetes Operator	CRDs AgentEndpoint / CloudEndpoint, Ingress, ou Gateway API	Ingress public complet avec politique edge (restrictions IP, limites de débit)	Nécessite un compte ngrok et un domaine réservé
Tailscale Kubernetes Operator	Ingress standard avec ingressClassName: tailscale, ou Service annoté	Accès privé au tailnet, avec exposition publique optionnelle via Funnel	Funnel a ports fixes et limites de bande passante
Cloudflare Tunnel	Déploiement cloudflared (officiel) ; opérateurs communautaires existants	Ingress HTTP(S) public sur le réseau Cloudflare	La voie officielle est un déploiement simple, pas un CRD
Pangolin (Newt)	Helm chart	Ingress tunnélisé en auto-hébergement	Newt est un agent déployé par Helm, pas un opérateur CRD
KubeSail	n/a	n/a	Arrêté

Webhook Relay : l’opérateur en forme de webhook

L’opérateur Webhook Relay est conçu pour une seule tâche : recevoir des webhooks et requêtes API (de GitHub, Stripe, Slack) dans un cluster sans IP publique ni load balancer. Son README mentionne déploiements on-premises, edge, et K3s comme environnements cibles. Il s’installe avec Helm et décrit les endpoints publics et destinations dans une ressource WebhookRelayForward.

Pour l’installation, fournir la clé et le secret du token Webhook Relay :

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

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

Puis déclarer le forward. Un champ inputs crée le point d’accès public, et outputs indique où vont les requêtes. Sans outputs, l’endpoint ne forwarde nulle part.

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: stripe-receiver
          lockPath: true
          destination: http://stripe-receiver.payment-services:8080/webhooks/stripe

Si plusieurs équipes partagent l’opérateur, vous pouvez sauter la gestion des credentials Helm et référencer un Secret dans chaque ressource via secretRefName (et éventuellement secretRefNamespace) dans spec. Le Secret contient key et secret pour le token d’accès Webhook Relay.

L’opérateur s’assure que le bucket, les inputs, et outputs existent, émet des événements Kubernetes, et écrit le statut dans la ressource. Récupérez l’URL publique à donner à l’expéditeur webhook :

kubectl get webhookrelayforwards.forward.webhookrelay.com stripe-webhook-forwarder \
  -n payment-services -o 'jsonpath={.status.publicEndpoints[0]}'

Deux notes pratiques :

• C’est le produit webhook, pas le général. La doc Webhook Relay décrit un contrôleur d’ingress séparé, recommandé pour ouvrir des tunnels bidirectionnels vers des services comme Grafana ou Prometheus. Ne vous attendez pas à ce que l’Operator expose des services arbitraires.
• Il est stable mais discret. La dernière version taguée est 0.6.0 (novembre 2022). La doc du fournisseur le recommande toujours pour faire passer des webhooks dans un cluster, mais fixez la version du chart et vérifiez le dépôt avant de l’utiliser pour un usage critique.

Quel que soit le transport, vérifiez la signature de l’expéditeur (pour Stripe, l’en-tête de signature) dans votre application. Le tunnel transmet la requête, il ne prouve pas qui l’a envoyée.

ngrok Kubernetes Operator : CRDs, Ingress, et Gateway API

L’opérateur ngrok est l’option la plus flexible de cette liste. Il propose deux ressources personnalisées natives, AgentEndpoint et CloudEndpoint. Il traduit aussi les ressources standard Ingress et Gateway API en ces deux types.

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

helm install ngrok-operator ngrok/ngrok-operator \
  --namespace ngrok-operator \
  --create-namespace \
  --set credentials.apiKey=$NGROK_API_KEY \
  --set credentials.authtoken=$NGROK_AUTHTOKEN

Il faut un compte ngrok et un domaine réservé. La façon la plus simple d’exposer est un AgentEndpoint unique :

apiVersion: ngrok.k8s.ngrok.com/v1alpha1
kind: AgentEndpoint
metadata:
  name: auth-service-endpoint
  namespace: dev
spec:
  url: https://VOTRE_DOMAINE_RESERVE
  upstream:
    url: http://auth-service.dev:8080

Puisque la politique d’endpoint fait partie de la ressource, la sécurité peut aussi vivre dans Git. Ajoutez une liste blanche IP :

spec:
  url: https://VOTRE_DOMAINE_RESERVE
  upstream:
    url: http://auth-service.dev:8080
  trafficPolicy:
    inline:
      on_http_request:
        - actions:
            - type: restrict-ips
              config:
                enforce: true
                allow:
                  - 203.0.113.10

Pour plusieurs services derrière un seul nom d’hôte, ngrok associe un CloudEndpoint public à des AgentEndpoints internes et route entre eux via l’action forward-internal de Traffic Policy. Si vous utilisez Gateway API, chaque hostname de Gateway devient un CloudEndpoint, et chaque service en amont référencé par un HTTPRoute devient un AgentEndpoint interne. Les filtres de miroir de requêtes ne sont pas encore supportés.

Tailscale Kubernetes Operator : Ingress standard, privé par défaut

L’opérateur Tailscale adopte une approche différente : pas besoin de CRD spécifique pour une exposition basique. Utilisez un Ingress standard avec ingressClassName: tailscale, et l’opérateur crée des pods proxy qui transfèrent le trafic vers votre Service. Une installation par défaut crée aussi une classe tailscale et des CRDs comme ProxyClass, Connector, ProxyGroup, DNSConfig, et Recorder.

Installez avec Helm après avoir créé un client OAuth et des tags dans la console d’administration :

helm repo add tailscale https://pkgs.tailscale.com/helmcharts
helm repo update

helm upgrade --install tailscale-operator tailscale/tailscale-operator \
  --namespace=tailscale --create-namespace \
  --set-string oauth.clientId="<ID_CLIENT_OAUTH>" \
  --set-string oauth.clientSecret="<SECRET_CLIENT_OAUTH>" \
  --wait

Un Ingress seul expose le service seulement à votre tailnet. Pour accéder à internet, utilisez l’annotation tailscale.com/funnel :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: auth-service-funnel
  namespace: dev
  annotations:
    tailscale.com/funnel: "true"
spec:
  ingressClassName: tailscale
  defaultBackend:
    service:
      name: auth-service
      port:
        number: 8080
  tls:
    - hosts:
        - auth-dev

La valeur tls.hosts devient le nom MagicDNS, par exemple auth-dev.<votre-tailnet>.ts.net. Vérifiez avec kubectl get ingress et lisez la colonne ADDRESS.

Funnel impose des contraintes :

• Peut utiliser uniquement des DNS sous le domaine ts.net de votre tailnet.
• N’écoute que sur les ports 443, 8443, et 10000, en TLS uniquement.
• Le trafic est soumis à des limites de bande passante non configurables.
• La politique du tailnet doit autoriser Funnel (attribut funnel), et MagicDNS et HTTPS doivent être activés.

Pour la production, Tailscale recommande le mode haute disponibilité : un ProxyGroup avec plusieurs réplicas plutôt qu’un seul proxy. Pensez aussi aux limites de certificats lors de la création de nombreux noms d’hôte temporaires. L’opérateur fournit des certificats via Let’s Encrypt, avec une limite de 50 certificats par semaine pour des noms d’hôte uniques. La doc recommande un ProxyClass utilisant l’environnement de staging de Let’s Encrypt pour tester.

Une propriété de sécurité importante : Tailscale indique que les serveurs relais Funnel transfèrent le flux chiffré sans le déchiffrer, TLS étant terminé sur votre propre nœud.

Cloudflare Tunnel et Pangolin

Cloudflare Tunnel. Le guide officiel Cloudflare pour Kubernetes exécute cloudflared en déploiement ordinaire, authentifié avec un token de tunnel stocké dans un Secret. Il recommande de faire tourner cloudflared dans un déploiement séparé, à côté de vos déploiements d’applications, pour une scalabilité indépendante. Les réplicas partagent la charge, chaque réplica pouvant atteindre tous les services du cluster. Cloudflare déconseille l’autoscaling de cloudflared, car la suppression d’un réplica coupe ses connexions. Pour des tunnels et DNS en CRD, des projets communautaires comme adyanth/cloudflare-operator proposent des CRDs Tunnel et TunnelBinding, mais ce projet est en alpha.

Pangolin. Pangolin est un reverse proxy tunnélisé auto-hébergé. Son agent Kubernetes, Newt, se déploie via Helm (version 1.4.0 au moment) et nécessite Kubernetes 1.30.14 ou plus récent. La documentation de Pangolin liste Helm, Kustomize, et GitOps (Argo CD, Flux) comme méthodes d’installation supportées, avec un exemple HelmRelease pour Newt. Le chart du serveur Pangolin est encore en pré-release, donc fixez la version exacte. La doc recommande de garder les credentials de Newt dans un Secret existant, plutôt que dans les valeurs Helm.

Qu’est-il arrivé à KubeSail

Les anciennes versions de ce sujet (y compris une version antérieure de cet article) présentaient KubeSail comme le modèle : opérateur maison qui surveille des ressources Ingress standard et donne à chacune un sous-domaine public avec TLS. KubeSail a fermé. Son site affiche un avis d’adieu, et les retours communautaires évoquent la fin des gateways hébergées vers mi-septembre 2025. Un message des fondateurs, reposté sur Lemmy, recommande Tailscale Funnel et Cloudflare Tunnel pour l’accès distant.

Si vous trouvez un guide vous disant d’installer l’agent KubeSail, considérez-le comme obsolète. Le workflow qu’il popularisait (écrire un Ingress normal, obtenir une URL publique) est repris par l’opérateur Tailscale.

Minikube : trois choses différentes appelées “tunnel”

Tester des callbacks OAuth ou webhooks tiers sur un cluster local est un cas classique, et les commandes Minikube peuvent prêter à confusion :

• minikube service ouvre des services NodePort. La doc indique que, avec le driver Docker, cela fonctionne en lançant un processus SSH qui forwarde un port local vers le service. La plage NodePort par défaut est 30000-32767.
• minikube tunnel crée une route sur votre machine vers des services LoadBalancer et leur attribue une IP externe. Il doit rester actif, et l’arrêter (Ctrl+C) supprime l’accès. Il rend les services accessibles depuis votre machine locale, pas sur internet.
• L’add-on Ingress + modifications hosts fonctionne pour un domaine que votre machine résout seul.

Aucun de ces moyens ne donne une URL publique à un collègue ou un webhook tiers. Pour cela, utilisez un des opérateurs ci-dessus dans Minikube. Avec ngrok, utilisez l’AgentEndpoint montré plus tôt, et ngrok fournit un guide pour clusters locaux. Avec Tailscale, le Ingress Funnel fonctionne tel quel, si le cluster peut atteindre le réseau Tailscale.

Puisque le tunnel est défini par une ressource, son cycle de vie suit celle-ci. kubectl delete sur l’AgentEndpoint ou l’Ingress ferme l’endpoint public, sans laisser un terminal ouvert.

GitOps : tunnels à côté de vos déploiements

Les définitions de tunnels en YAML peuvent cohabiter avec vos Deployment et Service dans le même dépôt, et Argo CD ou Flux les appliquent ensemble. En cas de reconstruction du cluster, réappliquer le dépôt recrée opérateurs et ressources personnalisées, et les tunnels reviennent.

Le piège principal est l’ordre. Une ressource personnalisée ne peut pas être appliquée avant que son CRD existe. Dans Argo CD, le CRD arrive souvent avec le chart Helm de l’opérateur, et le dry-run échoue avec “le serveur n’a pas trouvé la ressource demandée” si le CRD n’est pas encore dans le cluster. Deux astuces : placer l’opérateur dans une vague de synchronisation antérieure (ou une application séparée) que les ressources qui en dépendent, et ajouter l’option SkipDryRunOnMissingResource dans la synchronisation :

apiVersion: forward.webhookrelay.com/v1
kind: WebhookRelayForward
metadata:
  name: stripe-webhook-forwarder
  namespace: payment-services
  annotations:
    argocd.argoproj.io/sync-wave: "2"
    argocd.argoproj.io/sync-options: SkipDryRunOnMissingResource=true

La doc d’Argo CD précise que le dry run s’exécute quand le CRD est déjà là, donc cette option ne relâche la vérification que pour la première installation.

Garder les credentials hors Git. Chaque opérateur nécessite un token, une clé API ou un secret OAuth. Stockez-les dans un Secret créé hors ligne ou via un gestionnaire de secrets, et référencez-les dans vos manifests.

Sécurité : ce que le mode outbound-only apporte et ce qu’il ne fait pas

Les connexions outbound-only sont une vraie amélioration. Pas de ports entrants à ouvrir, pas de LoadBalancer cloud par service. Mais certaines affirmations doivent être nuancées :

• Le hostname public reste public. Le réseau du cluster est fermé, mais l’URL publiée est accessible à tous sauf si vous ajoutez un contrôle d’accès. La politique Traffic de ngrok (ex. restrict-ips) peut l’ajouter à la périphérie, une vérification applicative en est une autre. La surface DDoS se déplace vers le fournisseur et votre hostname ; elle ne disparaît pas.
• TLS est terminé sur votre nœud. Les fournisseurs qui appliquent une politique au niveau de la requête doivent déchiffrer HTTP, donc ils voient le contenu en clair. C’est une décision de confiance à faire consciemment. Tailscale Funnel est une exception, TLS y se termine sur votre propre nœud.
• Le filtrage en edge n’est pas de la sanitisation. Ne supposez pas que le trafic passant par un tunnel est authentifié ou propre. Validez les entrées et signatures dans l’application.
• RBAC ne fait que limiter, jamais refuser. Vous pouvez restreindre la création de ressources de tunnel à dev et staging en n’accordant les permissions que là, pas en refusant dans production. Pour des règles plus fines (ex. quels hostnames un namespace peut réclamer), utilisez une ValidatingAdmissionPolicy, disponible depuis Kubernetes 1.30.
• Les tokens sont des identifiants porteurs. Toute personne possédant un token de tunnel peut faire tourner son propre agent. Limitez et faites tourner régulièrement.

Choisir une approche

• Besoin uniquement de webhooks dans un cluster privé ? L’Operator Webhook Relay est conçu pour ça.
• Veux un ingress public complet avec politique edge en Git ? L’operator ngrok, avec AgentEndpoint, Ingress, ou Gateway API.
• Principalement besoin d’accès privé, avec URL publique occasionnelle ? L’operator Tailscale, en traitant Funnel comme une exception délibérée.
• Déjà sur Cloudflare ? Faites tourner cloudflared en Deployment, et ne regardez que les opérateurs communautaires si vous acceptez un logiciel alpha.
• Voulez auto-héberger l’edge ? Pangolin avec le Helm chart Newt.
• Voulez utiliser KubeSail ? Ce n’est plus possible. La plateforme a fermé.

La tendance est claire : déclarez vos services, laissez un contrôleur maintenir la connexion, et versionnez tout. Les détails diffèrent selon l’outil, vérifiez la doc actuelle avant de vous engager. Le domaine évolue rapidement, comme la fermeture de KubeSail l’a montré.

---

Sources

• Webhook Relay Operator : https://github.com/webhookrelay/webhookrelay-operator et https://webhookrelay.com/docs/installation/kubernetes/
• ngrok Kubernetes Operator : https://ngrok.com/docs/getting-started/kubernetes/crds et https://ngrok.com/docs/k8s/guides/using-gwapi
• Tailscale Kubernetes Operator : https://tailscale.com/docs/kubernetes-operator/install-operator et https://tailscale.com/docs/kubernetes-operator/ingress
• Tailscale Funnel avec Kubernetes : https://tailscale.com/docs/kubernetes-operator/ingress/expose-workload-to-internet
• Tailscale Funnel (limites et comportement TLS) : https://tailscale.com/docs/features/tailscale-funnel et https://tailscale.com/blog/tailscale-funnel-beta
• Cloudflare Tunnel sur Kubernetes : https://developers.cloudflare.com/tunnel/deployment-guides/kubernetes/
• Opérateur communautaire Cloudflare : https://github.com/adyanth/cloudflare-operator
• Pangolin Helm et Newt : https://docs.pangolin.net/self-host/manual/kubernetes/helm et https://docs.pangolin.net/self-host/manual/kubernetes/newt/helm
• Fin de KubeSail : https://kubesail.com/ et discussion communautaire https://lemmy.world/post/38039322
• Minikube : https://minikube.sigs.k8s.io/docs/handbook/accessing/ et https://minikube.sigs.k8s.io/docs/commands/tunnel/
• Options de synchronisation Argo CD : https://argo-cd.readthedocs.io/en/release-2.9/user-guide/sync-options/
• ValidatingAdmissionPolicy GA : https://kubernetes.io/blog/2024/04/24/validating-admission-policy-ga/

---

Notes de mise à jour (à retirer avant publication)

Corrections majeures

1. KubeSail est arrêté. La version initiale décrivait l’opérateur, les sous-domaines my-app.kubesail.io, et TLS en mode présent. La page d’accueil affiche un avis d’adieu, et les retours communautaires évoquent la fin des gateways hébergées vers mi-septembre 2025. La section est remplacée par une courte note “ce qui s’est passé”, et le rôle d’Ingress via Ingress standard est repris par l’opérateur Tailscale.
2. Le CRD LocalTunnel (tunneling.example.com/v1alpha1) était un placeholder, pas un vrai produit. L’exemple Minikube est remplacé par des manifests réels : un AgentEndpoint ngrok et un Ingress Funnel Tailscale.
3. Le manifest Webhook Relay était incomplet. Il avait un inputs (endpoint public) mais pas de outputs, donc il ne forwardait nulle part. Ajout du bloc outputs avec destination, lockPath, et responseStatusCode. La référence secretRefName est valide : la documentation du projet le mentionne (avec secretRefNamespace optionnel) pour des credentials par ressource dans un environnement multi-tenant. La erreur était de le présenter comme seul mode ; les credentials Helm étant la norme. La commande de statut a été corrigée pour utiliser le nom complet de la ressource selon la doc Webhook Relay.
4. minikube tunnel confondu avec exposition publique. minikube tunnel route les services LoadBalancer vers la machine locale ; minikube service ouvre un NodePort. Aucun ne donne une URL publique. La rédaction a été ajustée.

Avertissements exagérés atténués

1. “Immunisé contre scan de ports, DDoS, et attaques par force brute” supprimé. Le hostname publié reste public, et la surface d’attaque se déplace vers le fournisseur.
2. “Le trafic qui atteint le service est déjà déchiffré, authentifié, et nettoyé” supprimé. La terminaison TLS en edge signifie que le fournisseur voit le contenu en clair (sauf Tailscale Funnel). La filtration en edge ne remplace pas la validation applicative.
3. “Interdire strictement la création de CRs de tunneling en prod” corrigé. Kubernetes RBAC est additif ; il faut limiter, pas refuser. Ajout d’une ValidatingAdmissionPolicy (GA 1.30) pour règles fines.
4. Ajout d’informations sur la version Webhook Relay : dernière version 0.6.0, novembre 2022, alors que la doc officielle le recommande toujours.

Contenu ajouté

1. Nouvelles sections sur l’opérateur ngrok (AgentEndpoint, CloudEndpoint, Ingress, Gateway API ; gratuit ; domaine réservé requis), l’opérateur Tailscale (classe Ingress, annotation Funnel, HA avec ProxyGroup, limites de ports/bande passante, limites de certificats), Cloudflare Tunnel (déploiement officiel, pas d’autoscaling, alpha), et Pangolin avec le Helm Newt (version 1.4.0, Kubernetes 1.30.14+).
2. Clarification que Webhook Relay Operator et son Ingress Controller sont des produits séparés.
3. Ajout du problème d’ordre de CRD dans Argo CD (SkipDryRunOnMissingResource, vagues de synchronisation) et gestion des secrets.
4. Ajout d’un tableau de décision et d’un guide.

Ce qui n’a pas été vérifié / volontairement omis

• Tarification actuelle et limites gratuites pour chaque fournisseur (évolutif, lien vers pages tarifaires).
• Si Funnel de Tailscale est toujours en beta ; l’article ne le dit pas.
• Fonctionnalités récentes de Webhook Relay hors Operator et Ingress Controller.