" L'Intent-Based Networking est-il une technologie "qui a échoué ?

Au milieu des années 2010, les experts en marketing technologique et les analystes sont tombés amoureux d'une technologie appelée Intent-Based Networking (IBN), dont ils ont fait grand cas.

Aujourd'hui, près d'une décennie plus tard, vous n'entendez plus guère parler d'IBN. Mais cela ne veut pas dire qu'elle a disparu.

Cet article détaille l'histoire de l'IBN et ses fondements essentiels à l'infrastructure moderne de l'informatique en nuage d'aujourd'hui - et à la sécurité de l'informatique en nuage.

Début des années 2010 : S'adapter à l'évolution rapide des réseaux en nuage

Juste avant cela, chez HP Networking, le bureau du directeur technique a vu de nouvelles abstractions de réseau similaires inventées de manière isolée par de multiples groupes essayant de s'adapter à la nouvelle échelle et au rythme de changement des réseaux en nuage. La plupart de ces travaux ont été réalisés dans le cadre de projets à code source ouvert (par exemple, OpenStack, Open Day Light).

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

Milieu des années 2010 : Définir l'IBN

Des 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), dont j'étais le président. En octobre 2016, l'ONF a publié un document destiné à présenter le consensus des membres sur une définition et une vue d'ensemble technique pour un système IBN.

Lisez le document, Intent 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 à une plate-forme ou à une infrastructure.

L'intention consiste en des déclarations sur les comportements souhaités du réseau en termes commerciaux. Séparément, il existe un processus de mise en correspondance qui sait comment mettre en œuvre l'intention dans la configuration/état/topologie actuelle de l'infrastructure.

Les critiques ont affirmé que nous rejetions et ignorions la mise en œuvre et qu'il n'y avait donc aucune valeur. Nous avons fait remarquer que nous ne nous en débarrassions pas, mais que nous le déplacions ailleurs sous le contrôle d'un processus de cartographie. La déclaration d'intention "pure" n'exige pas des auteurs de la politique qu'ils soient experts en technologies d'infrastructure, mais qu'ils comprennent les contraintes commerciales de la politique.

" Dans ce document, la définition de l'ONF décrit une boucle active de l'intention "à l'intérieur du contrôleur :

"Cet élément est chargé d'évaluer en permanence les intentions de service actives et les correspondances provenant de la base de données et les informations de 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 existantes en fonction des changements d'intentions détectés (base de données), et/ou des changements de correspondances (base de données), et/ou de l'intention 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 continuellement une implémentation de l'intention déclarée au sein de l'infrastructure.

Dans cet article, nous utiliserons le terme de boucle de réconciliation continue (CRL) pour désigner toutes ces approches techniques.

2017 : IBN est "le prochain grand projet"

Peu de temps après la publication du document, le secteur a commencé à parler de l'IBN lorsque Gartner a inventé le terme en 2017 et l'a qualifié de "next big thing" dans un article de blog.

Les spécialistes du marketing ont fini par vider l'IBN de sa substance, comme ils le font, en commençant par faire croire à tous les vendeurs qu'ils ont toujours eu l'IBN. Et puis, en conséquence, les gens ont fini par ne plus en parler.

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

La réponse est non, bien au contraire.

Aujourd'hui : L'IBN est bien vivant dans l'infrastructure moderne en nuage

Nous ne parlons pas beaucoup de l'IBN, mais il est omniprésent dans les infrastructures modernes en nuage.

Trois exemples illustrent l'étendue de l'utilisation de cette approche dans des environnements de production importants.

Politiques de réseau Kubernetes

Le contrôleur de politique de l'interface de réseau de conteneurs (CNI) de K8, la liste de révocation de certificats (CRL), connaît l'état de tous les pods/points d'extrémité, commutateurs virtuels, proxies sidecar, passerelles, NAT, etc. Il connaît également les correspondances pour la mise en œuvre (adresses IP, ports, protocoles, identité, autorisation, étiquettes, espaces de noms, etc.) et exécute une boucle de réconciliation continue pour maintenir la cohérence de la mise en œuvre avec les politiques du réseau.

Les développeurs fournissent des politiques de réseau Kubernetes (KNP) sans détails de mise en œuvre (intention), et le contrôleur fait en sorte qu'il en soit ainsi. 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 locale afin de bénéficier de l'automatisation de l'état distribué dans le moteur KNP.

Moteur de calcul des politiques d'Illumio (PCE) et VEN d'Illumio (agent)

Illumio dispose d'un produit d'entreprise mature et largement déployé qui apporte la proposition de valeur d'intention au métal nu, aux machines virtuelles et aux conteneurs en utilisant une abstraction similaire basée sur les étiquettes. Il s'agit de plusieurs instances dynamiques utilisant un contrôleur de LCR pour maintenir les contraintes de la 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.

L'application effective de la politique, dans ce cas, est réalisée par la programmation d'outils natifs de niveau inférieur pour diverses plateformes d'infrastructure sur site et dans le nuage public.

Juniper/Apstra

Apstra IBN dispose également d'un modèle déclaratif avec une automatisation permettant de convertir des politiques abstraites en implémentations d'infrastructures spécifiques. Cependant, le problème qu'il résout est légèrement différent de celui des exemples précédents.

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

La solution Juniper Apstra permet de créer et de contrôler le réseau 'Underlay' qui comprend des racks remplis d'équipements de centres de données reliés par des câbles. Mais, comme dans les exemples précédents, il maintient la cohérence en rapprochant en permanence les politiques déclaratives et le réseau.  

IBN : L'épine dorsale de la performance des nuages à 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 la performance requis pour les charges de travail en nuage.

Si vous avez des milliers ou plus d'instances dynamiques d'une application "" qui changent constamment, les humains ne peuvent pas être en mesure de mettre à jour rapidement les politiques. Une interface basée sur l'intention "compresse" l'espace de règles du point de vue de l'utilisateur et cache toute la magie de la concrétisation derrière cette interface. Il permet aux instances ayant des comportements similaires/identiques d'être traitées comme un groupe auquel une politique peut être appliquée.

Si votre intention est ", les éléments du groupe A peuvent communiquer avec les éléments du groupe B,", vous créez une règle simple qui ne doit jamais être modifiée. C'est la bonne règle et elle conduit au bon comportement, qu'il n'y ait aucune instance, une, deux, trois ou un milliard d'instances, sur un seul serveur ou sur des millions. Il n'y a 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 dans cent mille pare-feu.

C'est le développement de ces énormes contrôleurs de boucle de réconciliation automatisés et distribués qui permet de mettre en œuvre des politiques de réseau globales pour les systèmes distribués à grande échelle qui sont de plus en plus souvent construits sur le nuage par des entreprises mondiales.

L'époque d'une feuille de calcul Excel contenant les règles de tous vos pare-feux est révolue depuis longtemps - toute approche manuelle et individualisée de la programmation des pare-feux "" pour les grands systèmes est également obsolète.

La sécurité moderne de l'informatique en nuage repose sur l'IBN

IBN a tranquillement suivi le cycle de l'engouement. Il est si profondément ancré dans les fondements de la mise en réseau moderne 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 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 étonnantes que nous pouvons faire aujourd'hui dans l'informatique dématérialisée.

Cette capacité s'avère d'autant plus importante que les cybermenaces augmentent et que la protection des réseaux "zéro confiance", en particulier, devient encore plus cruciale. La nature fiable et évolutive de l'IBN permet à son tour à des plateformes comme Illumio d'offrir une sécurité fiable et évolutive dans le nuage.

Pour en savoir plus sur la façon dont Illumio CloudSecure prévient les brèches dans le nuage hybride, cliquez ici.

Vous souhaitez sécuriser votre réseau en nuage avec la segmentation zéro confiance d'Illumio? Contactez-nous dès aujourd'hui pour une consultation et une démonstration.