Gérer son projet de migration cloud : 6 conseils pour éviter les dérives
Entre les risques à anticiper, les délais serrés et la maîtrise financière d’une migration cloud, généralement stratégique pour l’entreprise, chaque...
Azure Purview : comment gérer l’intégration réseau ?
Temps de lecture : 12 mins
Le Rhino
Azure Purview est un outil de gouvernance des données unifié pour cartographier, cataloguer et gérer vos données, qu’elles soient locales (on premise) ou dans le cloud.
L’objectif de cet article n’est pas de présenter la solution en elle-même, mais de voir comment elle s’intègre au niveau réseau dans Azure, dans un contexte sécurisé.
Je m’inspire d’une expérience d’implémentation chez un de nos clients, avec des contraintes réseau et sécurité fortes ! Ces contraintes imposent une exposition réseau limitée à l’interne, et de pouvoir se connecter à des sources de données de différents types & niveaux de classification.
Imaginez que vous ayez plusieurs coffres forts, dans différents lieux, avec une carte sur laquelle vous avez noté tous les emplacements et ce qu’ils contiennent. Est-ce que vous laissez cette carte accessible à tous ?
Vous l’avez deviné, Azure Purview, c’est cette carte !
Avec ce prérequis, je balaye dans cet article la partie réseau de Purview, trois cas d’usage illustrés pour la compréhension globale, ainsi que quelques analyses et recommandations techniques.
Configuration réseau
Le paramétrage global est simple, basique : un firewall en mode On/Off pour l’accès public de Purview. Cela couvre l’accès au portail Purview et au compte (account), mais aussi au compte de stockage managé. Le firewall de ce dernier suit automatiquement.
Forcément dans notre cas, l’accès public est désactivé !
Configuration Firewall
Il n’est pas possible d’utiliser un filtrage sur des ranges IP ou via des « Azure Trusted Services » par exemple. Un peu dommage, car cela va impliquer d’utiliser un VNet (réseau virtuel).
La connexion à un VNet est possible par l’utilisation de Private Enpoints, au nombre de 5 : Purview Account & Portal, Storage account Blob & Queue et l’Event Hub. Il est possible de réduire le nombre de ces endpoints, certains cas d’usage ne les requièrent pas tous.
Configuration Private Endpoints portail / compte Purview
Configuration Private Endpoints des ressources managées (Storage Blob/Queue et Event hub)
Cas d’usage « global » avec ressources Azure/Cloud
Lorsque les sources de données que Purview doit analyser sont accessibles en direct, que ce soit dans Azure ou sur le Cloud, les traitements sont réalisés directement par l’intégration runtime d’Azure Purview.
L’accès au portail Purview et aux endpoints d’ingestion est possible via les Private Endpoints (PE). Que vous utilisiez un réseau local interconnecté via VPN ou ExpressRoute au VNet disposant des PE, l’accès à Purview se fait alors de manière totalement privatisée.
À noter : Microsoft ne publie pas les adresses IP utilisées par le service Purview pour initier les connexions vers les data sources, sécuriser les flux peut donc s’avérer complexe.
Le service Purview dispose d’une « Managed identity » de type système qui permet de s’authentifier sur d’autres ressources, voire de filtrer via cette identité pour les services le supportant via les « Azure trusted services » (par exemple, Azure storage et Data Lake Gen2 le supportent).
Cas d’usage avec ressources Azure privatisées ou locales
J’entends par ressource Azure « privatisée » le fait qu’elle ne soit accessible que par un VNet via un Private Endpoint.
Dans ce cas, comme pour les sources de données on premise, l’utilisation d’un composant « Self Hosted Integration Runtime » (SHIR) est nécessaire.
Ce composant, hébergé sur une machine virtuelle, est connecté à Azure Purview et va servir de relai pour se connecter aux sources de données.
Localement, il est difficile de faire autrement, sauf peut-être en conteneur ; cependant, sur Azure une intégration VNet native aurait été plus élégante… Demander un composant IaaS pour faire communiquer des services PaaS, c’est un peu « old school » ! 😀
Ce composant peut vous être familier, il est en effet commun à Azure Data Factory, Azure Synapse Analytics and Azure Purview.
Cas d’usage Synapse
Le cas d’usage Synapse n’est pas le plus évident, et pourtant il n’est pas beaucoup plus complexe que le précédent.
Trois scénarios d’usage entre Synapse et Purview sont possibles.
Scan des données SQL
Ce cas est traité à l’identique du précédent, via une SHIR.
Découverte et exploration de données depuis le portail Synapse Studio
L’accès utilisateur via les PE Account & Portal de Purview répond à ce besoin. Cela enrichit l’expérience dans Synapse studio.
Exécution de Pipeline et rapport du lignage de données
Synapse remonte à Purview les informations de transformation des données, exécution de pipelines, etc. Il nécessite 4 nouveaux PE à positionner dans le VNet managé de Synapse. Les plus observateurs auront noté qu’il en manque un, c’est normal… Synapse n’a pas besoin du portail !
Finalement, pour couvrir tous les scénarios, cela nécessite un peu de tuyauterie…
Private Endpoints : DNS & Proxy
DNS
Comme souvent, la résolution DNS est primordiale pour privatiser des flux cloud.
En utilisant une SHIR hébergée dans Azure, utilisez de préférence les private DNS zone intégrées, soit via la résolution native Azure, qui est plus simple, ou via des redirections de zones si vous gérez votre DNS.
Une autre zone « privatelink.purviewstudio.azure.com » est mentionnée dans la doc Microsoft, mais celle-ci ne semble plus être nécessaire depuis la disponibilité générale du service ! Elle n’est plus créée avec les PE.
La redirection DNS est valable en local également, mais s’il n’est pas possible de l’utiliser, il reste l’option de créer les noms dans votre DNS interne. Voire, en dernier recours, âmes sensibles s’abstenir, d’utiliser le bon vieux fichier host. Oui, il est toujours là, et c’est même dans la documentation.
Microsoft fournit donc une liste de 21 noms à créer. Avec un mix de noms spécifiques à votre implémentation (le nom de votre compte Purview, ses ressources managées…), et de noms publics et génériques dont les flux passent via les PE.
Source : https://docs.microsoft.com/en-us/azure/purview/catalog-private-link-name-resolution
Si vous avez plusieurs comptes Purview, ce mix privé/public peut rediriger de fait des flux publics vers un PE aléatoire si vous avez plusieurs enregistrements… Cela concerne principalement le PE « portal » et la facturation de son trafic s’en trouvera moins exacte. Enfin, elle sera aussi aléatoire que la réponse DNS !
Après analyse, les flux du Private Endpoint « portal » ne faisant passer que des résolutions publiques génériques (sans endpoint spécifique), il est possible de se passer du PE et de ses multiples résolutions.
Vous pouvez, au choix, :
- laisser sortir ce flux via Internet,
- soit via un unique PE (attention de fait à l’adhérence à celui-ci). Cela n’affecte pas le comportement du portail, celui-ci vérifiant l’accès privé via le Private Endpoint account.
Pour que ce soit plus parlant, voici les résolutions DNS depuis plusieurs emplacements.
Résolution depuis une VM dans Azure, via le DNS Azure avec les zones DNS privées (créées automatiquement avec les PE).
Deux sont étranges… Une résolution est HS et une autre publique !
Pour comparaison, la résolution publique.
Résolution publique depuis un site client (redirection DNS inconnue, visiblement quelque part au UK ?).
Résolution publique depuis un opérateur (l’Agrume)
L’enregistrement non résolu l’est toujours, et l’enregistrement « gateway.purview.azure.com » est visiblement régionalisé, son IP et nom associé changent.
Avec cette analyse, à vous de voir si vous créez les 21 enregistrements de la documentation, modulo les enregistrements inutiles, si vous vous passez du PE portal… N’oubliez pas de tester et de vérifier où passent vos flux ! Attention toutefois à être dans une configuration supportée par Microsoft si vous rencontrez des problèmes.
Proxy
En théorie
Si vous êtes dans un environnement cloisonné, où la seule porte de sortie est un proxy, il faudra bien l’utiliser pour connecter la SHIR, notamment pour qu’elle joigne Azure AD pour s’authentifier.
La déclaration du proxy se fait dans sa configuration, mais n’oublions pas que les flux privatisés doivent atteindre les PE, donc être exclus du proxy…
Donc, deux fichiers .xml spécifiques sont à peupler selon une syntaxe toute .Net-ienne !
Ces fichiers à modifier sont dans le dossier d’installation de la SHIR :
- diahost.exe.config
- diawp.exe.config
Si cela fonctionne, que vos scans Purview remontent des informations de vos sources, tant mieux !
In da Real world
En intégrant Synapse en tant que source de données, nous avons constaté qu’un job se lançait sans jamais détecter de contenu. Aucun log ne relevait clairement le problème et le support Azure n’a pas réussi à identifier un problème spécifique.
Quelques pistes ont été identifiées comme le fait d’avoir les Private Endpoints dans un autre VNet via un peering, ce cas n’étant jamais documenté et presque présenté comme prérequis. Malgré un placement des PE dans le même réseau & sous-réseau que la machine, le problème persistait.
Après une analyse un peu plus poussée sur la VM SHIR, après avoir revu de nombreuses fois les résolutions DNS, les exceptions Proxy, etc. sur la machine SHIR, un processus se lançait, et tentait désespérément une connexion directe vers des IP publiques d’Azure sans tenir compte du proxy.
En calquant le fonctionnement pour les exécutables précédents, le problème a été résolu en générant une section de configuration de proxy pour le processus en question, via un fichier de configuration (à placer dans le même répertoire que l’exe) :
- Microsoft.DataMap.Agent.Connectors.Azure.DataFactory.ServiceHost.exe.config
Visiblement ce processus a la charge d’exécuter les jobs de scan Purview dans la SHIR. Nous avons constaté une fois le problème résolu qu’il se connectait à Synapse sur le port 1433 via son propre PE, au proxy et aux PE Purview.
Scan Synapse avant / après : les assets sont peuplés !
Sources SHIR & Proxy :
Conclusion
La privatisation de ressources Cloud n’est jamais simple, Purview n’échappe pas à la règle.
Selon vos sources et leur niveau de sécurisation ou d’isolation, définir une architecture cible pour couvrir les différents cas d’usage et leur intégration peut se révéler complexe.
J’espère que cet article aura permis de vous éclairer sur le fonctionnement de Purview au niveau infrastructure et d’appréhender quelques-unes de ses dépendances !