Hello, je travaille actuellement sur l’intégration d’un cloud provider non nativement compatible avec Azure DevOps pour utiliser Terraform/Ansible. Dans ce cadre, je vais vous présenter une des solutions que j’ai utilisée pour sécuriser les credentials d’accès.
Attention, cet article / tuto a été réalisé rapidement par conséquent le niveau de vulgarisation technique est assez faible. Par conséquent, pour bien tout comprendre, il est nécessaire d’avoir en tête le jargon Azure DevOps (ADO pour les intimes). La compréhension des termes suivants et leurs fonctionnements sont des prérequis : “Service Connection” (SC dans l’article), task groupe, agent self hosted ADO, pipeline ADO et Release ADO.
Quand on travail sur l’intégration d’un nouveau cloud provider ou d’un outil non nativement intégrer à la plateforme ADO tous est à réaliser manuellement. La première des difficultés concerne le chiffrement des credentials d’accès (ex cloud, supervision, gates, ansible tower etc..). Pour les services supportés, des “service connection” sont disponibles, mais pas dans notre cas…
Plusieurs solutions sont possibles :
- Mettre en dur les credentials en variable dans le pipeline / release,
- Utiliser une variable group réutilisée sur les ressources présentes dans le même “projet” qui en ont besoin (ex compte générique)
- La méthode que je propose.
En effet, les deux premières solutions sont possible mais pas idéal au niveau de la gestion des droits (ex partage) entre plusieurs “projet” (attention je parle du découpage organisationnel d’ADO) azure devops. Pour ce faire, on va d’appuyer sur le fait que Microsoft a pensé aux développeurs d’extensions pour leurs plateformes Azure DevOps. Ils ont mis en place un “SC” générique réutilisable via une tasks développée, soit même:
N’ayant pas le temps / la compétence pour faire un pull request pour mettre à jours les tasks que j’ai besoin (ex terraform). Je me suis appuyé vers le travail de Alexander Chermyanin. Il a réalisé une extension ADO accessible sur le marketplace Azure DevOps qui permet de récupérer les informations du “SC” génériques avec une tasks dédiée dans un pipeline / release. Pour les paranos vous pouvez builder votre propre task via le code source et l’ajouter via votre compte marketplace perso.
L’utilisation de cette tasks est aussi simple qu’efficace:
1) Installer le plugin depuis le MarketPlace au niveau de votre Organisation :
2) Ajouter un “SC” générique avec les informations à sauvegarder
Dans notre contexte, nous configurons l’access key id et l’access key password de notre compte de service Alibaba :
3) Ajouter la task installée par l’extension installée depuis le marketplace dans votre pipeline / release :
Pour vérifier que les informations sont bien récupérées, vous pouvez ajouter une task pour afficher les informations dans les logs (attention echo -> utiliser un agent linux).
Si on lance la release et on regarde les logs, on voit cela :
On remarque que la récupération de la variable “password” via sa variable d’environnement ne fonctionne pas, il s’agit surement d’une sécurité.
Cependant, pour des besoins spécifiques vous pouvez toujours setter en variable d’environnement le password de la SC via une commande spécifique. Cependant, si vous n’avez pas le choix du nom de la variable d’environnement (ex provider/backend terraform), il va falloir ruser.
En effet, la task de récupération va totalement bloquer au niveau des variables d’environnement le nom de variable choisi pour le password “MON_PASSWORD” (dans notre exemple). Par conséquent, il faut utiliser un nom de variable différent au niveau de la task de récupération de SC (ex “MON_PASSWORD_TMP”) et celle qui est utilisée en variable d’environnement.
Ci-dessous, vous pouvez voir une task bash (utilisation d’un agent Linux) avec une commande qui permet de définir une variable d’environnement au niveau de l’agent. Cette technique permet de réutiliser ces variables entre toutes les tasks de la même build / release.
La commande à utiliser :
echo "##vso[task.setvariable variable=MON_PASSWORD]$(MON_PASSWORD_TMP)"
Attention à ne pas oublier de changer le nom de la variable de la task Generic de “MON_PASSWORD” à “MON_PASSWORD_TMP” pour que ça fonctionne.
Vous pouvez vérifier le bon fonctionnement de ce process en déplacent la tasks de test après celle de définition de la variable d’environnement et relancer la release définition.
En espérant que cet article vous a été utile, je vous souhaite un bonne journée,
Yoann Fouillet
