Logo comoweb.fr
comoweb.fr EPITA ING 1
Retour aux articles
Réseau

Architecture Ingress & Edge Proxy : Zoraxy en amont du cluster Kubernetes

Pourquoi j'ai choisi de découpler la terminaison TLS sur un reverse proxy Zoraxy en amont, supprimant le besoin de cert-manager dans Kubernetes.

Architecture d'Ingress : Pourquoi Zoraxy en bordure ?

Dans une infrastructure Kubernetes de production ou de laboratoire, la question de la gestion des certificats TLS et de l'exposition des services est primordiale. Traditionnellement, beaucoup d'architectures s'appuient sur cert-manager déployé au sein même du cluster avec des ingress annotations et des challenges HTTP-01 ou DNS-01.

Sur comoweb.fr, j'ai fait le choix architectural délibéré de ne pas utiliser cert-manager dans Kubernetes, mais de déléguer l'ensemble de la terminaison TLS et du routage frontal à un reverse proxy Zoraxy dédié en amont.

CODE 
                 Internet (Dual WAN : Free & Numericable)
                                   │
                                   ▼
                   2x Cisco ISR 1100 (HSRP Gateway)
                                   │
                                   ▼
                    Stack 2x Cisco Catalyst 3650-24P
                                   │
                                   ▼
                    Pare-feu OPNsense (DMZ & Filtrage)
                                   │
                                   ▼
              ┌─────────────────────────────────────────┐
              │      Zoraxy Edge Reverse Proxy          │
              │  - Terminaison TLS Let's Encrypt global │
              │  - WAF & Redirection L7                 │
              │  - Zéro Cert-Manager dans les pods      │
              └────────────────────┬────────────────────┘
                                   │
                      VIP Interne (MetalLB)
                                   ▼
               Ingress-NGINX Controller (Cluster K8s)
                                   │
                                   ▼
                         Pods Applicatifs

Les avantages de cette approche

  1. Suppression de cert-manager dans Kubernetes :

    • Évite de surcharger les clusters avec des CRDs complexes (Issuer, ClusterIssuer, Certificate, Challenge, Order).
    • Aucune dépendance d'API tokens DNS injectés dans les pods du cluster pour les challenges DNS Let's Encrypt.
    • Les plans de contrôle Kubernetes restent ultra-légers et focalisés sur la logique métier.

  2. Point d'entrée unique pour toute l'infrastructure :

    • Zoraxy ne route pas seulement vers Kubernetes : il permet également d'exposer ou de sécuriser les interfaces d'administration hors-cluster (Proxmox VE, GitLab, OPNsense, Authentik, etc.) sous des sous-domaines propres avec certificats valides.

  3. Séparation nette des responsabilités (SOC & Ops) :

    • La bordure L7 s'occupe de la négociation TLS (TLS 1.3, chiffrement moderne, certificats wildcard).
    • L'Ingress-NGINX interne au cluster ne reçoit que du trafic déjà déchiffré ou ré-aiguillé proprement sur le réseau privé.

Configuration du routage vers MetalLB

Le contrôleur MetalLB attribue une adresse IP VIP interne à notre contrôleur Ingress-NGINX. Zoraxy achemine ensuite les requêtes HTTP/HTTPS vers cette VIP :

YAML 
# Exemple de configuration Ingress K8s interne simplifiée (sans annotation cert-manager)
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: site-vitrine-ingress
  namespace: comoweb-prod
spec:
  ingressClassName: nginx
  rules:
    - host: comoweb.fr
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: site-vitrine-service
                port:
                  number: 80

Grâce à ce découplage, la gestion des certificats est centralisée, auditée et d'une fiabilité totale.