Identité et Entra ID

Dans Azure, tout commence par l'identité. Avant de déployer une VM ou de créer un storage account, tu dois savoir qui peut faire quoi. Microsoft Entra ID est le pilier central de cette gestion des identités dans le cloud Microsoft.

1. Microsoft Entra ID : l'annuaire cloud

Microsoft Entra ID (anciennement Azure Active Directory / Azure AD) est le service d'annuaire et de gestion des identités cloud de Microsoft. Il permet de gérer les utilisateurs, les groupes, les applications et les accès à l'ensemble des services Azure — mais aussi aux applications SaaS comme Microsoft 365, GitHub ou Salesforce.

Ce qu'Entra ID gère

• Utilisateurs — comptes humains avec email, mot de passe, MFA
• Groupes — regroupements d'utilisateurs pour simplifier les attributions
• Applications — inscriptions d'apps qui s'authentifient via Entra ID
• Appareils — enregistrement et conformité des postes de travail
• Identités externes — invités B2B et clients B2C

2. Tenants et abonnements

Deux concepts sont fondamentaux pour comprendre la structure d'Azure :

Le tenant (locataire)

Un tenant Entra ID est une instance dédiée d'Entra ID, associée à une organisation. Quand tu crées un compte Microsoft ou Microsoft 365, un tenant est automatiquement créé pour toi. Chaque tenant possède un domaine par défaut en .onmicrosoft.com.

Le tenant est le conteneur des identités : utilisateurs, groupes et applications y sont stockés.

L'abonnement (subscription)

Un abonnement Azure est le conteneur des ressources (VMs, bases de données, réseaux…). C'est à ce niveau que la facturation est calculée. Un tenant peut être associé à plusieurs abonnements, mais un abonnement ne peut être associé qu'à un seul tenant.

3. RBAC Azure : contrôle d'accès basé sur les rôles

Le Role-Based Access Control (RBAC) est le mécanisme par lequel Azure détermine ce qu'un utilisateur ou une application est autorisé à faire sur les ressources. Le principe est simple : on attribue un rôle à un principal de sécurité sur un scope.

Les rôles intégrés principaux

• Owner — accès complet à toutes les ressources, peut déléguer l'accès à d'autres
• Contributor — peut créer et gérer toutes les ressources, mais ne peut pas gérer les accès
• Reader — peut consulter les ressources existantes, sans aucune modification possible
• User Access Administrator — peut gérer les accès utilisateurs aux ressources Azure

Il existe des dizaines de rôles spécialisés (ex. Storage Blob Data Reader, Key Vault Secrets User…) pour appliquer le principe du moindre privilège.

Les scopes d'attribution

Un rôle s'attribue toujours à un niveau précis de la hiérarchie Azure. L'attribution hérite vers le bas :

• Groupe d'administration — s'applique à tous les abonnements enfants
• Abonnement — s'applique à tous les groupes de ressources et ressources de l'abonnement
• Groupe de ressources — s'applique à toutes les ressources du groupe
• Ressource — s'applique uniquement à cette ressource spécifique

Attribuer un rôle via Azure CLI

# Attribuer le rôle Reader à un utilisateur sur un groupe de ressources
az role assignment create \
  --assignee "utilisateur@exemple.com" \
  --role "Reader" \
  --resource-group "mon-rg"

# Lister les attributions de rôles sur un groupe de ressources
az role assignment list \
  --resource-group "mon-rg" \
  --output table

4. Service Principals : identité applicative

Lorsqu'une application, un script ou un outil d'automatisation (comme Terraform, GitHub Actions ou Azure DevOps) doit accéder à des ressources Azure, il ne peut pas utiliser un compte utilisateur humain. C'est là qu'intervient le Service Principal.

Un service principal est la représentation locale, dans un tenant, d'une application inscrite dans Entra ID. C'est l'identité applicative : elle possède un identifiant unique, peut se voir attribuer des rôles RBAC, et s'authentifie via un secret (password) ou un certificat.

Créer un service principal et lui attribuer un rôle

# Créer un service principal avec le rôle Contributor sur l'abonnement courant
az ad sp create-for-rbac \
  --name "mon-sp-terraform" \
  --role "Contributor" \
  --scopes "/subscriptions/SUBSCRIPTION_ID"

# La commande retourne :
# {
#   "appId": "...",       <- CLIENT_ID
#   "displayName": "mon-sp-terraform",
#   "password": "...",    <- CLIENT_SECRET (à stocker de façon sécurisée !)
#   "tenant": "..."       <- TENANT_ID
# }

# Récupérer l'ID de l'abonnement courant
az account show --query id --output tsv

# Lister les service principals existants
az ad sp list --display-name "mon-sp" --output table

# Supprimer un service principal
az ad sp delete --id "APP_ID"

Les credentials du service principal (appId + password + tenantId) sont ensuite utilisés comme variables d'environnement par les outils d'automatisation :

# Variables utilisées par Terraform pour s'authentifier à Azure
export ARM_CLIENT_ID="appId"
export ARM_CLIENT_SECRET="password"
export ARM_TENANT_ID="tenant"
export ARM_SUBSCRIPTION_ID="subscriptionId"

5. Managed Identities : plus de secrets à gérer

La Managed Identity (identité managée) est la solution recommandée dès qu'un service Azure doit s'authentifier auprès d'un autre service Azure. Contrairement aux service principals, il n'y a aucun secret à créer, stocker ou faire tourner — Azure gère tout automatiquement.

Deux types de managed identities

• System-assigned — liée au cycle de vie de la ressource. Si tu supprimes la VM, l'identité est supprimée avec elle. Une ressource = une identité.
• User-assigned — créée indépendamment, peut être attachée à plusieurs ressources. Utile pour partager une identité entre plusieurs services (ex. plusieurs Function Apps qui accèdent au même Key Vault).

Activer une managed identity sur une VM

# Activer la system-assigned managed identity sur une VM existante
az vm identity assign \
  --name "ma-vm" \
  --resource-group "mon-rg"

# Créer une user-assigned managed identity
az identity create \
  --name "mon-identite-partagee" \
  --resource-group "mon-rg"

# Attacher une user-assigned identity à une VM
az vm identity assign \
  --name "ma-vm" \
  --resource-group "mon-rg" \
  --identities "mon-identite-partagee"

Attribuer un rôle à une managed identity

# Récupérer le principal ID de la managed identity de la VM
PRINCIPAL_ID=$(az vm show \
  --name "ma-vm" \
  --resource-group "mon-rg" \
  --query "identity.principalId" \
  --output tsv)

# Attribuer le rôle Storage Blob Data Reader
az role assignment create \
  --assignee "$PRINCIPAL_ID" \
  --role "Storage Blob Data Reader" \
  --scope "/subscriptions/SUBSCRIPTION_ID/resourceGroups/mon-rg/providers/Microsoft.Storage/storageAccounts/monstorageaccount"

Une fois le rôle attribué, le code tournant sur la VM peut obtenir un token d'accès sans aucun secret, via l'IMDS (Instance Metadata Service) — un endpoint interne disponible uniquement depuis la VM.

6. Principle of Least Privilege

Le principe du moindre privilège est la règle d'or de la sécurité des identités : n'accorder que les permissions strictement nécessaires, sur le scope le plus restreint possible, pour la durée la plus courte possible.

• Préfère un rôle spécialisé (Storage Blob Data Contributor) à Contributor ou Owner
• Attribue les rôles au niveau ressource ou groupe de ressources, pas sur tout l'abonnement
• Utilise des managed identities plutôt que des service principals avec des secrets quand c'est possible
• Audite régulièrement les attributions de rôles avec az role assignment list
• Évite de donner le rôle Owner à des comptes de service ou des identités applicatives

7. Workflow complet : service principal pour Terraform

Voici le workflow typique pour configurer un service principal utilisé par Terraform en CI/CD :

# 1. Se connecter et sélectionner l'abonnement cible
az login
az account set --subscription "SUBSCRIPTION_ID"

# 2. Créer le service principal avec droits Contributor
az ad sp create-for-rbac \
  --name "sp-terraform-prod" \
  --role "Contributor" \
  --scopes "/subscriptions/SUBSCRIPTION_ID" \
  --output json

# 3. Stocker les credentials dans des secrets GitHub/GitLab/Azure DevOps
# NE JAMAIS les committer dans le code source !

# 4. Vérifier les attributions de rôles du service principal
SP_OBJECT_ID=$(az ad sp show --id "APP_ID" --query id --output tsv)
az role assignment list --assignee "$SP_OBJECT_ID" --output table

# 5. Restreindre au minimum nécessaire si Contributor est trop large
az role assignment delete \
  --assignee "APP_ID" \
  --role "Contributor" \
  --scope "/subscriptions/SUBSCRIPTION_ID"

az role assignment create \
  --assignee "APP_ID" \
  --role "Contributor" \
  --resource-group "rg-prod-terraform"