Partager via

Créer un principal de service Azure avec Azure CLI

Les outils automatisés qui utilisent des services Azure doivent toujours disposer d’autorisations restreintes pour s’assurer que les ressources Azure sont sécurisées. Par conséquent, au lieu d’avoir des applications se connecter en tant qu’utilisateur entièrement privilégié, Azure offre des principals de service. Un principal de service Azure est une identité créée pour une utilisation avec des applications, des services hébergés et des outils automatisés. Cette identité est utilisée pour accéder aux ressources.

Dans ce tutoriel, vous allez apprendre à :

  • Créer un principal de service
  • Se connecter à l’aide d’un principal de service et d’un mot de passe
  • Se connecter à l’aide d’un principal de service et d’un certificat
  • Gérer les rôles du principal du service
  • Créer une ressource Azure à l’aide d’un principal de service
  • Réinitialiser les identifiants du principal de service

Conditions préalables

  • Dans le cadre d'un abonnement, vous devez disposer des autorisations User Access Administrator ou Role Based Access Control Administrator, ou de niveau supérieur, pour créer un principal du service. Pour obtenir la liste des rôles disponibles pour le contrôle d’accès en fonction du rôle Azure (Azure RBAC), consultez les rôles intégrés Azure.

Créer un principal de service

Utilisez la commande de référence azure CLI az ad sp create-for-rbac pour créer un principal de service. Cet exemple ne spécifie pas de --name paramètre. Par conséquent, un nom contenant un horodatage est automatiquement créé.

az ad sp create-for-rbac

Console de sortie :

{
  "appId": "myAppId",
  "displayName": "myServicePrincipalName",
  "password": "myServicePrincipalPassword",
  "tenant": "myTentantId"
}

Si vous ne respectez pas les conventions d’affectation de noms de ressources et prévoyez de créer un rôle et une étendue pour votre nouveau principal de service ultérieurement, la az ad sp create-for-rbac commande sans paramètres est une solution acceptable. Toutefois, sans rôle et périmètre, la nouvelle entité de service n’a pas accès aux ressources. Il existe simplement.

Lorsque vous créez un principal de service sans paramètres, effectuez également les étapes suivantes :

Remarque

Si votre compte n’a pas l’autorisation de créer un principal de service, az ad sp create-for-rbac retourne un message d’erreur contenant « Privilèges insuffisants pour effectuer l’opération ». Contactez votre administrateur Microsoft Entra pour créer un principal de service.

Dans un répertoire d’ID Microsoft Entra dans lequel les paramètres de Inscription des applications par les utilisateurs est défini sur Non, vous devez être membre de l’un des rôles intégrés Microsoft Entra ID suivants (qui ont l’action : microsoft.directory/applications/createAsOwner ou microsoft.directory/applications/create) :

Pour plus d’informations sur les paramètres utilisateur dans Microsoft Entra ID, consultez Restreindre les utilisateurs qui peuvent créer des applications.

Créer un principal de service avec un rôle et une étendue

En guise de meilleure pratique, attribuez toujours un principal de service spécifique --role et --scopes lorsque vous créez un principal de service. Suivez ces étapes :

  1. Déterminez le rôle approprié.

    Lors de la détermination du rôle, utilisez toujours le principe du privilège minimum. Par exemple, ne donnez pas à votre principal contributor de service des autorisations à un abonnement si le principal de service doit uniquement accéder au stockage Azure au sein d’un groupe de ressources. Considérez un rôle spécialisé comme contributeur aux données blob de stockage. Pour obtenir la liste complète des rôles disponibles dans Azure RBAC, consultez Rôles intégrés Azure.

  2. Obtenez une valeur pour le paramètre de portée.

    Recherchez et copiez l’ID de ressource de la ressource Azure dont le nouveau principal de service doit accéder. Ces informations se trouvent généralement dans la page Propriétés ou Points de terminaison du portail Azure de chaque ressource. Voici des exemples --scopes courants, mais comptez sur votre ID de ressource pour un format et une valeur réels.

    Étendue Exemple :
    Abonnement /subscriptions/mySubscriptionID
    groupe de ressources /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName
    Machine virtuelle /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.Compute/virtualMachines/myVMname
    Service de fichiers du compte de stockage /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.Storage/storageAccounts/myStorageAccountName/fileServices/default
    Fabrique de données /subscriptions/mySubscriptionID/resourceGroups/myResourceGroupName/providers/Microsoft.DataFactory/factories/myDataFactoryName

    Pour plus d’exemples de portée, consultez Comprendre la portée d’Azure RBAC.

  3. Créez le principal de service.

    Dans cet exemple, un nouveau principal de service nommé myServicePrincipalName1 est créé avec des autorisations de lecteur pour toutes les ressources du groupe de ressources RG1.

    # Bash script
az ad sp create-for-rbac --name myServicePrincipalName1 \
                         --role reader \
                         --scopes /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG1

    Le --scopes paramètre accepte une liste de périmètres séparée par des espaces. Dans cet exemple, un nouveau principal de service nommé myServicePrincipalName2 est créé avec des autorisations de lecteur pour toutes les ressources du groupe de ressources myRG1. Ce principal de service reçoit également des autorisations de lecteur pour myVM situé dans myRG2.

    # Bash script
az ad sp create-for-rbac --name myServicePrincipalName2 \
                         --role reader \
                         --scopes /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG1 /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myRG2/providers/Microsoft.Compute/virtualMachines/myVM

Si vous décidez que vous avez accordé trop peu ou trop d’autorisations à votre nouveau principal de service, modifiez les autorisations en gérant les rôles de principal de service.

Créer un principal de service à l’aide de variables

Vous pouvez également créer un principal de service à l’aide de variables :

# Bash script
let "randomIdentifier=$RANDOM*$RANDOM"
servicePrincipalName="msdocs-sp-$randomIdentifier"
roleName="azureRoleName"
subscriptionID=$(az account show --query id --output tsv)
# Verify the ID of the active subscription
echo "Using subscription ID $subscriptionID"
resourceGroup="myResourceGroupName"

echo "Creating SP for RBAC with name $servicePrincipalName, with role $roleName and in scopes /subscriptions/$subscriptionID/resourceGroups/$resourceGroup"
az ad sp create-for-rbac --name $servicePrincipalName \
                         --role $roleName \
                         --scopes /subscriptions/$subscriptionID/resourceGroups/$resourceGroup

Pour obtenir la liste complète des propriétés du principal de service, utilisez az ad sp list et consultez Obtenir un principal de service existant.

Avertissement

Lorsque vous créez un principal de service Azure à l’aide de la commande, la az ad sp create-for-rbac sortie inclut des informations d’identification que vous devez protéger. Veillez à ne pas inclure ces informations d’identification dans votre code ou vérifiez les informations d’identification dans votre contrôle de code source. En guise d’alternative, envisagez d’utiliser identités managées si disponible pour éviter d’avoir à utiliser des informations d’identification.

Étapes suivantes

Maintenant que vous avez appris à créer un principal de service Azure, passez à l’étape suivante pour apprendre à utiliser des principaux de service avec l’authentification par mot de passe.

Utiliser l’authentification par mot de passe