Fruit des travaux de l’Open Infrastructure Foundation (OIF, anciennement fondation Openstack), le projet d'infrastructure cloud open source StarlingX évolue avec une deuxième mise à jour majeure 11.0. Cette plateforme combine le noyau Linux, Kubernetes et OpenStack pour les déploiements informatiques en edge. Verizon, Vodafone, T-Systems et KDDI font partie des grands opérateurs qui utilisent cet environnement en production pour les infrastructures 5G et O-RAN. L'OIF a rejoint cette année la Linux Foundation. La version 11.0 de StarlingX s'appuie sur la mise à jour 10.0 sortie en février dernier. 

Les principales fonctionnalités de StarlingX 11.0

La dernière actualisation comprend plusieurs fonctionnalités dont :

- le chiffrement du trafic pod à pod  via IPsec : les communications entre pods hôtes sont protégées à l'aide du protocole IPsec en mode tunnel avec des contrôles de politique par service ;

- l'optimisation des adresses réseau : l'infrastructure cloud sous-jacente ne nécessite désormais qu'une seule adresse IP au lieu de plusieurs pour la gestion et les interfaces hôtes de cluster ;

- les rôles de contrôle d'accès améliorés : de nouveaux rôles offrent un contrôle d'accès plus granulaire ;

- la prise en charge étendue des restaurations :davantage d'options pour faciliter les restaurations dans toutes les configurations.

« La sécurité sur l'edge est difficile, car il n'existe en réalité aucune sécurité physique qui puisse être présumée », a déclaré Greg Waines, membre du comité technique de StarlingX. « Cela signifie qu'il n'existe pas de réseaux internes sur lesquels on peut exécuter du trafic non protégé. Tout le trafic, tant interne qu'externe, doit être protégé contre les attaques provenant de différents niveaux d'attaquants. »

Un chiffrement IPsec pour protéger le trafic des pods 

StarlingX 11.0 utilise un tunnel IPsec pour chiffrer les communications inter-hôtes entre pods sur le réseau hôte du cluster. Une dernière application système Kubernetes appelée ipsec-policy-operator gère les configurations via des politiques IPsec. Les opérateurs peuvent protéger le trafic d'applications spécifiques par service plutôt que de chiffrer tout le trafic. Le trafic de l'interface de fonction virtuelle Single-root input/output virtualization ou virtualisation d'entrée/sortie à racine unique (SR-IOV) est exclu afin d'éviter la surcharge IPsec. « La préoccupation concernant la sécurité à l'edge, où la sécurité physique est loin d'être aussi bonne que dans un environnement centralisé, ne cesse de croître », a souligné M. Waines. « C’est le cas en particulier des utilisateurs de StarlingX en Europe », a-t-il ajouté. 

Les tests de sécurité effectués par des tiers supposent désormais un accès physique aux équipements. « Il arrive souvent qu’ils réalisent des tests lorsqu'ils ont un accès physique aux équipements et peuvent accéder aux ports de commutation utilisés ou inutilisés pour se connecter de manière passive ou active aux serveurs depuis l'intérieur du déploiement périphérique distant », a expliqué M. Waines. La version ajoute également les rôles de contrôle d'accès « configurateur » et « opérateur » au rôle d'administrateur existant. Associées aux fonctionnalités de sécurité du registre de conteneurs Harbor de StarlingX 10.0, ces modifications répondent aux exigences de sécurité lorsque l'accès physique ne peut être garanti.

Optimisation des adresses IPv4 pour l'edge

Dans la continuité du support dual-stack IPv4/IPv6 introduit dans la version 10.0, la déclinaison 11.0 inclut une réduction des adresses réseau de la plateforme pour les réseaux sous-jacents des services cloud. Cette fonctionnalité ne nécessite qu'une seule adresse IP par environnement au lieu de plusieurs adresses spécifiques. L'architecture précédente attribuait des adresses distinctes pour les opérations, l'administration et la gestion (Operations, Administration and Management, OAM) ainsi que pour les interfaces hôte du cluster Kubernetes. Les adresses réseau de la plateforme sont désormais attribuées à partir d'un sous-réseau partagé dans les environnements IPv4 et IPv6. Plusieurs clouds peuvent utiliser la même plage d'adresses réseau. L'architecture à IP unique fonctionne avec les capacités de mise en réseau dual-stack de StarlingX 10.0, offrant aux opérateurs une grande flexibilité dans leurs stratégies de migration IPv4 vers IPv6. Pour les opérateurs disposant d'un espace d'adressage IPv6, la prise en charge dual-stack offre une voie de migration tout en conservant la compatibilité IPv4. La réduction des exigences IPv4 dans StarlingX 11.0 étend la viabilité des déploiements de ces adresses uniquement, où l'adoption de l'IPv6 se heurte à des limitations organisationnelles ou matérielles.

Alors que le marché dans son ensemble s'oriente vers l'IPv6, la réalité est que de nombreux opérateurs continuent de s'appuyer sur l'IPv4 en raison des contraintes liées à l'infrastructure existante. « Cette fonctionnalité a été principalement mise en œuvre pour les utilisateurs de StarlingX qui utilisent encore l'adressage IPv4 avec des espaces d'adressage plus petits pour leur infrastructure », a indiqué M. Waines. Pour certains de ces utilisateurs IPv4 qui ont des déploiements à grande échelle, l'optimisation des adresses aura un impact réel sur les opérations. « Les opérateurs déploient StarlingX à grande échelle, ce qui, pour les versions ultérieures de la plateforme, signifie jusqu'à 5 000 réseaux cloud sous jacents AIO-SX dans un seul déploiement de centre de données », a expliqué M. Waines. « À cette échelle, même une petite réduction du nombre d'adresses IP requises par sous-cloud fait une grande différence. »

Un framework de gestion logicielle unifiée toujours en évolution 

La facilité des mises à jour est un autre domaine dans lequel StarlingX cherche à aider les opérateurs cloud. Ildikó Váncsa, directrice de la communauté à l'Open Infrastructure Foundation, a expliqué que la communauté avait introduit le framework Unified Software Management (USM) dans la version 10.0 afin de fournir une interface unique et un ensemble unifié de commandes pour que les utilisateurs puissent effectuer des mises à jour et des mises à niveau sur l'ensemble d'un système déployé.

Elle fait remarquer que les contributeurs continuent d'optimiser le framework tout en l'enrichissant de nouvelles fonctionnalités. « Alors que les réseaux continuent leur transformation numérique et commencent à suivre les principes du cloud natif, il devient de plus en plus important de pouvoir déployer des mises à niveau et de rester à jour avec les nouvelles versions des composants du système », a fait valoir Mme Váncsa. « En améliorant l'USM, la plateforme StarlingX cherche à répondre à ce besoin émergent. »