Recette d’un Datalake et Key Vault à la sauce Terraform

Tout au long de cet article, vous allez découvrir la drôle de recette d’un Datalake et Key Vault à la sauce Terraform ! Nous allons apprendre ensemble à réussir ce mélange sans perdre les droits sur le Datalake notamment lors d’un redéploiement.

Les ingrédients nécessaires pour réaliser notre Datalake

J’ai récemment dû mettre en place un Datalake crypté avec une clé du Key Vault. J’avais également un Data Factory qui utilisait le Datalake crypté. Le tout était épicé (déployé) avec Terraform.

Dans cet article, je vous propose de plonger avec moi au cœur de ma recette !

Erreur de pipeline du Data Factory

Lors du premier déploiement, tout se passait bien, les ressources étaient déployées et les pipelines du Data Factory accédaient correctement au Datalake.

Alors que tout semblait fonctionner, le déploiement à progressivement commencé à se corser. Sans explication, le pipeline du Data Factory tombait en erreur : « Azure Key Vault access denied (user-managed)».

L’erreur persistait malgré le succès des test de connexion depuis linked service du Data Factory vers le Datalake. Après quelques essais, je me suis également rendue compte qu’il m’était impossible de déposer un fichier sur le Datalake. En effet, le fichier se créait, mais sa taille restait de 0 bytes systématiquement.

Résolution de l’erreur en trois étapes

Si vous aussi vous rencontrez le même problème que moi, j’ai la solution ! Je vous présente les trois grandes étapes à suivre pour réussir ma recette sur Terraform :

• Première étape : la création d’un Key Vault avec les policies affectées au compte de service principal, il me sert à exécuter le pipeline Data Factory en utilisant la propriété access_policy de la ressource azurerm_key_vault :

• Deuxième étape : procédons à la création de la clé de cryptage dans Key Vault pour crypter le Datalake.

• Troisième étape : il faut créer le Datalake et procéder au cryptage de celui-ci avec la clé générée précédemment :



Dans mon cas, j’utilise un template ARM pour créer le Datalake, et dans ce template, les accès Crypt/Decrypt sont affectées dans Key Vault au Datalake :

Ce qui nous donne quelque chose comme cela :

Cela implique que lors d’un nouveau déploiement, Terraform détecte que le Key Vault a été modifié par rapport à son état initial (étape 1) et enlève les droits au Datalake du Key Vault.

Révélation de l’ingrédient secret

Dans l’état actuel de mon Terraform, je ne peux pas ajouter ces accès au Key Vault lors de la création du Key Vault, car si c’est un premier déploiement, le Datalake n’existe pas encore. Comme vous le savez, je ne peux pas créer le Datalake sans la clé de cryptage (l’œuf ou la poule… ).
La solution pour pallier à ce problème est de séparer la création du Key Vault et la gestion des accès à celui-ci en utilisant la ressource azurerm_key_vault_access_policy. Pour pouvoir le faire, on a besoin de connaître l’identifiant Terraform du datalake qui sera créé.

Comme dans mon cas, le déploiement du Datalake est contenu dans un template json (déployé via Terraform), on l’obtient via la fonction output de notre template json :

Ainsi on peut passer cet identifiant pour l’affectation des droits dans Key Vault :

C’est donc de cette manière que Terraform peut tranquillement créer le Key Vault, le Datalake, puis donner les accès sur le Key Vault au Datalake, la recette est sauvée.

Bonne dégustation !