Il y a quelques jours, notre dernier post traitait de la fonctionnalité Azure Service Endpoint, qui permet de ne pas exposer ses ressources Azure sur Internet, pour des raisons évidentes de sécurité.
Aujourd’hui nous allons voir une autre solution présente dans Azure, qui permet de restreindre encore d’avantage l’exposition des services, grâce à Azure Private Link.
A l’inverse de la fonctionnalité Azure Service Endpoint, où le point de terminaison est une catégorie d’un service Azure, comme le Stockage, SQL Database, ou Key Vault; Azure Private Link, propose un point de terminaison qui pointe sur un service déployé par l’utilisateur :
Il permet de cibler spécifiquement un service que vous souhaitez mettre à disposition d’autres services Azure, ou alors de services externes à Azure connectés grâce à une connexion privée de type ExpressRoute ou VPN.
Pour revenir à Azure Private Link, cette fonctionnalité, regroupe plusieurs notions :
- Private Endpoint : Qui est votre point de terminaison privé avec une interface réseau qui utilise une adresse IP privée de votre réseau virtuel
- Private Link Resource : Qui est le service cible que vous souhaitez consommer via son adressage privé.
- Private Link : C’est l’association entre votre point de terminaison privé et votre service cible.
- Private Link Service : C’est ce qui permet de mapper un service qui se trouve dans un autre VNET derrière un Azure Load Balancer Standard.
Cas d’usage n°1 :
Notre premier cas d’usage, consiste à consommer un compte de stockage, et plus précisément un objet blob, au travers du réseau privé Azure (Backbone Microsoft) avec Azure Private Link.
Pour se faire nous avons déployé les ressources Azure suivantes :
- Compte de Stockage – SA (Service PaaS qui sera pris comme exemple)
- Virtual Machine – VM
- Groupe de sécurité – NSG
- Adresse IP publique
- Interface réseau – NIC
- Disque dur – Disk
- Réseau virtuel – VNET / Subnet
1. Service PaaS exposé sur Internet
Pour notre premier exemple, notre compte de stockage n’aura aucune limitation, et sera donc exposé sur Internet :
(Ce n’est évidemment pas à reproduire pour des raisons évidentes de sécurité, mais cela permet de mieux comprendre le mécanisme de Service Endpoint).
Si on fait un test depuis notre machine, on accède à notre fichier stocké sur le SA, sans aucun problème :
Regardons notre schéma qui explique comment notre SA va être consommé, par notre VM, et potentiellement par d’autres services ou utilisateurs externes :
Lorsque notre VM souhaite se connecter ou consommer un service Azure, par défaut, le flux réseau sort sur Internet pour ensuite arriver sur le service concerné, au travers de son point de terminaison public (DNS), dans notre cas https://saprivatedemo01.blob.core.windows.net/demo/file.txt
Voyons maintenant ce que cela donne avec Azure Private Link.
2. Activation de Azure Private Link
La mise en place de Azure Private Link n’est pas compliquée, il suffit simplement de suivre quelques étapes :
- Première étape, en cliquant sur Private Endpoint au niveau du SA :
- Ensuite, on définit les informations de base :
- Après on choisit la ressource que l’on souhaite consommer, dans notre cas c’est un fichier blob :
- C’est à cette étape que l’on va sélectionner le VNET et Subnet dans lequel va être créée l’interface réseau, c’est à dire l’IP privée de notre Private Endpoint :
(Nous n’activons pas l’option Network policy for private endpoints qui permet l’utilisation des UDR et des NSG dans notre exemple, et nous choisissons une IP dynamique au sein du subnet).
- On termine en intégrant notre Private Endpoint à une zone privée DNS Azure, qui sera en l’occurrence privatelink.blob.core.windows.net : (Evidemment vous pourriez utiliser une zone privée DNS Azure existante ou votre propre serveur DNS).
Je peux maintenant récupérer le point de terminaison privé saprivatedemo01.privatelink.blob.core.windows.net que je vais pouvoir utiliser en lieu et place de saprivatedemo01.blob.core.windows.net
Tant que nous y sommes, nous désactivons l’accès public sur notre SA afin qu’il ne soit plus exposé sur Internet ce qui nous donne la configuration suivante :
Testons maintenant depuis notre VM01, que cela fonctionne correctement en passant par la zone privée DNS Azure, mais on voit que cela fonctionne aussi avec l’ancien DNS :
Un nouveau coup d’oeil sur notre schéma :
Nous constatons maintenant que le flux réseau de la VM, ne passe plus part Internet, mais directement via Private Endpoint
Et bien évidemment, le trafic Internet est bloqué étant donné que je l’ai désactivé.
Mais comment cela fonctionne t’il concrètement ?
Comme on l’a vu, lorsqu’on crée un Private Endpoint, on crée une IP privée au sein d’un subnet, et donc dans le VNET.
Mais ce n’est pas tout !
Comme on peut le voir sur l’image ci-dessous, une entrée DNS CNAME privée est créée sur le serveur DNS qui gère la zone saprivatedemo01.blob.core.windows.net et qui pointe sur la zone de DNS privée Azure que nous avons créé à savoir privatelink.blob.core.windows.net
Cas d’usage n°2 :
Dans ce second cas d’usage, nous souhaitons consommer, un service Web hébergé sur une VM02 déployée dans un autre VNET02 qui a la même adresse que notre premier VNET01.
Ainsi cette configuration, rend impossible la mise en place d’un VNET Peering entre les 2 VNET à cause du chevauchement (overlapping) d’adressage IP des VNET.
C’est là que Private Link Service entre en jeu.
Comme nous l’avons évoqué précédemment, nous allons pouvoir consommer notre service, notre VM02, au travers d’un Azure Load Balancer Standard.
On commence donc par créer un LB interne, c’est à dire avec un adressage privé, à savoir LB01, dans le VNET02 où est stocké notre VM02.
- Renseignons les informations de base :
- Nous sélectionnons le VNET02, en laissant Azure définir son adresse IP privée :
- Ensuite on définit le point de terminaison sur lequel va être envoyé le trafic lorsque nous arriverons sur LB01, qui sera donc notre VM02 :
- L’étape suivante permet de définir une règle qui va associer le point de terminaison, au port d’écoute de LB01, ainsi que le port sur lequel renvoyer le trafic vers la VM02.
On en profite aussi pour créer une sonde qui vérifiera l’intégrité du service côté VM02 :
- Les étapes suivantes de configuration ne sont pas nécessaires, on peut donc cliquer sur review and create pour créer le LB.
Voici le résultat après quelques secondes :
Maintenant que nous avons créé notre LB01, passons à l’étape suivante qui est la création de notre Private Link Service.
Dans la barre de recherche du portail Azure, nous recherchons Private Link, nous arrivons sur le service Private Link Center.
Il nous suffit de cliquer sur Create Private Link Service :
- Commençons par renseigner les informations :
- L’étape suivante est importante car c’est ici que nous allons sélectionner notre LB01, ainsi que la configuration associée :
- Ensuite nous définissons, les accès qui permettent de consommer le Private Link Service :
(Nous limitons l’accès à notre souscription, mais il est évidemment possible de limiter uniquement l’utilisation à un service, comme avec notre VM01).
On peut ensuite directement cliquer sur review and create pour créer notre Private Link Service.
Maintenant que LB01, ainsi que le Private Link Service sont créés, passons à la dernière étape qui est la création de notre Private Endpoint.
Deux possibilités existent, la première, retourner sur le service Private Link Center, la seconde, se rendre sur le Private Link Service que nous venons de créer. Pour ma part je choisis la seconde option.
- Au niveau de mon PrivateLinkService01, je vais maintenant créer mon Private Endpoint :
Sur l’onglet Resource nous n’avons rien à configurer, mais pourquoi ?
Simplement parce que lors de la création du Private Link Service nous avions sélectionné l’option Auto-approve, et comme nous n’avons qu’un seul Private Link Service au sein de cette souscription, il est sélectionné par défaut :
- Ensuite nous sélectionnons le VNET dans lequel déployer notre Private Endpoint, c’est donc le même que celui où est hébergée notre VM01, c’est à dire VNET01. Nous laissons la méthode d’allocation de l’IP à dynamique :
- A ce jour, l’option DNS n’est pas supportée pour un Private Endpoint connecté à un Private Link Service, je me connecterai donc au travers de son IP privée.
On peut ensuite directement cliquer sur review and create pour créer notre Private Endpoint :
- Je récupère l’IP du Private Endpoint nouvellement créé :
- Ne reste plus qu’à tester l’accès à ma VM02, depuis ma VM01 via la combinaison du Private Link Service et du Private Endpoint, qui est complètement transparente pour l’utilisateur.
Tout fonctionne comme attendu :
Un dernier coup d’oeil à notre schéma, montre que nous sommes capables de consommer le service hébergé sur la VM02 qui possède le même adressage réseau que notre VM01, grâce à notre LB interne :
A l’heure où nous écrivons ces quelques lignes, voici la liste des services Azure qui sont actuellement supportés :
- Azure API Management – General Availability
- Azure App Configuration – General Availability
- Azure Automation – General Availability
- Azure Backup – General Availability
- Azure Batch (batchAccount) – General Availability
- Azure Batch (nodeManagement) – Preview
- Azure Bot Service – General Availability
- Azure Cache for Redis – General Availability
- Azure Cognitive Services – General Availability
- Azure Container Registry – General Availability
- Azure Cosmos DB – General Availability
- Azure Data Factory – General Availability
- Azure Database for MariaDB – General Availability
- Azure Database for MySQL – General Availability
- Azure Database for PostgreSQL – Single server – General Availability
- Azure Digital Twins – Preview
- Azure Event Grid – General Availability
- Azure Event Hub – General Availability
- Azure File Sync – General Availability
- Azure Files – General Availability
- Azure HDInsight – General Availability
- Azure IoT Hub – General Availability
- Azure Key Vault – General Availability
- Azure Kubernetes Service – Kubernetes API – General Availability
- Azure Machine Learning – General Availability
- Azure Managed Disks – General Availability
- Azure Migrate – General Availability
- Azure Monitor (Log Analytics & Application Insights) – General Availability
- Azure Queue storage – General Availability
- Azure Relay – Preview
- Azure Search – General Availability
- Azure Service Bus – General Availability
- Azure SignalR – General Availability
- Azure SQL Database – General Availability
- Azure Static Web Apps – Preview
- Azure Synapse Analytics – General Availability
- Azure Table storage – General Availability
- Azure Web Apps – General Availability
- Microsoft Purview – General Availability
La liste des services peut être consultée ici : https://docs.microsoft.com/en-us/azure/private-link/availability
Pour résumer, Private Link est une excellente solution pour ne pas exposer ses services PaaS sur Internet.
Aujourd’hui tous les services ne sont pas encore supportés, mais la liste évolue très régulièrement.
Microsoft encourage l’utilisation de Private Link pour des raisons évidentes de sécurité, mais aussi pour réduire la latence en passant par le backbone Microsoft, au lieu d’utiliser Internet.
