Authentification Azure Container Registry avec des principaux de service

  • Article

Vous pouvez utiliser un principal de service Microsoft Entra pour fournir l’extraction (pull), l’envoi (push) ou un autre accès à votre registre de conteneurs. En utilisant un principal de service, vous pouvez fournir l’accès aux applications et services « sans affichage ».

Qu’est-ce qu’un principal de service ?

Les principaux de service Microsoft Entra ID donnent accès aux ressources Azure dans votre abonnement. Vous pouvez considérer un principal de service comme l’identité d’un utilisateur pour un service, le « service » étant n’importe quelle application, n’importe quel service ou n’importe quelle plateforme qui a besoin d’accéder aux ressources. Vous pouvez configurer un principal de service avec des droits d’accès limités aux ressources que vous spécifiez. Configurez ensuite votre application ou votre service pour qu’il utilise les informations d’identification du principal du service et accède à ces ressources.

Dans le contexte d’Azure Container Registry, vous pouvez créer un principal de service Microsoft Entra avec des autorisations d’extraction (pull), d’envoi (push) et d’extraction (pull), ou d’autres autorisations pour votre registre privé dans Azure. Pour obtenir la liste complète, consultez Autorisations et rôles Azure Container Registry.

Pourquoi utiliser un principal de service ?

En utilisant un principal de service Microsoft Entra, vous pouvez fournir un accès délimité à votre registre de conteneurs privé. Créez différents principaux de service pour chacune de vos applications ou chacun de vos services, en personnalisant les droits d’accès à votre registre. De plus, étant donné que vous pouvez éviter le partage des informations d’identification entre les services et applications, vous pouvez faire tourner les informations d’identification ou révoquer l’accès uniquement pour le principal de service (et donc l’application) de votre choix.

Par exemple, configurez votre application web pour utiliser un principal de service qui lui fournit l’accès pull uniquement, alors que votre système de génération utilise un principal de service qui lui fournit à la fois l’accès push et l’accès pull. Si le développement de votre application est confié à quelqu’un d’autre, vous pouvez modifier les informations d’identification du principal de service sans affecter le système de génération.

Quand utiliser un principal de service

Vous devez utiliser un principal de service pour fournir l’accès au registre dans les scénarios sans affichage. En d’autres termes, cela concerne toutes les applications, tous les services et tous les scripts qui doivent envoyer ou extraire des images conteneur de manière automatisée ou sans assistance. Par exemple :

  • Pull : Déployer des conteneurs d’un registre à des systèmes d’orchestration, y compris Kubernetes, DC/OS et Docker Swarm. Vous pouvez également procéder à des extractions depuis les registres de conteneurs vers des services Azure connexes tels que App Service, Batch, Service Fabric et autres.

    Conseil

    Un principal de service est recommandé dans plusieurs scénarios Kubernetes pour extraire des images à partir d’un registre de conteneurs Azure. Avec Azure Kubernetes Service (AKS), vous pouvez également utiliser un mécanisme automatisé pour vous authentifier auprès d’un registre cible en activant l’identité managée du cluster.

    • Push : Générer des images conteneur et les envoyer (push) à un registre en utilisant des solutions d’intégration et de livraison continues, comme Azure Pipelines ou Jenkins.

Pour un accès individuel à un registre, par exemple quand vous extrayez manuellement une image conteneur vers votre station de travail de développement, nous vous recommandons d’utiliser votre propre identité Microsoft Entra pour accéder au registre (par exemple avec az acr login).

Créer un principal du service

Pour créer un principal de service avec accès à votre registre de conteneurs, exécutez le script suivant dans Azure Cloud Shell ou dans une installation locale de l’interface de ligne de commande Azure CLI. Le script est mis en forme pour l’interpréteur de commandes Bash.

Avant d’exécuter le script, mettez à jour la variable ACR_NAME avec le nom de votre registre de conteneurs. La valeur SERVICE_PRINCIPAL_NAME doit être unique dans votre locataire Microsoft Entra. Si vous recevez une erreur « 'http://acr-service-principal' already exists. », spécifiez un autre nom pour le principal du service.

Vous pouvez éventuellement modifier la valeur --role dans la commande az ad sp create-for-rbac si vous souhaitez accorder des autorisations différentes. Pour obtenir la liste complète des rôles, consultez Autorisations et rôles Azure Container Registry.

Après avoir exécuté le script, notez l’ID et le mot de passe du principal de service. Une fois que vous avez noté les informations d’identification, vous pouvez configurer vos applications et services afin qu’ils s’authentifient auprès de votre registre de conteneurs en tant que principal du service.

#!/bin/bash
# This script requires Azure CLI version 2.25.0 or later. Check version with `az --version`.

# Modify for your environment.
# ACR_NAME: The name of your Azure Container Registry
# SERVICE_PRINCIPAL_NAME: Must be unique within your AD tenant
ACR_NAME=$containerRegistry
SERVICE_PRINCIPAL_NAME=$servicePrincipal

# Obtain the full registry ID
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query "id" --output tsv)
# echo $registryId

# Create the service principal with rights scoped to the registry.
# Default permissions are for docker pull access. Modify the '--role'
# argument value as desired:
# acrpull:     pull only
# acrpush:     push and pull
# owner:       push, pull, and assign roles
PASSWORD=$(az ad sp create-for-rbac --name $SERVICE_PRINCIPAL_NAME --scopes $ACR_REGISTRY_ID --role acrpull --query "password" --output tsv)
USER_NAME=$(az ad sp list --display-name $SERVICE_PRINCIPAL_NAME --query "[].appId" --output tsv)

# Output the service principal's credentials; use these in your services and
# applications to authenticate to the container registry.
echo "Service principal ID: $USER_NAME"
echo "Service principal password: $PASSWORD"

Utiliser un principal de service existant

Pour accorder l’accès au registre à un principal de service existant, vous devez assigner un nouveau rôle au principal de service. Comme pour la création d’un principal du service, vous pouvez notamment accorder un accès en envoi (push), un accès en envoi et tirage (pull), ou un accès propriétaire.

Le script suivant utilise la commande az role assignment create pour accorder des autorisations en extraction à un principal de service que vous spécifiez dans la variable SERVICE_PRINCIPAL_ID. Ajustez la valeur --role si vous souhaitez accorder un niveau d’accès différent.

#!/bin/bash
# Modify for your environment. The ACR_NAME is the name of your Azure Container
# Registry, and the SERVICE_PRINCIPAL_ID is the service principal's 'appId' or
# one of its 'servicePrincipalNames' values.
ACR_NAME=$containerRegistry
SERVICE_PRINCIPAL_ID=$servicePrincipal

# Populate value required for subsequent command args
ACR_REGISTRY_ID=$(az acr show --name $ACR_NAME --query id --output tsv)

# Assign the desired role to the service principal. Modify the '--role' argument
# value as desired:
# acrpull:     pull only
# acrpush:     push and pull
# owner:       push, pull, and assign roles
az role assignment create --assignee $SERVICE_PRINCIPAL_ID --scope $ACR_REGISTRY_ID --role acrpull

Exemples de scripts

Vous trouverez les exemples de scripts précédents pour Azure CLI sur GitHub, ainsi que les versions pour Azure PowerShell :

S’authentifier avec le principal de service

Une fois que vous disposez d’un principal de service auquel vous avez accordé l’accès à votre registre de conteneurs, vous pouvez configurer ses informations d’identification pour accéder aux services et applications sans périphérique de contrôle ou les entrer à l'aide de la commande docker login. Utilisez les valeurs suivantes :

  • Nom d’utilisateur - ID d’application (client)du principal du service
  • Mot de passe - mot de passe du principal de service (clé secrète client)

La valeur Username a le format xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

Conseil

Vous pouvez régénérer le mot de passe (clé secrète client) d’un principal de service en exécutant la commande az ad sp credential reset.

Utiliser les informations d’identification avec les services Azure

Vous pouvez utiliser les informations d’identification du principal de service à partir de n’importe quel service Azure qui s’authentifie auprès d’un registre de conteneurs Azure. Utilisez les informations d’identification du principal de service à la place des informations d’identification d’administrateur du Registre pour un large éventail de scénarios.

Utiliser avec la connexion Docker

Vous pouvez exécuter docker login à l’aide d’un principal de service. Dans l’exemple suivant, l’ID d’application du principal de service est transmis dans la variable d'environnement $SP_APP_ID, et le mot de passe dans la variable $SP_PASSWD. Pour connaître les pratiques recommandées de gestion des informations d’identification Docker, consultez la référence de la commande docker login.

# Log in to Docker with service principal credentials
docker login myregistry.azurecr.io --username $SP_APP_ID --password $SP_PASSWD

Une fois connecté, Docker met en cache les informations d’identification.

Utiliser avec un certificat

Si vous avez ajouté un certificat à votre principal de service, vous pouvez vous connecter à l’interface de ligne de commande Azure à l’aide de l’authentification basée sur un certificat, puis utiliser la commande az acr login pour accéder à un registre. L’utilisation d’un certificat comme clé secrète au lieu d’un mot de passe fournit une sécurité supplémentaire lorsque vous utilisez la CLI.

Un certificat auto-signé peut être créé lorsque vous créez un principal de service. Vous pouvez également ajouter un ou plusieurs certificats à un principal de service existant. Par exemple, si vous utilisez l’un des scripts de cet article pour créer ou mettre à jour un principal de service ayant des droits d’extraction ou de transmission d’images à partir d’un registre, ajoutez un certificat à l’aide de la commande az ad sp credential reset.

Pour utiliser le principal de service avec un certificat pour se connecter à Azure CLI, le certificat doit être au format PEM et inclure la clé privée. Si votre certificat n’est pas au format requis, utilisez un outil tel que openssl pour le convertir. Lorsque vous exécutez az login pour vous connecter à l’interface CLI à l’aide du principal de service, fournissez également l’ID d’application du principal de service et l’ID de locataire Active Directory. L’exemple suivant illustre ces valeurs en tant que variables d’environnement :

az login --service-principal --username $SP_APP_ID --tenant $SP_TENANT_ID  --password /path/to/cert/pem/file

Ensuite, exécutez az acr login pour vous authentifier auprès du registre :

az acr login --name myregistry

L’interface CLI utilise le jeton créé lorsque vous avez exécuté az login pour authentifier votre session auprès du registre.

Création d’un principal de service dans les scénarios inter-locataires

Un principal de service peut également être utilisé dans les scénarios Azure qui impliquent d’extraire des images d’un registre de conteneurs situé dans une instance Microsoft Entra ID (locataire) vers un service ou une application situé dans une autre. Supposons qu’une organisation exécute une application dans le locataire A qui doit extraire une image d’un registre de conteneurs partagé dans le locataire B.

Pour créer un principal de service capable de s’authentifier auprès d’un registre de conteneurs dans un scénario inter-locataire, elle doit procéder comme suit :

  • Créer une application multi-locataire (principal de service) dans le locataire A
  • Provisionner l’application dans le locataire B
  • Autoriser le principal de service à effectuer des extractions à partir du registre dans le locataire B
  • Mettre à jour le service ou l’application dans le locataire A pour que l’authentification s’effectue avec le nouveau principal de service

Pour voir un exemple de cette procédure, consultez Extraction d’images d’un registre de conteneurs Azure vers un cluster AKS situé dans un autre locataire AD.

Renouvellement du principal de service

Le principal de service est créé avec une validité d’un an. Vous avez la possibilité de prolonger la validité au-delà d’un an ou de fournir la date d’expiration de votre choix à l’aide de la commande az ad sp credential reset.

Étapes suivantes