Xylos brands

Comment garantir un accès sécurisé ?

Dans les billets de blog précédents, nous avons lancé une application à la fois dans Azure Container Instances (ACI) et Azure Kubernetes service (AKS). Mais nous ne nous sommes pas encore appesantis sur les aspects de sécurité de l’application. En voici un aperçu :

  • L’AKS est-il vraiment sûr ? Existent-ils des « points finaux » publics que nous devons sécuriser ?
  • Qui a quels droits dans l’AKS (RBAC) ?
  • Le conteneur présente-t-il des faiblesses ?
  • Devons-nous analyser nos conteneurs à la recherche de virus ou de logiciels malveillants ?
  • Devons-nous déployer et configurer un pare-feu ?
  • Le trafic vers l’application est-il sécurisé ?

Il est facile de répondre à la dernière question : « Non ». Afin de sécuriser le trafic vers l’application, vous devez prendre vous-mêmes des mesures. Azure ou Kubernetes ne le feront pas pour vous. Dans ce billet de blog, nous allons nous pencher sur la dernière question.

1. Qu’est-ce que Kubernetes service avec Azure Load Balancer ?

Dans les billets de blog précédents, nous avons lancé deux conteneurs avec une application web. Ensuite, nous avons créé un service et publié ce service sur internet via un équilibreur de charge Azure public. Vos ingénieurs réseau ne doivent pas intervenir pour ce faire : AKS créera l’Azure Load Balancer et le configurera correctement. Le schéma ci-dessous illustre cette configuration :

LoadBalancer. L’AKS crée automatiquement l’Azure Load Balancer et une adresse IP publique par service. Kubernetes met automatiquement à jour la configuration de routage qui relie l’adresse IP du service A et B aux pods de ce service.

Cette configuration n’est pas du tout au fait de votre application. Vous ne pouvez pas configurer un certificat SSL au niveau de l’équilibreur de charge ou du service. Et c’est exactement ce dont vous avez besoin pour protéger le trafic vers votre application.

Si vous avez beaucoup de services, vous avez une montagne d’adresses IP à gérer. Un système qui peut relier une seule adresse IP à plusieurs applications facilite la gestion. Dans l’écosystème de Kubernetes, nous parlons d’un contrôleur d’entrée ou Ingress Controller.

2. Qu’entend-on par Ingress Controller ?

Un contrôleur d’entrée ou Ingress Controller n’est rien de plus qu’un proxy inverse (reverse proxy). Ce dernier est au fait de la couche applicative : la couche 7. Dans ce cas, c’est http. Le diagramme ci-dessous le montre clairement :

Il s’agit en l’occurrence de deux applications, accessibles via https://serviceA et https://serviceB. Le contrôleur d’entrée est au fait de la couche applicative et peut transmettre les demandes au service A interne (idem pour le service B). Les services A et B n’ont désormais plus d’adresse IP externe. Le contrôleur d’entrée, en revanche, possède une adresse IP externe qui est créée via un service séparé avec un équilibreur de charge classique.

Kubernetes ne contient pas de contrôleur d’entrée standard. Mieux vaut que vous l’installiez vous-même. Le contrôleur d’entrée le plus fréquemment utilisé est probablement nginx-ingress. Mais il y en a encore bien plus. Chez Xylos, nous utilisons, entre autres, Voyager et traefik. Microsoft propose le routage d’application HTTP comme extension d’AKS pour pouvoir rapidement déployer un Ingress Controller. Il n’est toutefois pas recommandé de l’utiliser en production.

3. Configuration de l’Ingress Controller

Supposons que vous ayez déployé nginx-ingress et que vous vouliez configurer ce contrôleur d’entrée. Quelle est la marche à suivre ? La réponse est assez simple : créer une ressource d’entrée avec un fichier YAML :

Ce fichier YAML configure un contrôleur nginx-ingress installé pour transférer les requêtes pour l’application web sur https://demo.xylos.com à deux services Kubernetes. L’URL https://demo.xylos.com/ mène au service demo-app-client, https://demo.xylos.com/api, au service demo-app-api. Bien sûr, cela ne fonctionnera que si vous traduisez demo.xylos.com vers l’adresse IP du contrôleur d’entrée dans DNS.

4. Certificat

Le fichier YAML contient une ligne avec secretName : tls-secret. Cette ligne fait référence à un certificat installé pour demo.xylos.com. Le trafic vers le contrôleur d’entrée est sécurisé par SSL, puis terminé. Le trafic du contrôleur d’entrée est interne et n’est pas sécurisé.

Vous pouvez installer le certificat manuellement en tant que secret Kubernetes. Vous pouvez également utiliser Let’s Encrypt comme solution de remplacement pour créer un ou plusieurs certificats automatiquement. Vous aurez besoin d’un logiciel supplémentaire qui peut demander le certificat comme certmanager. La documentation Microsoft contient un guide complet afin de l’automatiser avec nginx-ingress et certmanager.

5. Conclusion

Dans ce dernier billet de blog de la série sur les conteneurs, nous avons examiné la sécurité du transport avec un contrôleur d’entrée ou Ingress Controller. Nous nous sommes penchés sur les fondamentaux, sans nous soucier d’autres aspects de sécurité tels que les pare-feu d’applications web (WAF) en combinaison avec Kubernetes. Si vous voulez en savoir plus à ce sujet, vous pouvez toujours nous contacter.

Partager cet article de blog

Laissez une réponse

Votre adresse email ne sera pas publiée. Les champs requis sont indiqués.