Terminaison TLS avec les Ingress

Sécuriser le trafic entrant : le besoin de HTTPS

Exposer des services web via HTTP est simple, mais dans le monde d'aujourd'hui, ce n'est généralement pas suffisant. Pour protéger la confidentialité et l'intégrité des données échangées entre les clients et vos applications, il est essentiel d'utiliser HTTPS (HTTP Secure). HTTPS chiffre le trafic en utilisant le protocole TLS (Transport Layer Security), anciennement SSL.

Comment mettre en place HTTPS pour les applications exposées via un Ingress Kubernetes ? Faut-il que chaque Pod gère son propre certificat TLS et effectue le déchiffrement ? Bien que possible, cette approche est complexe à gérer (distribution et renouvellement des certificats dans tous les Pods). Une approche beaucoup plus courante et pratique est la terminaison TLS au niveau de l'Ingress.

Cela signifie que le contrôleur Ingress (le proxy inverse) gère le certificat TLS, déchiffre le trafic HTTPS entrant provenant du client, puis transmet la requête (souvent en HTTP simple non chiffré) aux Services et Pods internes du cluster. Le trafic à l'intérieur du cluster peut rester non chiffré (plus simple) ou être re-chiffré si nécessaire (sécurité accrue).

Le rôle du Secret TLS

Pour que le contrôleur Ingress puisse terminer la connexion TLS, il a besoin de deux éléments : le certificat TLS public (qui sera présenté aux clients) et la clé privée correspondante (utilisée pour déchiffrer le trafic). Ces deux éléments sont des données extrêmement sensibles, en particulier la clé privée.

Où stocker ces données de manière sécurisée dans Kubernetes ? La réponse est, comme nous l'avons vu pour d'autres données sensibles : dans un objet Secret.

Kubernetes définit un type spécifique de Secret pour cet usage : `kubernetes.io/tls`. Un Secret de ce type doit contenir au moins deux clés :

• `tls.crt` : Contient le certificat public (et potentiellement la chaîne de certificats intermédiaires), encodé en Base64.
• `tls.key` : Contient la clé privée correspondante, encodée en Base64.

Vous pouvez créer ce Secret manuellement avec `kubectl create secret tls` (comme vu précédemment) ou via un manifeste YAML, en fournissant vos fichiers de certificat et de clé (généralement obtenus auprès d'une autorité de certification (CA) ou auto-signés pour le développement).

kubectl create secret tls mon-tls-secret --cert=chemin/vers/tls.crt --key=chemin/vers/tls.key -n mon-namespace

Le contrôleur Ingress sera configuré (via RBAC) pour avoir les permissions de lire ces Secrets de type `kubernetes.io/tls` afin de récupérer les certificats et clés nécessaires.

Configuration de la terminaison TLS dans l'Ingress

Une fois que vous avez créé le Secret contenant votre certificat et votre clé, vous pouvez configurer l'Ingress pour l'utiliser. Cela se fait via la section `spec.tls` de l'objet Ingress.

La section `spec.tls` est une liste, où chaque élément spécifie :

• `hosts` : Une liste des noms d'hôtes (ceux définis dans les `spec.rules`) qui doivent être sécurisés avec ce certificat. Le nom d'hôte demandé par le client doit correspondre à l'un de ceux listés ici et être couvert par le certificat.
• `secretName` : Le nom du Secret (de type `kubernetes.io/tls`) qui contient le certificat et la clé à utiliser pour les hôtes spécifiés. Ce Secret doit exister dans le même Namespace que l'objet Ingress.

Exemple YAML :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: tls-example-ingress
  namespace: production
spec:
  tls:
  - hosts:
    - monapp.example.com # Hôte(s) à sécuriser
    secretName: mon-tls-secret # Nom du Secret contenant cert/key
  rules:
  - host: "monapp.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: mon-app-service
            port:
              number: 8080
  # Optionnel: Redirection HTTP vers HTTPS (souvent via annotations)
  # annotations:
  #   nginx.ingress.kubernetes.io/force-ssl-redirect: "true"

Dans cet exemple :

1. L'Ingress `tls-example-ingress` dans le namespace `production` est configuré pour gérer le trafic TLS.
2. Pour les requêtes vers l'hôte `monapp.example.com`, il utilisera le certificat et la clé stockés dans le Secret `mon-tls-secret` (qui doit aussi être dans le namespace `production`).
3. Le contrôleur Ingress gérera la poignée de main TLS (handshake).
4. Une fois le trafic déchiffré, la règle de routage sous `rules` s'appliquera comme d'habitude, envoyant le trafic vers `mon-app-service` sur le port 8080 (probablement en HTTP simple, sauf configuration contraire du contrôleur Ingress).

Vous pouvez avoir plusieurs entrées dans la liste `spec.tls` pour utiliser différents certificats pour différents hôtes, si nécessaire.

Gestion des certificats et automatisation (Let's Encrypt)

Obtenir et gérer les certificats TLS peut être fastidieux, surtout leur renouvellement. Heureusement, l'écosystème Kubernetes offre des solutions pour automatiser ce processus, notamment avec Let's Encrypt, une autorité de certification gratuite et automatisée.

L'outil le plus populaire pour cela est cert-manager. C'est un contrôleur Kubernetes dédié à la gestion des certificats. Vous le déployez dans votre cluster, puis vous créez des ressources personnalisées (CRDs) comme `Issuer` (ou `ClusterIssuer`) pour définir comment obtenir des certificats (par exemple, via le protocole ACME de Let's Encrypt) et `Certificate` pour demander un certificat spécifique pour certains domaines.

Cert-manager interagit alors avec l'autorité de certification (comme Let's Encrypt), valide la propriété du domaine (via des challenges HTTP-01 ou DNS-01, souvent en s'intégrant avec votre contrôleur Ingress ou votre fournisseur DNS), obtient le certificat et la clé, et les stocke automatiquement dans un Secret Kubernetes (de type `kubernetes.io/tls`). Il gère également le renouvellement automatique avant l'expiration.

En utilisant cert-manager, vous pouvez simplement annoter votre objet Ingress ou créer un objet `Certificate` en spécifiant les hôtes et le nom du Secret désiré, et cert-manager s'occupe du reste. Votre section `spec.tls` dans l'Ingress référence ensuite le `secretName` géré par cert-manager.

Conclusion : trafic web sécurisé et simplifié

La terminaison TLS au niveau de l'Ingress est la méthode standard et recommandée pour sécuriser le trafic HTTP entrant dans votre cluster Kubernetes. En utilisant des Secrets de type `kubernetes.io/tls` pour stocker les certificats et clés, et en configurant la section `spec.tls` de l'objet Ingress, vous demandez au contrôleur Ingress de gérer le chiffrement et le déchiffrement pour vous.

Cette approche centralise la gestion des certificats, simplifie la configuration des applications backend (qui peuvent souvent écouter en HTTP simple), et peut être largement automatisée grâce à des outils comme cert-manager pour l'obtention et le renouvellement des certificats via Let's Encrypt.

Maîtriser la configuration TLS des Ingress est donc une compétence essentielle pour déployer des applications web sécurisées et professionnelles sur Kubernetes.