ArgoCD CLI cassé avec Cilium Gateway? Utilise le TLS passthrough

L’UI ArgoCD marchait nickel sur https://lab.sofianedjerbi.com/argo/. Le CLI plantait:

argocd login lab.sofianedjerbi.com --grpc-web --grpc-web-root-path /argo
# Error: POST https://lab.sofianedjerbi.com/argo/session.SessionService/Create failed with status code 404

Les requêtes directes via port-forward renvoyaient HTTP 200. Les mêmes requêtes via Cilium Gateway renvoyaient 404. Le gateway faisait quelque chose au trafic

Le filtre caché

Cilium Gateway inclut envoy.filters.http.grpc_web activé par défaut. Ce filtre:

1. Détecte les requêtes gRPC-web via Content-Type: application/grpc-web+proto
2. Les convertit en gRPC natif avant de les transférer
3. S’attend à ce que le backend parle gRPC natif sur HTTP/2

ArgoCD avec server.insecure: true tourne en mode HTTP. Il accepte uniquement le gRPC-web sur HTTP/1.1, pas le gRPC natif. Quand Cilium convertit le protocole, ArgoCD ne comprend pas et renvoie 404

J’ai trouvé ça après avoir creusé: cilium/cilium#31933

Ce qui n’a pas marché

Approche	Résultat	Pourquoi
URLRewrite /argo/* vers /*	404 pour gRPC	Le filtre convertit toujours
Sous-domaine dédié	Toujours 404	Même filtre, le path n’était pas le souci
Patcher CiliumEnvoyConfig	Rejeté	Je voulais tout en code
HTTPS avec HTTPRoute	Boucles de redirect	Cilium ne supporte pas BackendTLSPolicy

Le TLS passthrough règle tout

Rends le trafic opaque pour Cilium. Il ne peut pas inspecter ni modifier les paquets chiffrés

1. ArgoCD tourne avec TLS activé (server.insecure: false) sur le port 443
2. Le listener Gateway utilise protocol: TLS avec mode: Passthrough
3. TLSRoute transfère le trafic chiffré directement à ArgoCD
4. ArgoCD termine le TLS et gère le gRPC natif sur HTTP/2
5. cert-manager fournit le certificat Let’s Encrypt

La configuration

Le listener Gateway:

listeners:
  - name: argo-tls
    protocol: TLS
    port: 443
    hostname: argo.lab.sofianedjerbi.com
    tls:
      mode: Passthrough
    allowedRoutes:
      kinds:
        - kind: TLSRoute

La TLSRoute:

apiVersion: gateway.networking.k8s.io/v1alpha2
kind: TLSRoute
metadata:
  name: argocd
spec:
  parentRefs:
    - name: cilium-gateway
      sectionName: argo-tls
  hostnames:
    - argo.lab.sofianedjerbi.com
  rules:
    - backendRefs:
        - name: argocd-server
          port: 443

Les valeurs Helm ArgoCD:

configs:
  params:
    server.insecure: false

server:
  certificate:
    enabled: true
    domain: argo.lab.sofianedjerbi.com
    issuer:
      kind: ClusterIssuer
      name: letsencrypt-prod

Pourquoi ça marche

HTTPRoute (TLS termination)	TLSRoute (passthrough)
Le Gateway termine le TLS	Le Gateway transfère les paquets chiffrés
Envoy inspecte les headers HTTP	Envoy ne peut pas inspecter le contenu
Le filtre grpc-web s’active	Pas de traitement L7 possible
Convertit gRPC-web en gRPC natif	Le trafic passe tel quel
ArgoCD (mode HTTP) perd les pédales	ArgoCD termine le TLS, gère le gRPC

Le truc: ArgoCD en mode TLS supporte le gRPC natif sur HTTP/2. HTTP/2 est naturellement disponible sur les connexions TLS. Le même ArgoCD qui plante avec gRPC-web en mode HTTP marche parfaitement avec le gRPC natif en mode TLS

Le pattern

Quand un proxy Layer 7 interfère avec ton protocole, descends au Layer 4

Le filtre grpc-web de Cilium ne peut pas être désactivé via Gateway API. Plutôt que de patcher les configs Envoy, le TLS passthrough rend le trafic invisible. Le flux chiffré passe sans être touché

Ça s’applique aux WebSockets, gRPC, protocoles binaires custom. Si ton proxy L7 casse un protocole, pense au passthrough L4. Tu échanges le routage par headers et les logs au niveau gateway contre l’intégrité du protocole

Parfois la solution c’est d’empêcher le proxy de t’aider