Comprendre l'accès à Azure avec Terraform via Azure DevOps
Imagine ceci :
- Azure = une grande résidence avec plein de maisons (VM, KeyVault, etc.).
- Subscription = ton contrat de location pour une maison.
- Tenant = l'agence qui gère tous les contrats (l'entreprise Azure).
- Terraform = un ouvrier qui veut construire ou modifier une maison.
Mais pour entrer, Terraform a besoin d'une autorisation.
1. Service Principal (SPN)
C'est comme donner une clé spéciale à un artisan externe.
- Tu crées une clé (client_id + secret).
- Azure reconnaît cette clé et autorise l'accès à certaines ressources.
- Utilisé pour connecter Terraform à Azure depuis Azure DevOps.
Avantages :
- Fonctionne même en dehors d'Azure.
Inconvénients :
- Moins sécurisé : tu dois gérer les secrets.
2. Managed Identity (Identité managée)
C'est comme un badge automatique pour un résident de la résidence.
- Azure donne automatiquement une identité à certaines ressources (VM, agent, etc.).
- Pas besoin de secret ou de clé.
- Terraform s'exécute via cette identité et Azure vérifie les droits (RBAC).
Avantages :
- Très sécurisé, pas de secret.
Inconvénients :
- Marche uniquement avec des ressources Azure (agent self-hosted par ex.).
3. Dans Azure DevOps :
- Si tu utilises un SPN, tu enregistres ses infos dans une Service Connection.
- Si tu utilises une Managed Identity, tu relies l'agent Azure à une identité managée avec des rôles
RBAC.
Résumé :
- Tenant = agence immobilière
- Subscription = contrat de location
- Service Principal = artisan externe avec clé
- Managed Identity = badge automatique résident
- RBAC = les droits d'accès aux maisons (ressources)