Désormais, l’architecture réseau Leaf & Spine est mise en place, nous allons donc y raccorder nos équipements physiques Palo Alto. Tout équipement qui doit être raccordé à l’architecture ACI sera effectué uniquement sur les commutateurs Leaf. Les équipements Palo Alto seront donc connectés à des commutateurs leaf différents et cela vaut également pour les membres actifs et passifs des clusters, pour des besoins de redondance.
Il existe deux types de flux de communication :
- Flux Est/Ouest : lorsque 2 machines, d’une même VRF, souhaitent communiquer entre elles (on peut alors parler de flux intravrf ou intrazone dans Palo Alto)
- Flux Nord/Sud : lorsqu’une machine d’une VRF souhaite communiquer avec une machine d’une autre vrf (on peut alors parler de flux intervrf / interzone)
Dans ACI, les communications sont réalisées entre EPG et ces 2 types de flux sont distingués. Afin de s’accorder au mieux avec le fonctionnement d’ACI, nous avons décidé de créer sur le cluster de firewall Palo Alto un Virtual System par VRF pour chaque type de flux (on aura donc 2 Virtual System par VRF). Un virtual system correspond à une instance virtuelle d’un firewall, permettant de simuler de nombreux firewalls complètement distincts sur une seule instance physique.
Comme dit précédemment, toute communication entre 2 EPG est régulée par un contrat qui autorise ou non la communication suivant des filtres. Pour intégrer des équipements Palo Alto, le contrat n’utilisera pas d’ACL mais un service graph.
Service Graph & Policy Base Redirect – flux Est/Ouest
Un Service Graph correspond à une chaine de liaison de service qui peut être composée de firewall, load-balancer ou tout autre service. Un service Graph définit un service par lequel va passer la communication entre 2 EPG via l’application d’un contrat.
Le service graph faisant intervenir le cluster de firewall Palo Alto permet de l’utiliser uniquement pour appliquer un filtrage sur les communications E/O. De ce fait, nous intégrerons le cluster de firewall dans le service graph via les Vsys E/O de chaque vrf.
Nous avons la possibilité en fabric ACI d’intégrer le cluster de firewall en mode OneArm : le firewall ne possède qu’une interface et qu’une seule adresse IP ; les flux entrent et sortent par la même interface, d’où l’appellation flux intrazone, car dans Palo Alto, chaque interface appartient à une zone qui représente logiquement un sous-réseau local. Le mode TwoArm étant le mode le plus classique avec une interface pour les flux entrants dans un sens et une autre interface pour les flux sortants.
Nous avons choisi pour cet exemple le mode d’intégration en OneArm afin de présenter la notion de Policy Base Redirect, que nous verrons un peu plus loin. L’intégration d’équipements de service/cybersécurité dans Cisco ACI peut être réalisée suivant plusieurs modes :
- Unmanaged (network policy mode) : la configuration de l’équipement n’est pas gérée par ACI et n’est donc pas soumise aux politiques de configuration
- Managed (service policy mode) : configuration des VLANS pour les équipements L4-7 et accès à leur configuration au travers de l’APIC
- Service manager mode : configuration des équipements depuis l’APIC Unmanaged (network policy mode)
Si on souhaite configurer les pares-feux Palo Alto indépendamment de la Fabric Cisco, alors il est recommandé d’intégrer le cluster de firewall Palo Alto en mode Unmanaged.
Maintenant que nous savons comment nous allons intégrer notre cluster de firewall Palo Alto, nous pouvons appliquer l’élément principal de Cisco ACI : le Policy Base Redirect.
Dans cet exemple, nous avons 2 EPG, WEB et APP, qui souhaitent s’échanger des messages. Ils appartiennent tous les deux au même Bridge Domain (APP-BridgeDomain).
Nous devons donc mettre en place un contrat autorisant la communication entre ces deux EPG, mais puisque l’on souhaite faire intervenir notre cluster de Palo Alto, nous appliquons un service graph sur lequel on associe notre équipement de sécurité (qui se situe dans le Bridge Domain PolicyBaseRedirect). Une fois cela réalisé, nous pouvons activer le Policy Base Redirect qui indique à chaque EPG comment envoyer son trafic vers le cluster de Palo, sachant que le cluster de Palo Alto n’appartient pas au même Bridge Domain, ni au même subnet que ces 2 EPGs.
Sachant que les équipements de service tels que les pares-feux ne sont plus en passerelle par défaut des serveurs, il est donc nécessaire de pouvoir appliquer une redirection des flux pour les faire passer par ces derniers, c’est donc le Policy Base Redirect.
L3OUT – flux Nord/Sud
Nous avons vu ci-dessus comment nos équipements de sécurité pouvaient intervenir pour les communications de type Est/Ouest, nous allons maintenant nous intéresser aux communications de type Nord/Sud.
Une communication Nord/Sud dans notre cas se symbolise par un EPG appartenant à une première VRF qui souhaite communiquer avec un autre EPG appartenant à une seconde VRF. Cette seconde VRF peut faire partie de notre tenant, donc de notre infrastructure ou bien elle peut tout à fait appartenir à Internet. Il est donc nécessaire de faire intervenir notre cluster de Palo Alto via un Virtual System N/S, complètement différent du Virtual System E/O (uniquement utilisé pour les flux Est/Ouest) ; pour pouvoir sécuriser un flux venant de notre VRF vers n’importe quel élément extérieur.
Dans ACI, n’importe quel élément extérieur est représenté par un EPG particulier appelé EXT_EPG. Il est nécessaire encore une fois de mettre en place un contrat avec chaque EPG qui souhaite envoyer du trafic vers l’extérieur. De ce fait, nous allons mettre en place un contrat entre un EPG (WEB) de notre VRF et cet EXT_EPG.
C’est l’EXT_EPG qui fournit le contrat et c’est l’EPG WEB qui le consomme ; l’EPG WEB peut donc initier une communication vers l’extérieur.
Maintenant, il est nécessaire de savoir de quelle manière, au niveau de la couche réseau, l’EPG envoie son trafic. On applique sur ce contrat un objet de type L3OUT qui permet de revenir sur des communications réseau traditionnelles et de plus laisser la fabric ACI faire de manière autonome.
De manière simple, l’EPG WEB envoie son trafic à une instance de routage de la fabric ACI et cette instance de routage a en passerelle par défaut notre cluster de Palo Alto. Notre cluster de Palo Alto a suffisamment de connaissances au niveau de sa table de routage pour pouvoir, via une route par défaut ou bien un protocole de routage dynamique comme BGP, envoyer le trafic de l’EPG WEB vers sa destination.
Une Virtual Routing and Forwarding est un contexte réseau, une instance virtuelle de routage au sein de la fabric IP. Deux VRFs sont complètement indépendantes et peuvent utiliser des adresses IP identiques sans qu’il n’y ait de conflit entre elles. Chaque VRF possède ses propres tables de routage qui ne seront inaccessibles à aucune autre VRF.
Un Bridge Domain est utilisé pour fournir une isolation broadcast et multicast, ce qui était auparavant réalisé par les VLANs. L’adressage IP sous forme de sous-réseaux correspond aux Subnets dans ACI. Lors d’une migration d’une architecture classique vers une architecture ACI, on pourrait dans un premier temps rester sur un fonctionnement similaire aux VLANs, pour cela, on met en place autant de bridge domain qu’il y a de subnets avec un seul subnet par bridge domain. Cette forme est appelée Network Centric. En dehors de cette situation, on pourrait tout à fait n’avoir qu’un seul BD par VRF et de nombreux subnets à l’intérieur de ce BD puisque l’on peut gérer l’isolation des EPGs via des fonctionnalités de redirection de trafic afin d’y appliquer des restrictions via des équipements L4-L7.
L’architecture ACI s’appuie sur le Virtual eXtensible LAN. C’est un format d’encapsulation permettant de faire transiter des trames de niveau 2 dans UDP. Cette propriété permet, par conséquent, d’utiliser une segmentation de type VLAN au-delà d’un domaine de diffusion de niveau 2. Contrairement à l’encapsulation 802.1Q, dont le champ d’identification est sur 12 bits permettant 4094 vlans, VXLAN à son champ d’identification sur 24 bits, offrant la possibilité de créer sur un même domaine VxLAN, plus de 16 millions de VLANs différents.
On voit ci-dessus que le paquet originellement émis par la machine dans le domaine VxLAN ne se retrouve qu’au niveau 5. Il est donc possible d’effectuer un routage entre les VTEP avant de décapsuler le paquet et ainsi permettre une segmentation de type V(X)LAN en s’affranchissant des domaines Ethernet.
Les Vxlan Tunnel End Point correspondent aux points d’entrée (ou de sortie) d’un domaine VXLAN, ils permettent l’encapsulation et la décapsulation des paquets VXLAN afin d’acheminer ceux-ci vers leur destination finale. VxLAN constitue la technologie clé utilisée par la Fabric ACI. Dans la Fabric ACI, chaque Leaf a une fonction de VTEP. Dans ACI, la notion de localisation est l’adresse du VTEP, tandis que la notion d’identité de l’End-Point est portée par l’@IP de l’équipement (loopback0). Donc un EndPoint est identifié par son @IP et est localisé dans ACI par l’adresse du Leaf sur lequel il est.
Nous maîtrisons désormais toutes les notions liées à l’infrastructure Cisco ACI, nous verrons dans le prochain article comment intégrer les pares-feux nouvelle génération Palo Alto Networks à cette solution SDN.
Filtrage d’EPG – MicroSegmentation
Traditionnellement, les politiques de filtrage sur les équipements de type pare-feu sont majoritairement appliquées sur des adresses IP. Sur les pares-feux Palo Alto, nous pouvons créer des groupes d’adresses IP (Address Group) et leur appliquer les politiques de filtrage.
Des plugins ont été développés pour permettre l’interconnexion entre les équipements Palo Alto et les solutions SDN de Cisco (ACI) et de VMware (NSX). Nous allons nous concentrer uniquement sur le plugin Cisco ACI.
Ce plugin permet de contacter l’APIC pour pouvoir récupérer des informations sur les EPGs de la fabric : connaître les serveurs et leurs adresses IP qui peuplent ces EPG à un instant T. Le délai de synchronisation avec l’APIC est par défaut de 60s.
Une fois que l’on a configuré les paramètres permettant de contacter l’APIC, nous pouvons utiliser une fonctionnalité Palo Alto : les Dynamic Adress Group.
Plus haut, la notion de groupe d’adresses a été présentée, ces groupes d’adresses sont peuplés de manière statique (à la main). Nous avons la possibilité de créer des groupes d’adresses dynamiques qui sont peuplés suivants des critères de correspondances : par exemple, tous les serveurs ayant leur adresse IP dans le sous-réseau 192.168.0.0/24.
Dans notre cas, nous allons utiliser des critères de correspondance créés par ce plugin ACI qui suivent le format suivant :
cisco.cl_<cluster> . tn_<tenant> . ap_<app-profile> . {epg_<EPG> | uepg_<micro-EPG>}
Cluster : la racine de la fabric ACI qui contient tous les tenants
Tenant : le container logique qui contient les profils d’application
App-profile : le profil d’application qui contient les EPG EPG : groupe d’endpoints
Micro-EPG : il s’agit de l’endpoint directement (fonctionnalité non fonctionnelle)
Nous pouvons donc peupler nos DAG plus ou moins précisément si l’on s’arrête au tenant pour récupérer tous les EPGs de notre tenant ou bien si on peuple nos DAG par un EPG pour avoir 1 DAG = 1 EPG. Cette deuxième proposition semble la plus adaptée pour pouvoir appliquer des politiques de filtrage en adéquation avec la politique ACI puisque les éléments qui communiquent sont des EPGs (et non plus des endpoint directement via leur adresse IP).
Voici un exemple de critère de sélection (match) que nous pouvons avoir. La fenêtre de gauche étant la fenêtre permettant d’éditer un groupe d’adresse en sélectionnant son type (statique ou dynamique) et ajoutant des critères de sélection.
Voici un exemple de règle de filtrage où l’on utilise un DAG en tant qu’objet de type adresse.
Nous pouvons désormais créer autant de DAG, correspondant à des EPG ou App_profile, tenant etc, et les utiliser en tant que source/destination dans des règles de filtrage afin de mettre en place notre politique de filtrage de flux.
Vous avez désormais toutes les clefs pour pouvoir configurer des pares-feux Palo Alto dans un contexte Cisco ACI.
Source :
https://docs.paloaltonetworks.com/vm-series/9-1/vm-series-deployment/set-up-a-firewall-in-cisco-aci/endpoint-monitoring-in-cisco-aci/install-the-cisco-aci-plugin-for-panorama
https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/policy/monitor-changes-in-the-virtual-environment/use-dynamic-address-groups-in-policy
https://www.cisco.com/c/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/white-paper-c11-739971.html
