Configurer SSL/TLS pour l’Ingress de Kubernetes

Aujourd’hui, les applications web et mobiles ainsi que les points de terminaison de microservices basés sur des API sont devenus la norme. Ces applications sont accessibles via le protocole web HTTP. Le chiffrement fourni par Secure Sockets Layer ou Transport Layer Security (SSL/TLS) est indispensable pour sécuriser les communications entre le client et le serveur, ainsi qu’avec les back-ends d’API.

SSL/TLS désigne des mécanismes de chiffrement reposant sur des certificats. SSL est la norme depuis plus de 20 ans. TLS est une évolution plus sécurisée de SSL, qui s’appuie sur le même principe, mais utilise des mécanismes de chiffrement plus stricts.

Les certificats TLS peuvent être autosignés par l’autorité de certification interne d’une organisation, ou signés par l’une des nombreuses autorités de certification publiques, telles que GoDaddy, DigiCert, Symantec, GlobalSign et Let’s Encrypt. Lorsque les communications fondées sur IP sont chiffrées, le trafic est protégé contre les attaquants qui tentent d’inspecter les paquets de données.

Dans un environnement Kubernetes, les conteneurs de workloads s’exécutent au sein du réseau Kubernetes. Ils sont généralement exposés au monde extérieur (en ligne) à l’aide d’un contrôleur Ingress HTTP : un service basé sur une API qui achemine le trafic vers les pods. Pour garantir la sécurité dans ce scénario, nous devons ajouter une configuration de chiffrement SSL/TLS au cluster Kubernetes.

Tous les scénarios courants impliquant un échange de données — par exemple, l’envoi d’identifiants de connexion, la consultation de données confidentielles comme les clés d’accès aux applications et aux points de terminaison de stockage, les chaînes de connexion aux bases de données, etc. — bénéficient toujours d’un chiffrement sécurisant les échanges.

Cet article explique comment configurer des certificats TLS/SSL avec le contrôleur Ingress de Kubernetes. Nous allons configurer un contrôleur Ingress NGINX, créer un certificat SSL/TLS autosigné, définir les règles nécessaires pour associer le certificat SSL/TLS au contrôleur, puis le relier au service d’une application Kubernetes de démonstration.

Configuration des certificats TLS/SSL

Avant de commencer, vérifiez que vous disposez d’un environnement Kubernetes opérationnel sur votre machine locale (par exemple, Docker avec Kubernetes ou MiniKube) ou dans un environnement cloud hébergé, comme Azure (AKS), AWS (EKS), GCP (GKS) ou Ocean (DOKS), avec Helm installé.

Cette démonstration utilise un déploiement Azure Kubernetes Service par défaut, comme indiqué dans cet article Microsoft Learn, avec un abonnement Azure gratuit. Toutefois, la plupart des étapes sont propres à Kubernetes plutôt qu’au fournisseur cloud : vous pouvez donc suivre ce guide quel que soit l’environnement d’hébergement Kubernetes utilisé.

Création du contrôleur Ingress

Commençons par injecter la configuration du contrôleur Ingress dans le cluster Kubernetes. Plusieurs options sont disponibles, notamment NGINX, Google Cloud Load Balancer, Traefik et Contour. Cet article utilise NGINX, un contrôleur Ingress bien connu et relativement simple à configurer. Il est proposé par la communauté Kubernetes ingress-nginx sur GitHub.  

Outre les différents contrôleurs Ingress, il existe plusieurs méthodes pour les installer, comme Helm ou kubectl. Pour cette démonstration, nous utiliserons Helm, qui fonctionne avec toutes les architectures Kubernetes.

Le déploiement comprend les étapes suivantes :

• Définir le nom d’un nouvel espace de noms Kubernetes, qui sera utilisé par le contrôleur Ingress. C’est le rôle de la variable NAMESPACE.

• Télécharger le package du contrôleur ingress-nginx à l’aide de la commande helm repo add.

• Écrire la configuration à mettre à jour avec helm repo update.

• Installer le package à l’aide de la commande helm install.

Comme cet exemple utilise Azure et Azure Load Balancer, la commande helm install est complétée pour définir une intégration avec les sondes d’intégrité d’Azure Load Balancer. Cette configuration varie selon votre environnement Kubernetes (sur site, Azure, AWS, GCP, etc.).

Dans la ligne de commande, exécutez la commande suivante :

1NAMESPACE=ingress-nginx
2
3helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
4helm repo update
5
6helm install ingress-nginx ingress-nginx/ingress-nginx \
7  --create-namespace \
8  --namespace $NAMESPACE \
9  --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz

L’image ci-dessous montre la commande helm complète :

Le résultat de la création du contrôleur NGINX ressemblera à l’image ci-dessous :

Vérifiez ensuite l’installation du contrôleur Ingress à l’aide de la commande ci-dessous :

1kubectl --namespace ingress-nginx get services -o wide -w ingress-nginx-controller

L’image ci-dessous montre la réponse à la commande précédente.

Dans votre navigateur, accédez à l’EXTERNAL-IP indiquée pour ingress-nginxcontroller. Nous n’avons pas encore défini de règles Ingress, car nous n’acheminons pas le trafic vers un service d’application réel : vous obtiendrez donc une erreur HTTP 404. Vous pouvez toutefois constater que le contrôleur NGINX répond.

Sur Mac, l’adresse IP externe peut s’afficher sous la forme « localhost » plutôt que d’un numéro IP.

En cliquant sur le message Non sécurisé, vous constaterez qu’aucun certificat n’est utilisé :

Essayez maintenant de vous connecter à nouveau à la même adresse IP, cette fois en HTTPS. Le navigateur affichera un avertissement indiquant que la connexion n’est pas sûre et qu’il est déconseillé de continuer, comme ci-dessous :

Cliquez sur le bouton Paramètres avancés, puis sur Continuer vers .

Dans le même onglet Non sécurisé, cliquez sur le logo du certificat indiqué ci-dessous :

Les détails du certificat fictif intégré au contrôleur Ingress s’affichent, comme ci-dessous. C’est ce certificat que nous allons remplacer.

Choix d’un certificat SSL/TLS

Il existe plusieurs façons d’obtenir des certificats SSL/TLS :

• Autosigné : ce type de certificat est généralement utilisé à des fins internes et repose sur l’autorité de certification (CA) de votre propre infrastructure à clés publiques (PKI).

• Acheté auprès d’une autorité de certification publique : généralement utilisé pour les applications accessibles depuis l’Internet public, ce certificat SSL/TLS est acheté par les organisations auprès d’une autorité de certification publique, comme GlobalSign, Symantec, DigiCert ou GoDaddy. Le principal avantage d’une CA publique est que les certificats racines, qui valident tous les certificats émis, sont reconnus comme fiables par les navigateurs modernes. Les certificats sont généralement valides pendant un à cinq ans.

• Let’s Encrypt : Let’s Encrypt est un projet à but non lucratif. La principale différence entre les CA publiques et Let’s Encrypt est que les certificats SSL/TLS sont gratuits. De plus, les certificats Let’s Encrypt ne sont valides que pendant trois mois.

Outre le type de certificat SSL/TLS, il faut tenir compte des tâches de maintenance, comme la rotation des certificats et des clés. Pour le cas d’utilisation de Kubernetes et du contrôleur Ingress présenté dans cet article, vous pouvez planifier la création d’un nouveau certificat SSL/TLS et configurer des tâches cron sur votre cluster Kubernetes pour créer de nouveaux Secrets. Il est également important de choisir une période de validité adaptée pour les certificats de votre CA publique ou de Let’s Encrypt.

Un autre aspect du chiffrement et de la sécurité SSL/TLS consiste à décider si le chiffrement doit être géré au niveau du contrôleur Ingress, du pod ou de l’application, ou des deux. Chaque scénario présente des avantages et des inconvénients. Le chiffrement au niveau d’Ingress permet d’établir un lien direct entre toutes les requêtes entrantes d’Ingress et les services Kubernetes de back-end.

Stocker des certificats SSL/TLS dans le pod ou l’application en cours d’exécution ajoute de la complexité. Il peut toutefois y avoir des raisons métier de vouloir garantir le chiffrement du trafic entre le contrôleur Ingress et le pod ou l’application, en plus du trafic chiffré vers Internet assuré par la configuration du contrôleur. Pour cette démonstration, nous allons créer un certificat autosigné. Les étapes sont toutefois similaires pour les deux autres options.

Sur une machine Mac ou Linux, ou dans un shell de plateforme cloud (ici, Cloud Shell), exécutez la commande openssl suivante :

1mkdir certs
2
3openssl req -x509 -nodes -days 9999 -newkey rsa:2048 -keyout certs/ingress-tls.key -out certs/ingress-tls.crt

L’image ci-dessous montre le résultat de la commande précédente.

Saisissez les informations relatives à votre organisation à intégrer à la demande de certificat, comme le nom de l’organisation, le code pays, la ville et l’adresse e-mail. Notez que cette démonstration utilise www.ingress-tls.com comme nom de domaine complet (FQDN) du certificat.

Cette opération crée le fichier de certificat (CRT-extension) et le fichier de clé privée du certificat (KEY-extension) dans le dossier \certs.

Création du Secret Kubernetes

Associez ensuite le certificat et la clé à un Secret Kubernetes en exécutant la commande suivante :

1kubectl create secret tls ingress-cert --namespace dev --key=certs/ingress-tls.key --cert=certs/ingress-tls.crt -o yaml

Vous pouvez récupérer le Secret proprement dit à l’aide de kubectl get secret. Le résultat ressemblera à l’image suivante :

Publication d’une nouvelle application de démonstration dans l’espace de noms Ingress

Créez ensuite un nouveau fichier sample-app.yaml contenant la syntaxe suivante (en veillant à respecter les niveaux d’indentation YAML) :

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: sample-app
5  namespace: default
6spec:
7  selector:
8    matchLabels:
9      app: sample
10  replicas: 2
11  template:
12    metadata:
13      labels:
14        app: sample
15    spec:
16      containers:
17      - name: sample
18        image: "gcr.io/google-samples/hello-app:2.0"
19
20---
21
22apiVersion: v1
23kind: Service
24metadata:
25  name: sample-app-service
26  namespace: default
27  labels:
28    app: sample
29spec:
30  type: ClusterIP
31  selector:
32    app: sample
33  ports:
34  - port: 80
35    targetPort: 8080
36    protocol: TCP

Cette opération crée un service et une application de démonstration (à l’aide de l’image de conteneur de démonstration hello-app de Google) dans l’espace de noms ingress-nginx déjà existant. Notez que le code associe le Secret SSL/TLS à cet espace de noms : vous ne pouvez donc l’utiliser que pour les applications et services qui y sont exécutés.

Injectez ensuite la configuration dans le cluster Kubernetes en exécutant la commande suivante :

1kubectl apply -f sample-app.yaml:

Créer l’intégration SSL/TLS entre le contrôleur Ingress et l’application de démonstration

Enfin, créez un autre fichier nommé sample-ingress.yaml et déclarez la ressource Ingress à l’aide des paramètres de configuration SSL/TLS suivants :

1apiVersion: networking.k8s.io/v1
2kind: Ingress
3metadata:
4  name: sample-app-ingress
5  namespace: default
6spec:
7  ingressClassName: nginx
8  tls:
9  - hosts:
10    - www.ingress-tls.com
11    secretName: ingress-cert
12  rules:
13  - host: "www.ingress-tls.com"
14    http:
15      paths:
16        - pathType: Prefix
17          path: "/"
18          backend:
19            service:
20              name: sample-app-service
21              port:
22                number: 80

Dans l’exemple ci-dessus, les paramètres suivants appliquent SSL/TLS et l’associent au Secret :

1tls:
2  - hosts:
3    - www.ingress-tls.com
4    secretName: ingress-cert
5  rules:
6  - host: "www.ingress-tls.com"

La section des chemins, à la fin du fichier, indique que toutes les requêtes entrantes destinées à l’hôte doivent être acheminées vers le sample-app-service créé à l’étape précédente (l’application conteneur hello-app de Google).

Exécutez à nouveau la commande kubectl pour injecter cette configuration dans le cluster Kubernetes :

1kubectl apply -f sample-app-ingress.yaml

Pour tester la connectivité au FQDN, mettez à jour le fichier hosts DNS de votre machine locale (généralement /etc/hosts sur Mac ou Linux, ou C:\Windows\System32\Drivers\Etc\Hosts sous Windows) afin d’associer l’adresse IP du contrôleur Ingress au FQDN utilisé.

Remarque : si vous ne souhaitez pas modifier le fichier hosts local ou si vous ne le pouvez pas, vous pouvez utiliser un résolveur DNS, comme https://nip.io. Par exemple, le nom de notre contrôleur Ingress serait résolu en 20.245.164.52.nip.io. Cette adresse renverrait à l’adresse IP du contrôleur 20.245.164.52.

Ouvrez le navigateur et accédez au FQDN utilisé pour le certificat (www.ingress-tls.com ou 20.245.164.52.nip.io dans notre exemple). Notez que l’avertissement « Non sécurisé » s’affiche toujours, car le navigateur ne fait pas confiance au certificat autosigné. Cliquez sur Paramètres avancés, puis sur Continuer pour ouvrir l’URL de l’application :

Comme vous pouvez le constater, l’application de démonstration (le message « Hello, world! » à gauche) fonctionne comme prévu avec le certificat SSL/TLS autosigné que nous avons créé précédemment.

Pour en savoir plus, consultez l’outil CNCF Cert Manager. Il propose une méthode plus avancée pour gérer les certificats et créer automatiquement des Secrets.

Comparaison de différents fournisseurs Ingress

Dans ce guide, nous avons utilisé le contrôleur Ingress NGINX, très populaire, mais il en existe bien d’autres. Si vous débutez avec Kubernetes, la solution open source NGINX permet facilement d’équilibrer la charge et de protéger les workloads de votre cluster. NGINX propose également une version davantage orientée entreprise, appelée NGINX Plus. Vous pouvez aussi opter pour Kong, une autre solution commerciale qui s’appuie sur le même code que NGINX. Traefik est une autre solution commercialisée, qui offre une prise en charge étendue des protocoles, une haute disponibilité et d’autres fonctionnalités. 

Toutes les solutions que nous choisissons interagissent avec l’API Kubernetes Ingress. Cependant, plus tôt cette année, Kubernetes a publié la version bêta de son Gateway API, qui pourrait devenir une alternative intéressante à l’API Ingress actuelle, notamment grâce à ses capacités de contrôle d’accès granulaires basées sur les rôles. Outre la prise en charge de plusieurs protocoles standard, tels que HTTP et TCP/UDP, l’un des principaux avantages de la Gateway API est qu’elle intégrera également la prise en charge de TLS.

Comme la Gateway API en est encore à ses débuts (elle est actuellement en version bêta), il est trop tôt pour savoir quel sera l’avenir de l’API Ingress par rapport à celui de la Gateway API. Cette dernière, qui devait succéder à l’API Ingress, pourrait offrir bien plus que la simple reproduction des fonctionnalités de l’API Ingress. Mais on ne sait pas encore comment les autres fournisseurs et extensions s’y adapteront. La bonne nouvelle, toutefois, est que la sécurité est une priorité absolue, TLS étant utilisé comme standard pour le routage.

Conclusion

Dès lors que des charges de travail et des services Kubernetes sont accessibles depuis Internet, les contrôleurs Ingress entrent en jeu. Au-delà de leurs fonctionnalités de proxy inverse, il est vivement recommandé d’intégrer des certificats SSL/TLS à votre architecture Ingress. Cela garantit le chiffrement du trafic entre le client (navigateur) et le serveur (application Kubernetes Service). Kubernetes prend en charge différents fournisseurs Ingress et accepte divers certificats SSL/TLS sous forme de Secrets. Consultez notre guide sur la sécurité Kubernetes pour découvrir d’autres bonnes pratiques.

Avec les commandes d’administration Kubernetes standard, comme Helm et kubectl, l’intégration de SSL/TLS ne devrait pas être plus compliquée que le déploiement d’un service Kubernetes. Consultez également notre guide pour implémenter TLS/SSL en Python.

Sécuriser les communications entre le monde extérieur et vos applications à l’aide de certificats SSL/TLS n’est qu’une étape vers des applications plus sûres : vous devez également sécuriser chaque étape du cycle de vie du développement logiciel. Identifiez et corrigez les vulnérabilités potentielles dans le code que vous écrivez et les projets open source que vous utilisez avec Snyk Code et Snyk Open Source, et utilisez Snyk Container pour partir d’une image de base plus sûre et repérer les éventuelles vulnérabilités supplémentaires introduites lors du processus de build. Enfin, vérifiez que le code que vous déployez ne contient aucune faille de sécurité avec Snyk IaC.