NSX-T 3.0, Covid Edition …

Bonjour à tous, content de vous retrouver, même si en ce moment, c’est un petit peu, beaucoup, énormément la course forcément. Notre priorité depuis plusieurs semaines est la production et le déploiement des solutions dédiées à la continuité de soin et de service. Cela explique en très grande partie pourquoi je n’ai pas posté de puis un moment, sachant qu’il n’y a toujours que 24h dans une journée ^^. Il n’empêche, malgré le contexte, j’ai trouvé le temps de participer en avance à un webinar sur NSX-T 3.0, sous NDA jusqu’à aujourd’hui même ! On fait le tour des principales nouveautés ? Oui ? Alors, go :)

NSX-T 3.0

Globalement, NSX-T 3.0 reste une grosse évolution de NSX-T 2.5 et vient ajouter de nouvelles fonctions réseau mais aussi s’adapter à l’arrivée récente de vSphere 7 et sa prise en charge native des containers. Dans la pratique, les nouveautés sont regroupées sous 4 grands thèmes : des améliorations générales sur les fonctions réseau, la disponibilité des fonctions IDS et IPS, le support intégré des containers de vSphere 7.0 et enfin des avancées en matière d’interface et d’automatisation.

Amélioration de l’interface générale

Coté interface de management, clairement, il y a des progrès notables. Première chose, la disparition du menu “Advanced Network & Security” au profit d’un menu général plus cohérent et simple. J’ai entre autres repéré deux nouveau dashboards bien sympathiques : un qui centralise les alarmes et un autre qui présente la topologie générale de votre environnement NSX. Franchement, on a hâte de voir cela car cela va nous simplifier la vie au quotidien (notamment pour nos schémas d’architecture). Avec l’arrivée de la fonction Distribued IDS/IPS, on récupère également un tout nouveau groupe de menus et listings dédiés à cette fonction (voir plus loin).

Vous pouvez aussi switcher rapidement entre deux modes dans l’interface : Policy et Management. En gros, lorsque NSX-T est en place, nul besoin d’avoir toutes les fonctions de configuration sous la main (ça évite de faire des bêtises en plus ^^), on peut directement basculer sur une interface concentrée sur la partie policy management. A voir en pratique, ça peut être également un moyen de ne pas trop perdre des personnes dont le rôle sera plus opérationnel que build.

La partie configuration initiale a également été simplifiée et revue en profondeur. Ça participe à l’effort de VMware de rendre ses produits plus faciles à installer depuis quelques années, on le voit très bien aussi sur l’installer vCenter 7.0 aussi. Et c’est vrai que l’installation de NSX-T est loin d’être simple quand on y est confronté la première fois. En même temps, il n’est pas inintéressant d’en comprendre les finesses pour appréhender au mieux le produit. A éprouver dans la pratique si cela est vraiment bénéfique ou juste un “cache misère”.

Fédération , VRF et multicast !

C’était attendu, la disponibilité d’un mode de fédération permet de gérer plusieurs instances de NSX-T situées sur des datacenters, voire clouds, différents. En définissant des politiques générales, des règles de sécurité génériques on met en place une hiérarchie de gestion de la sécurité multi-site et on facilite aussi la gestion de la conformité au règles de la PSSI. VMWare a mis en place, logiquement, au dessus de l’ensemble des management clusters, un “global manager” basé lui-aussi sur les mêmes fondamentaux (un cluster de management, qu’il vous faudra instancier sur un environnement à part, pour bien faire). Vous pouvez également travailler avec les security tags, qui peuvent être partagés par l’ensemble des instances. On retrouve un peu le principe des fédérations active directory, avec des groupes de sécurité “locaux” “globaux” etc. Aujourd’hui NSX DataCenter et NSX Cloud sont d’ores et déjà supportés, NSX On AWS le sera dans le future. Ca nous aidera très certainement à l’avenir alors que nous construisons en ce moment même un réseau de territoire pour l’ensemble des membres de notre GHT.

N’étant pas le plus acéré en réseau, je ne rentrerai pas dans le détail, mais c’est malgré tout important : NSX-T support désormais la création de VRF dites “lite”, permettant donc la séparation logiques de tables de routages différentes au sein d’un TIER0 (très utile pour des gros opérateurs et afin d’éviter les conflits d’IP entre clients potentiels) et supporte les flux IP Multicast (ça clairement, ça va nous servir en interne et c’est une très bonne nouvelle).

Arrivée de la fonction IPS/IDS !

Pour moi LA grande fonction de NSX-T 3.0, clairemen : le produit intègre désormais une fonction de détection et prévention d’intrusion. Au même titre que la fonction firewall, vous avez donc un nouveau menu qui se présente un peu comme la partie Distributed Firewall et qui vous donne accès à l’application de règles et politiques de prévention sur des VMs, des groupes de VM, des segments etc. Tout comme le firewall, ces stratégies s’appliquent à tout élément préparés au sein des securityGroups. Contrairement aux IPS/IDS souvent présentes dans nos réseaux à des points spécifiques (périmètre externe, périmètre interne, extranet etc.), la fonction intégrée de NSX est distribuée à travers l’ensemble de vos transport Nodes (vos ESXi ou hyperviseurs KVM). Non seulement cela décloisonne complètement cette fonction, mais en plus, cela permet de répartir sa charge CPU sur l’ensemble de vos ressources compute. On supprime le SPOF éventuel des approches classiques, on dilue totalement la consommation de CPU de ce type de service, qui peut être important à l’échelle d’une seule appliance dédié et, cerise sur le gâteau, on est capable de repérer une activité suspecte à tous les niveaux, y compris en est-ouest, de votre DC virtualisé et pas seulement sur des “points de passage”. On est donc capable de mitiger au plus tôt la menace.

Cela signifie aussi, entre les lignes, que le moteur de règles L7 a du être grandement revu et on en bénéficiera certainement dans d’autres composants (load balancing et DFW en tête).

Sur le papier, donc, que des avantages et une intégration parfaite et totalement “transparente” (autant qu’on puisse l’être avec une fonction IDS/IPS évidemment) avec votre production. Il nous tarde d’essayer cela sur le terrain, d’autant que l’obsolescence de certains des OS et applications que nous hébergeons nous oblige à mettre en place des artifices particulièrement lourds à gérer au quotidien pour les protéger. Il reste juste une question : à partir de quel niveau de licence a-t-on droit à cela. Je ne suis pas certain que la licence de base ne suffise …

Vous le verrez dans les slides, il y a forcément beaucoup de nouvelles sections et dashboards au sein de l’interface pour administrer le distributed IDS/IPS. Personnellement, je les trouve bien construits et efficaces mais encore une fois, à voir dans la pratique. Si tout cela marche bien dès le début, nul doute que cela remporte un très gros succès.

Ajoutons une pincée de dvSwitch, de LDAP/AD et de Terraform/Ansible …

Evidemment, j’ai surtout parlé jusqu’à présent des grandes features, mais il y a aussi d’autres nouveautés bienvenues, que je ne détaillerai pas ici en attendant d’en savoir un peu plus.

Tout d’abord, l’intégration “en greenfield” du dvSwitch v7.0. Si vous souhaitez déployer votre instance sur un vCenter construit nativement en v7.0, vos dvSwitchs sont donc compatible avec NSX-T. De ce que j’ai compris, dans la pratique ça signifie que NSX s’appuie directement sur vos switchs distribués, au moins pour la micro-segmentation (ainsi que l’IPS/IDS, de facto !). Pas besoin de monter un nvds spécifique donc, ni de migration à envisager. Vous installez, et les fonctions NSX sont activées directement sans coupure.

Ensuite, il est enfin possible techniquement d’utiliser des comptes LDAP/AD pour se connecter à l’interface NSX-T, sans être obligé d’y attacher VMware IDP… oserais-je dire que c’est pas trop tôt … mmmh, presque ^^. Mais comme cela n’a pas été du tout détaillé, je pense qu’en terme de RBAC, ça se limite à “administrateur/auditeur”, comme pour les comptes de base. C’est mieux que rien !

Enfin, NSX-T 3.0 met également le paquet sur les API et l’automatisation avec un support étendu de Ansible et Terraform. C’était déjà le cas avec les versions précédentes (au moins depuis la 2.4 de mémoire), mais visiblement, cela devient un thème stratégique pour les développeurs de VMware. Ca tombe bien, on y va aussi, quand on a pas une catastrophe comme le Covid19 à gérer…

Bon, on migre quand ?

Comme souvent, tout cela semple très cool sur le papier. Et même si nous avons suivi très docilement les versions de NSX-T depuis la 2.4 en Avril 2019 (2.4.1, 2.5.0, 2.5.1), on prendra le temps d’avoir un certain nombre de certitudes sur la résolution des bugs existants avant de faire le saut (voir en particulier mon billet sur les soucis de DNAT, ici). D’une manière générale, NSX-T fonctionne parfaitement depuis quelques mois chez nous en dehors des bugs connus et maîtrisés et il n’est pas envisageable que cette 3.0 ne dégrade le service d’une manière ou d’une autre. Des nouvelles fonctions, c’est top, mais pas au détriment de la qualité ^^.

En tout cas et pour les prochaines semaines, prenez tous soin de vous et sachez que nous faisons tout notre possible pour aider nos soignants et nos services supports.
Carpe diem