Reverse ETL et cloud privé : guide pratique pour comprendre les concepts et les enjeux

Reverse ETL et cloud privé : guide pratique pour comprendre les concepts et les enjeux

Une force irrésistible face à un obstacle immuable"

Les architectures de données modernes répondent souvent à une même exigence : permettre aux équipes concernées d’accéder aux données stockées dans les entrepôts de données. Mais dès lors que des règles particulièrement strictes de sécurité réseau s’appliquent, les choses peuvent rapidement se compliquer. Et parfois, on se retrouve face à une véritable impasse.

D’une part, Segment Reverse ETL, nécessite un point de terminaison HTTPS accessible depuis le réseau public pour assurer son fonctionnement. De l’autre côté se trouve un Databricks SQL Warehouse hébergé dans un réseau virtuel privé Azure (VNet), protégé par des mécanismes d’isolation réseau et inaccessible depuis l’Internet public.

Cette configuration impose deux contraintes majeures :

• Segment a besoin d’un point de terminaison HTTPS accessible publiquement.
• Le Databricks SQL Warehouse ne dispose d’aucun accès public.

Résultat : les besoins de connectivité de l’un se heurtent aux exigences d’isolation réseau de l’autre. Impossible, dans ces conditions, d’établir une connexion directe entre les deux. D’un côté, les politiques de sécurité interdisent tout accès public. De l’autre, Segment ne peut pas établir de connexion avec le service Databricks. Nous allons voir comment nous avons conçu une solution d’interconnexion permettant de surmonter ces difficultés sans compromettre les règles de sécurité en vigueur.

Segment Reverse ETL à l’épreuve : trois tentatives infructueuses avant de trouver la bonne solution

Afin de résoudre ce problème, nous avons étudié plusieurs options dans le cadre d’une preuve de concept (PoC). La solution retenue n’a toutefois pas été identifiée dès notre première tentative. Nous avons organisé cette preuve de concept (PoC) sous la forme d’un sprint visant à identifier les obstacles techniques précis empêchant l’établissement de la connexion entre les deux services. Chaque étape de l’évaluation a permis de déterminer les conditions requises pour mettre en œuvre une solution opérationnelle.

Évaluation de la connectivité directe

Nous avons commencé par étudier l’approche la plus simple, consistant à établir une connexion directe entre Segment Reverse ETL et le Databricks SQL Warehouse.

• Résultat :aucune communication n’a pu être établie.
• Enseignement : aucune négociation de connexion ne peut aboutir avec un serveur inaccessible. Les points de terminaison privés sont précisément conçus pour limiter leur accessibilité.

Cette approche a échoué pour les raisons suivantes :

• Le Databricks SQL Warehouse n’était pas accessible depuis l’Internet public.
• Segment ne disposait d’aucun accès aux points de terminaison privés.

Ces résultats ont confirmé l’impossibilité de mettre en place une connexion directe dans l’architecture réseau privée retenue.

L’approche suivante consistait à exploiter le connecteur Databricks de Segment en conservant sa configuration standard.

Configuration standard du connecteur

Nous avons ensuite évalué la possibilité d’utiliser le connecteur Databricks de Segment avec ses paramètres de configuration standard. Cette tentative a immédiatement révélé deux limitations majeures :

Incompatibilité des mécanismes d’authentification : Segment nécessitait un mécanisme d’authentification spécifique (Basic/Client Credentials), alors que Databricks imposait une procédure complète de négociation OAuth, non prise en charge par la version actuelle du connecteur.

Restriction liée au nom d’hôte : le pilote Databricks est assez exigeant sur ce point. Il utilise une vérification strings.Contains afin de déterminer si le nom d’hôte contient la chaîne azuredatabricks.net. Si cette condition n’est pas remplie, aucune tentative de connexion n’est effectuée.

Afin d’accélérer la mise en œuvre de la solution, l’introduction d’un proxy externe a été retenue comme l’approche la plus pragmatique.

Configuration d’un nom d’hôte personnalisé et mappage DNS

Afin de satisfaire aux exigences de validation imposées par le connecteur, nous avons défini un nom d’hôte personnalisé intégrant la chaîne azuredatabricks.net.

Exemple de format :

• dev.staging.azuredatabricks.net.<custom-domain>

Une correspondance DNS a ensuite été établie entre ce nom d’hôte et l’adresse IP publique d’Azure Application Gateway.

Cette configuration permettait d’assurer :

• La résolution DNS du nom d’hôte vers l’adresse IP publique correspondante.
• La conformité aux règles de validation des noms d’hôte appliquées par le connecteur.

Le comportement du pilote Databricks SQL a également été pris en compte :

• Le pilote identifie le fournisseur de services cloud concerné en examinant le nom d’hôte.
• Dans la mesure où cette vérification repose sur la recherche d’une sous-chaîne (strings.Contains), il était possible de définir un nom d’hôte satisfaisant aux critères du pilote, tout en assurant le routage des requêtes à travers une infrastructure réseau personnalisée.

Cependant, cette approche ne suffisait pas à elle seule, pour plusieurs raisons :

• Aucune logique applicative côté serveur n’avait été mise en place pour traiter les requêtes.
• Nous n’avions pas encore mis en place le mécanisme d’authentification nécessaire.
• Rien ne permettait non plus d’assurer le routage et la transformation des requêtes.

Nous avons ainsi confirmé qu’une configuration DNS adaptée était indispensable pour satisfaire aux exigences de validation du connecteur, mais ne suffisait pas à assurer l’intégration des deux systèmes.

Tentative avec Azure Application Gateway seul

Nous avons déployé Azure Application Gateway afin de gérer le trafic entrant depuis le réseau public. Cette solution permettait de résoudre le problème d’accessibilité réseau. Toutefois, Azure Application Gateway ne disposait pas de la logique applicative nécessaire pour orchestrer les échanges complexes de jetons d’authentification exigés par Databricks.

Azure Application Gateway assurait correctement les fonctionnalités suivantes :

• Prise en charge du trafic entrant depuis le réseau public
• Terminaison des connexions TLS
• Acheminement des requêtes

Toutefois, cette architecture ne permettait pas de répondre à l’ensemble des exigences d’intégration, pour les raisons suivantes :

• Absence de prise en charge des échanges de jetons d’authentification OAuth
• Impossibilité d’exposer les points de terminaison requis pour les mécanismes d’authentification
• Absence de mécanismes permettant d’effectuer les transformations nécessaires au niveau de chaque requête

Cette évaluation a confirmé que les seules capacités de routage ne suffisaient pas à assurer l’interopérabilité entre Segment et Databricks.

Gestion de l’authentification et du routage au moyen d’une couche de proxy

Un service proxy sur mesure a donc été introduit afin de résoudre les problèmes d’authentification et de connectivité empêchant l’intégration de Segment et de Databricks.

Le service proxy a été conçu pour satisfaire aux exigences du connecteur Segment tout en garantissant la sécurité des communications avec Databricks.

Niveau d’authentification

• Le proxy expose des points de terminaison compatibles avec OIDC, qui permettent de :
• /oidc/v1/token
• /oidc/.well-known/oauth-authorization-server
• /oidc/jwks.json
• Prise en charge de l’authentification HTTP Basic utilisée par Segment.
• Génération de jetons JWT signés au moyen de l’algorithme RS256.
• Validation des jetons JWT entrants à l’aide de mécanismes de cryptographie asymétrique reposant sur des paires de clés publique et privée.
• Gestion du cycle de vie des jetons au moyen d’identifiants uniques (jti).

Échange de jetons avec Databricks

• Obtention de jetons d’accès auprès de Databricks à l’aide du flux OAuth client_credentials.
• Mise en cache des jetons afin de réduire le nombre de requêtes d’authentification répétées.
• Substitution de jetons OAuth Databricks valides aux jetons initialement émis par le proxy et transmis dans les requêtes entrantes.

Couche de transfert des requêtes

• Achemine les requêtes vers les points de terminaison Databricks (/api, /sql)
• Harmonise les en-têtes et supprime ceux susceptibles de provoquer des conflits avant de transmettre les requêtes.
• Assure la compatibilité avec les API Databricks SQL.

Capacités opérationnelles

• Point de terminaison de surveillance de l’état de fonctionnement (/health)
• Prise en charge du protocole TLS pour garantir la sécurité des communications
• Traçabilité des requêtes avec visibilité sur les temps de latence, permettant de différencier les durées de traitement au niveau du proxy et des services en amont

Cette architecture a permis de remédier aux problèmes suivants :

• Échecs de validation au niveau du connecteur
• Incompatibilité des mécanismes d’authentification
• Échecs d’exécution des requêtes

Notre proxy remplissait donc une double mission : faire le lien entre les différents mécanismes d’authentification de Segment et de Databricks, tout en assurant un acheminement maîtrisé des requêtes entre les deux environnements.

La solution décisive : un proxy assurant la substitution des identifiants d’authentification

Pour résoudre le problème, un simple mécanisme d’acheminement des requêtes ne suffisait pas : nous avions besoin d’un composant capable d’adapter les mécanismes d’authentification des deux environnements. Nous avons donc développé un service proxy sur mesure, intercalé entre Azure Application Gateway et Databricks.

Le principe clé de notre solution

Pour répondre aux exigences des deux systèmes, notre proxy réalisait quelques petits «∘tours de passe-passe∘» techniques :

• L’astuce du nom d’hôte : nous avons attribué au proxy un nom d’hôte personnalisé, tel que dev.staging.azuredatabricks.net.custom-domain.com. Comme celui-ci contenait la fameuse chaîne de caractères attendue, le pilote Databricks acceptait la connexion.
• Échange de jetons d’authentification : le proxy expose des points de terminaison compatibles avec OpenID Connect (OIDC). Il reçoit les identifiants transmis par Segment, obtient un jeton d’accès OAuth valide auprès de Databricks, le conserve en cache pour optimiser les performances, puis l’insère dans la requête transmise au service cible.
• Nettoyage et normalisation des en-têtes : le proxy supprime ou adapte dynamiquement les en-têtes HTTP afin que les requêtes transmises à Databricks respectent les conventions et les exigences de ses API.

L’architecture finale

Cheminement des requêtes :