Quel meilleur timing que cette fin de confinement annoncée pour donner signe de vie et essayer de reprendre un rythme de publication plus digne de vous sur ce blog ? Je vous propose donc de relancer tout cela aujourd’hui avec un article technique sur NSX-T, encore, et plus spécifiquement au sujet de la fameuse directive “Apply-To” qu’on trouve dans la section des stratégies et règles de sécurité. En effet, la maîtrise de l’Apply-To mérite quelques essais et explications. Alors, allons-y, petits Padawans ! (oui, je me la joue un peu, mais ça fait du bien d’écrire à nouveau, donc on va faire dans le léger ^^)

Mais, crénon, qu’est-ce que c’est quoi donc ?

D’abord, l’Apply-To c’est quoi, fondamentalement ? Le principe est relativement simple : vous disposez d’un champ spécifique “Apply-To” qui représente en fait “la portée” des filtres et comportements que vous allez décrire sur chacune de vos règles (et sur les policies aussi, on le verra). Par défaut, vous noterez la présence du sigle DFW aka Distributed FireWall, le fameux bien nommé pare-feu intégré aux couches NSX installées sur chaque transport node. Cela signifie que par défaut toute règle s’appliquant à DFW a une portée sur l’ensemble des flux internes. On se trouve ici dans le coeur de fonctionnement de NSX-T, mais attention, il existe aussi des règles et policies Nord-Sud, qui sont le domaine des Edges Nodes. Ils on aussi des Apply-To d’ailleurs, mais vous pourrez le constater, il sont renseignés automatiquement – et non modifiables – avec le routeur sur lequel vous travaillez.

On pourrait se dire que c’est plutôt une bonne idée que toutes les règles soient appliquées. Quelle que soit l’origine et la destination des flux réseau, la sécurité est donc maximale (en théorie). Sauf que dans la pratique, cela peut vite poser un problème… et un gros. Quand vous avez 10, 20, 50 règles, pas de souci, les conditions de ces filtres sont passées rapidement par NSX-T avant de délivrer les paquets. Mais si vous disposez, disons, de 3000 VMs et que chacune nécessite 3 ou 4 règles en moyenne, cela vous donne une combinatoire qui fait froid dans le dos : se sont plus de 10000 règles qui doivent être vérifiées avant de prendre la décision de délivrer le paquet ou non. Alors, ok, certes, bon, d’accord, j’exagère un peu ok ok ok …. NSX-T, comme tout logiciel intégrant un firewall, dispose de nombreuses optimisations pour simplifier l’évaluation (on y trouve souvent des compilateurs de règles qui sont chargés de cela d’ailleurs) et s’appuie sur l’ensemble de la puissance des transport nodes. Cela étant dit, contrairement à des firewalls physiques traditionnels, il ne dispose d’aucun accélérateur hardware pour décharger le CPU et limiter les prises de décisions au strict minimum. La conséquence arrivera inévitablement : une saturation ou tout du moins un engorgement et une inexorable augmentation sensible de la latence au sein de votre environnement virtualisé.

De plus, quand on commence à vraiment jouer avec ce Apply-To, on se rend compte que les règles associées peuvent être particulièrement simplifiées et optimisées, rendant leur compréhension beaucoup plus évidente, même pour une personne qui n’a jamais travaillé initialement sur l’environnement. C’est donc bon pour la planète NSX-T et en plus, c’est bon pour le moral, bon le moral, ben yakafokon !

Alors, comment ça marche ty donc, Jammy ?

Objet ou IP, il faut choisir

Première chose à noter : vous pouvez décider d’utiliser l’Apply-To à deux niveaux, séparément ou en complément : au niveau de la policy et/ou au niveau de la règle. Si vous choisissez d’utiliser le Apply-To à l’échelle de l’ensemble d’une policy, les Apply-To des règles sous-jacentes sont désormais inopérants. En plus simple, le Apply-To sur une policy est prioritaire sur celui d’une règle.

De plus, vous devez connaître une autre loi fondamentale : ne JAMAIS, absolument JAMAIS leur donner à manger après minuit … aheum, non, désolé, hors-sujet, je recommence… De plus, vous devez connaître une autre loi fondamentale, ne jamais utiliser de groupes de sécurités contenant des IPs, le Apply-To ne fonctionne qu’avec les VMs, les segments, les segment-ports et les tags NSX. N’espérez pas utiliser un groupe de sécurité indiquant des range d’IP, ce la ne fonctionnera pas. J’arrête pas de vous le dire, bon alors, maintenant on m’écoute, ok ?

On teste ?

Pour illustrer mon propos, je vous propose quelques tests à faire chez vous, mais oui Maryse, ou, aussi, de me croire sur parole vis à vis des résultats que je vous indique… c’est vous qui voyez ^^. Bon, un peu de sérieux, je me disperse trop en ce moment. Voici une petite liste qui m’a permis de valider les différents cas de figure. Dont certains sont assez troublants, voir contre nature …. brrrrr

Voici ce que j’ai construit pour tester tout ça. Au passage, ça vous permet de voir à quel point les nouveautés de NSX-T 3.0 sont si pratiques !

On va utiliser la VM test-10.10.2.100. Pour pouvoir faire mes essais, j’ai créé des security groups reposants sur des filtres différents, à savoir :
– sg-ip-10.10.2.100 contenant uniquement l’IP de la machine
– sg-vm-10.10.2.100 contenant directement la sélection de la VM en question
– sg-vmtag-10.10.2.100 dont les objets sont inclus s’ils sont taggués st-testag
– sg-segment-10.10.2.0 contenant le directement le segment de rattachement de la VM
– sg-ip-RienAVoir contenant une IP qui n’a strictement rien à voir avec nos tests (192.168.1.1)

Enfin, j’ai créé une policy et une règle associée pour tester simplement le ping vers une IP publique.
Pour l’exemple j’ai pris un des dns de Google : 8.8.8.8
Voici les résultats et conclusions :
1- Policy avec Apply-To sur “sg-ip-10.10.2.100” et la rule ICMP Echo-request avec Apply-To sur DFW : le ping ne passe pas
2- Policy avec Apply-To sur “sg-vm-10.10.2.100” et la rule ICMP Echo-request avec Apply-To sur DFW : le ping passe
3- Policy avec Apply-To sur “sg-vmtag-10.10.2.100” et la rule ICMP Echo-request avec Apply-To sur DFW : le ping passe
4- Policy avec Apply-To sur “sg-vm-10.10.2.100” et la rule ICMP Echo-request avec Apply-To sur “sg-ip-RienAVoir” : le ping passe !

Les 4 tests ci-dessous démontrent que le Apply-to au niveau de la policy est bien prioritaire par rapport aux apply-to des règles et qu’il ne marche qu’avec des objets que NSX-T peut identifier dans sa base de données (ce n’est pas le cas des ranges d’IP – a forcieri – publiques).

La seconde série de tests concerne directement les règles, sans l’application d’un Apply-To spécifique sur la policy au dessus.

1- Rule ICMP Echo-request avec Apply-To sur “sg-vm-10.10.2.100” : le ping passe
2- Rule ICMP Echo-request avec Apply-To sur “sg-vmtag-10.10.2.100” : le ping passe
3- Rule ICMP Echo-request avec Apply-To sur “sg-ip-10.10.2.100” : le ping ne passe pas !

Les deux premiers tests sont somme toute logiques, par contre, le troisième indique clairement que l’utilisation d’un range d’IP dans un security group ne fonctionne pas. Mieux, si vous créez une règle générale pour le segment de la VM sg-segment-10.10.2.0 en indiquant que vous autorisez le ping pour tout le monde et que vous refaites le test 3, toutes les VM du segment continuerons à pinguer correctement, sauf la VM de test ! Non seulement l’utilisation des security group à base d’IP ne marche pas en Apply-To, mais, pire, cela invalide litérallement la règle et peu conduire à des comportements très bizarres, difficiles à diagnostiquer.

Conclusion

Tous mes tests ont été réalisés avec la version 3.0 de NSX-T. Je vérifierai rapidos tout cela la semaine prochaine sur notre production en 2.5.1, mais je ne suis pas inquiet quant à la confirmation que cela fonctionne de la même façon.

Je profite enfin de ce petit billet pour vous mentionner une petite découverte sur les règles de sécurité de 3.0 : vous pouvez désormais indiquer des horaires d’activation sur vos règles. Je n’avais pas lu cela dans les release notes (peut-être une erreur de ma part), mais c’est bon à savoir.

Voila donc une fonction “Apply-To” très pratique et très puissante aussi, que je vous conseille fortement d’utiliser à l’avenir dans vos productions, si ce n’est pas encore déjà fait. Elle apporte une nouvelle dimension à l’application des règles de filtrage DFW tout en soulageant fortement la compilation et l’exécution de vos règles de sécurité sur NSX-T. Je suis comme toujours très curieux d’avoir vos retours sur ce sujet, donc si vous avez des usages spécifiques ou si vous avez mis en oeuvre des filtrages astucieux grâce à l’Apply-To, n’hésitez pas, les commentaires sont toujours ouverts, aucune distanciation social ici-bas ^^

Bon dé-confinement à vous.