Le réseau basé sur l'intention est-il une technologie « défaillante » ?

Au milieu des années 2010, les spécialistes du marketing technologique et les analystes sont tombés amoureux d'une technologie qu'ils ont baptisée Intent Based Networking (IBN), et ont beaucoup apprécié cette technologie.

Aujourd'hui, presque dix ans plus tard, vous n'entendez plus beaucoup parler d'IBN. Mais cela ne veut pas dire qu'il a disparu.

Cet article détaille l'histoire d'IBN et ses fondements essentiels à l'infrastructure cloud moderne d'aujourd'hui, ainsi qu'à la sécurité du cloud.

Début des années 2010 : adaptation à l'évolution rapide des réseaux cloud

Juste avant cela, chez HP Networking, le bureau du CTO avait vu de nouvelles abstractions réseau similaires inventées de manière isolée par plusieurs groupes essayant de s'adapter à la nouvelle échelle et au nouveau rythme de changement des réseaux cloud. Une grande partie de ce travail a été réalisée dans le cadre de projets open source (par exemple, OpenStack, Open Day Light).

HP a décidé d'investir des ressources pour essayer d'unifier ce travail et a organisé en 2013 le « IBN Summit » aux HP Labs à Palo Alto. Des invitations ont été adressées à toutes les personnes connues pour travailler sur des solutions de politique réseau pour des projets SDN et cloud, notamment des personnes de Cisco, HP, RedHat, IBM, Huawei, Brocade, Microsoft, NEC, VMware, etc. Les différentes parties ont présenté certains aspects de leur travail dans ce domaine et ont convenu d'essayer de trouver une voie vers une API commune.

Milieu des années 2010 : Définition de l'IBN

Les représentants de bon nombre de ces entreprises ont ensuite continué à travailler ensemble au sein du groupe de travail North-Bound Interface (NBI) de l'Open Networking Foundation (ONF) alors que j'étais président. En octobre 2016, l'ONF a publié un document destiné à présenter le consensus des membres sur une définition et un aperçu technique d'un système IBN.

Lisez le document, Intention NBI - Définition et principes, ici.

La définition de ce document peut être résumée par une sorte de règle d'or : l'intention n'inclut aucun détail de mise en œuvre qui la rendrait spécifique à la plate-forme ou à l'infrastructure.

L'intention consiste en des déclarations déclaratives concernant les comportements de réseau souhaités en termes commerciaux. Séparément, il existe un processus de mappage qui sait comment implémenter l'intention dans la configuration/l'état/la topologie actuels de l'infrastructure.

Les critiques ont affirmé que nous jetions et que nous ignorions la mise en œuvre, de sorte qu'elle n'avait aucune valeur. Nous avons fait remarquer que nous n'étions pas en train de le jeter, mais que nous le déplacions ailleurs sous le contrôle d'un processus de cartographie. Déclarer une intention « pure » ne nécessite pas que les auteurs de la politique soient des experts des technologies d'infrastructure, mais qu'ils comprennent simplement les contraintes commerciales liées à la politique.

Dans ce document, la définition de l'ONF décrivait une « boucle active intentionnelle » au sein du contrôleur :

« Cet élément est chargé d'évaluer en permanence les intentions et les mappages des services actifs à partir du référentiel et des informations réseau provenant du gestionnaire SBI ; et de prendre les mesures nécessaires pour instancier de nouvelles configurations de service ou modifier de manière appropriée les configurations de service existantes en fonction des changements d'intention détectés (repo), et/ou des changements de mappage (repo), et/ou de l'Intent NBI. »

La description de la boucle active d'intention est cohérente avec un terme devenu bien connu de Kubernetes qui décrit les contrôleurs qui traduisent l'intention déclarative en comportements du système comme étant construits sur une boucle de réconciliation continue (CRL) qui maintient en permanence une implémentation de l'intention déclarée au sein de l'infrastructure.

Cet article utilisera le terme boucle de réconciliation continue ou CRL pour désigner toutes ces approches techniques.

2017 : IBN est « la prochaine grande nouveauté »

Peu après la publication du document, l'industrie a commencé à parler d'IBN lorsque Gartner a inventé le terme en 2017 et l'a qualifié de « prochaine grande nouveauté » dans un article de blog.

Les spécialistes du marketing ont fini par rendre l'IBN vide de sens, comme ils le font, d'abord en affirmant que chaque fournisseur a toujours eu un IBN. Et puis, en conséquence, les gens ont fini par arrêter d'en parler.

Après tout ce bruit, on peut se demander : l'IBN a-t-il été un échec sur le plan pratique ?

La réponse est non, bien au contraire.

Aujourd'hui : IBN est bien vivant dans l'infrastructure cloud moderne

Nous ne parlons pas beaucoup d'IBN, mais il est omniprésent dans l'infrastructure cloud moderne.

Trois exemples illustrent l'étendue de l'utilisation de cette approche dans les grands environnements de production.

Politiques réseau Kubernetes

Le contrôleur de politique de l'interface réseau de conteneurs (CNI) de K8, la liste de révocation des certificats (CRL), connaît l'état de tous les pods/terminaux, commutateurs virtuels, proxys sidecar, passerelles, NAT, etc. Il connaît également les mappages nécessaires à la mise en œuvre (adresses IP, ports, protocoles, identité, autorisations, étiquettes, espaces de noms, etc.) et exécute une boucle de réconciliation continue pour assurer la cohérence de la mise en œuvre avec les politiques réseau.

Les développeurs fournissent Kubernetes politiques réseau (KNP) sans détails d'implémentation (intention), et le contrôleur le fait. Les KNP permettent aux utilisateurs de spécifier des attributs de niveau inférieur tels que l'adresse IP ou le port, mais la meilleure pratique consiste à utiliser des sélecteurs basés sur des étiquettes dans les déclarations de politique locales afin de bénéficier de l'automatisation de l'état distribué dans le moteur KNP.

Moteur de calcul de politiques Illumio (PCE) et Illumio VEN (agent)

Illumio propose un produit d'entreprise mature et largement déployé qui apporte une proposition de valeur intentionnelle aux machines et conteneurs virtuels et virtuels en utilisant une abstraction similaire basée sur des étiquettes. Cela couvre plusieurs instances dynamiques utilisant un contrôleur CRL pour maintenir les contraintes de politique.

Il existe un contrôleur distribué (PCE), préconfiguré avec des politiques abstraites, dynamiques et basées sur des étiquettes, qui utilise la boucle de réconciliation continue pour mettre en œuvre ces politiques dans le contexte de l'état et de la topologie actuels de l'infrastructure.

Dans ce cas, l'application effective des politiques se fait en programmant les outils natifs de niveau inférieur pour diverses plateformes d'infrastructure sur site et dans le cloud public.

Genévrier/Apstra

Apstra IBN dispose également d'un modèle déclaratif automatisé pour convertir les politiques abstraites en implémentations d'infrastructure spécifiques. Cependant, le problème qu'il résout est légèrement différent des exemples précédents.

Les politiques réseau de Kubernetes et la plateforme Illumio peuvent toutes deux être classées dans la catégorie des technologies réseau « superposées ». Ils créent et contrôlent les fonctionnalités d'un réseau virtuel en plus d'un réseau qui dispose déjà d'une connectivité de base entre les appareils physiques.

La solution Juniper Apstra a la capacité de créer et de contrôler le réseau « Sous-couche » qui comprend des racks remplis d'appareils de centre de données connectés par des câbles. Mais, comme les exemples ci-dessus, il maintient la cohérence en conciliant en permanence les politiques déclaratives avec le réseau.

IBN : l'épine dorsale des performances du cloud à grande échelle

La couche d'abstraction supplémentaire fournie par une approche basée sur l'intention est nécessaire pour atteindre l'échelle, le taux de changement et les performances nécessaires pour les charges de travail dans le cloud.

Si vous avez au moins des milliers d'instances dynamiques d'une « application » en constante évolution, les humains ne peuvent pas être à la pointe de la mise à jour des politiques. Une interface basée sur l'intention « comprime » l'espace des règles du point de vue de l'utilisateur et cache toute la magie qui permet de le réaliser derrière cette interface. Il permet de traiter les instances présentant des comportements similaires/identiques comme un groupe auquel une politique peut être appliquée.

Si votre intention est que « les objets du groupe A peuvent communiquer avec les objets du groupe B », vous créez une règle simple qui n'a jamais besoin de changer. Il s'agit de la règle correcte qui conduit au comportement correct, qu'il n'y ait aucune instance, une, deux, trois ou un milliard d'instances, sur un seul serveur ou des millions. Il n'existe qu'une seule règle, mais sa mise en œuvre dans un grand système peut nécessiter des mises à jour dynamiques d'un milliard de règles de pare-feu sur cent mille pare-feux.

C'est le développement de ces énormes contrôleurs de boucle de réconciliation continue, distribués et automatisés qui permettent de mettre en œuvre des politiques de réseau mondiales pour les systèmes distribués à grande échelle, qui sont de plus en plus développés sur le cloud par des entreprises internationales.

L'époque des feuilles de calcul Excel contenant les règles de tous vos pare-feux est révolue depuis longtemps. Toute approche manuelle et individualisée de « programmation de pare-feux » pour des systèmes plus importants est également obsolète.

La sécurité moderne du cloud repose sur IBN

IBN a discrètement fait tout le trajet sur le cycle de battage médiatique. Il est si profondément ancré dans les fondements des réseaux modernes qu'il n'est plus associé à un mot à la mode.

Le fait que plusieurs parties aient inventé des solutions conceptuellement similaires de manière isolée est toujours un signe aussi fort que quelque chose d'important est en train de se produire. Les personnes qui ont réalisé ce travail sont largement inconnues, mais elles savent qu'elles ont contribué à la réalisation des choses incroyables que nous pouvons réaliser dans le cloud aujourd'hui.

Cette capacité s'avère d'autant plus importante que cybermenaces l'augmentation et la protection des Confiance zéro la mise en réseau, en particulier, devient encore plus cruciale. La nature fiable et évolutive d'IBN permet à son tour à des plateformes comme Illumio d'offrir une sécurité fiable et évolutive dans le cloud.

En savoir plus sur la manière dont Illumio CloudSecure contient les failles dans le cloud hybride ici.

Vous souhaitez sécuriser votre réseau cloud avec Illumio Zero Trust Segmentation ? Nous contacter aujourd'hui pour une consultation et une démonstration.