Les microservices permettent aujourd’hui d’adopter une nouvelle stack technologique distribuée en raison de leur flexibilité, scalabilité, autonomie et disponibilité. La plupart du temps, ils sont développés dans des langages et des contextes différents. En adoptant cette architecture distribuée, les entreprises découvrent les défis que la sécurité peut poser. Il est inutile de rappeler que la complexité est le pire ennemi de la sécurité. Les vulnérabilités applicatives, le manque de protection des données ou encore la mauvaise gestion des identités et accès augmentent la surface d’attaque des microservices. 

La nécessité aujourd’hui est tout d’abord de comprendre les enjeux autour de la sécurité d’une telle architecture et par la suite déployer une stratégie qui va minimiser les risques.

À l’heure actuelle, l’approche la plus populaire pour adresser ces problématiques est de recourir au Service Mesh qui sécurise les interactions entre microservices. Beaucoup d’entreprises s’intéressent à Istio car elle simplifie la gestion des microservices. Dans ce cas, comment Istio répond t-il aux exigences de sécurité des architectures distribuées?

 

Istio: Conformité et Objectifs

Pour maîtriser les risques liés aux développement des microservices, le framework NIST a identifié dans son draft 800-204A quelques mesures à prendre en compte. Il définit pour l’utilisation d’une technologie de Mesh les recommandations suivantes:

  • Utilisation d’un service proxy pour les communications
  • Configuration des gateways
  • Gestion des identités et des accès
  • Capacité de Monitoring
  • Résilience au niveau réseau
  • Configuration du CORS

Istio reprend ces concepts dans son architecture et identifie principalement trois objectifs.

     Secure by default

Ce concept nous ramène au triangle de développement des applications. Il nous rappelle la difficulté à trouver l’équilibre entre le choix de prioriser  l’intégration de nouvelles fonctionnalités ou la sécurité. Plus on met en avant la sécurité dans nos process plus il devient difficile de mettre en place de nouvelles fonctionnalités.

Istio répond à cette problématique avec une garantie que son utilisation n’apporte aucune modification aux fonctionnalités intégrées dans les applications. Son utilisation est transparente car il n’est pas nécessaire de  modifier le code ou l’infrastructure pour appliquer de nouvelles politiques de sécurité.

 

     Principe de défense en profondeur

La défense en profondeur a pour but de ne pas faire reposer la sécurité sur un élément mais sur un ensemble cohérent. Déployer des microservices dans des environnements cloisonnés tels que Kubernetes ne signifie pas forcément qu’ils sont sécures. Une fois que l’attaquant arrive à s’introduire au niveau de la plateforme, il est tout à fait possible de compromettre les applications.

Istio apporte donc une couche supplémentaire de sécurité par rapport à celles existantes afin de réduire l’exposition des microservices aux risques induits. 

 

     Une architecture Zero Trust 

Dans cette approche, Istio part du principe que tout trafic provenant aussi bien de l’intérieur que de l’extérieur du mesh peut constituer une menace. Aujourd’hui avec l’avènement des attaques très avancées et complexes, la notion de confiance est de plus en plus contraignante. Partant du threat modeling des architectures microservices, Istio orchestre un ensemble de mesures pour mitiger les risques à travers :

  • Une gestion des identités et des accès
  • Une granularité dans la définition des autorisations
  • Une micro-segmentation
  • Du chiffrement de bout en bout

Concrètement comment est-ce mis en oeuvre? 

Parlons un peu technique maintenant ^_^.                                                    

Istio sécurise le déploiement des microservices grâce à des méthodes d’authentification, d’autorisation, chiffrement de bout en bout et de monitoring. Dans l’architecture d’Istio, on retrouve ci-dessous les composants du control plane qui gèrent chacun de ces mécanismes.

Architecture d’Istio.io

 

     Proxy un jour, Proxy toujours

Istio permet de créer une chaîne de proxies pour éviter d’exposer les microservices. Dans le Data plane, toutes les communications passent par des proxies appelés Envoy. Chaque microservice dispose de son propre Envoy.

Si la communication doit s’établir en dehors du mesh, deux proxies interviennent à savoir l’Ingress et l’Egress. Ingress reçoit le trafic d’un service externe et le route vers le service de destination. Egress à l’opposé achemine le trafic du mesh vers des services externes. Ils ont les fonctionnalités de terminaison TLS afin de chiffrer et déchiffrer le trafic à travers des “gateways ressource”.

 

     Authentification

L’authentification est le premier qui doit être défini pour gérer la communication des microservices dans un mesh. Citadel est la composante d’Istio qui agit en tant que CA de Istio pour contrôler l’authentification et la gestion d’identité pour chaque workload. Il est en charge de générer, distribuer et révoquer les clés et certificats X.509.

Lorsque des services veulent communiquer, ils passent par les proxy appelés Envoy au niveau du Data plane pour s’authentifier réciproquement via du mTLS. Traditionnellement en utilisant du TLS, le client présente un certificat pour s’authentifier auprès du serveur et établir la communication. Avec Istio, cette authentification est mutuelle, dans les deux sens, ce qui permet de valider leurs identités à travers les clés publiques.

Au niveau utilisateur, Istio utilise le standard de tokenisation JWT compatible avec OpenID qui permet de se connecter via du Auth0 ou des services providers tels que Google Auth et Key Cloak.  

En fin de compte, rien ne passe en clair, toutes les communications sont chiffrées.

 

     Autorisation

Après l’authentification, la gestion des autorisations avec Istio est paramétrable avec un modèle de RBAC. Ce modèle s’applique pour les services, utilisateurs et comptes de services à travers deux objets:

  • Le ServiceRole qui décrit la liste des permissions suivant un certain nombre de conditions .
  • Le ServiceRoleBinding qui va permettre d’assigner ce role à une entité.

Ces politiques d’accès sont personnalisables au niveau méthode, namespace et service. La composante Pilot se charge de pousser par la suite cette configuration dans l’engin proxy Envoy. 

     Monitoring

Istio propose un concept d’observabilité qui peut être intéressant pour avoir de la visibilité sur les microservices. La composante Mixer permet de collecter les logs, générer des métriques et faire du tracing distribué.Cette fonctionnalité est importante d’une part pour être conforme à certaines réglementations telles que le PCI-DSS mais aussi d’autre part pour servir dans un contexte de SOC ou d’audit. Pour détecter les anomalies comportementales dans les microservices, il est nécessaire de surveiller le trafic lié à la sécurité et surtout être en mesure d’investiguer pour plus de contexte, l’objectif étant d’endurcir la politique de sécurité dans les microservices.

Dans le prochain article, nous allons déployer Istio et voir en détail, comment configurer chacun de ces éléments.

Stay tuned !