S’authentifier auprès de ressources Azure au moyen de serveurs avec Azure Arc
Les applications ou les processus qui s’exécutent directement sur des serveurs avec Azure Arc peuvent utiliser des identités managées pour accéder à d’autres ressources Azure qui prennent en charge l’authentification basée sur Microsoft Entra ID. Une application peut obtenir un jeton d’accès représentant son identité, qui est affectée par le système pour les serveurs Azure Arc, et l’utiliser en tant que jeton de « porteur » pour s’authentifier auprès d’un autre service.
Reportez-vous à la documentation de présentation des identités managées pour obtenir une description détaillée des identités managées et comprendre la distinction entre les identités affectées par le système et celles affectées par l’utilisateur.
Dans cet article, nous vous montrons comment un serveur peut utiliser une identité managée affectée par le système pour accéder à Azure Key Vault. Servant de bootstrap, Key Vault permet à votre application client d'utiliser ensuite un secret pour accéder aux ressources non sécurisées par Microsoft Entra ID. Par exemple, les certificats TLS/SSL utilisés par vos serveurs web IIS peuvent être stockés dans Azure Key Vault et être déployés de façon sécurisée sur des serveurs Windows ou Linux en dehors d’Azure.
Présentation de la sécurité
Lors de l’intégration de votre serveur à des serveurs avec Azure Arc, plusieurs actions sont effectuées pour configurer l’utilisation d’une identité managée, à l’instar de ce qui est effectué pour une machine virtuelle Azure :
Azure Resource Manager reçoit une demande d’activation de l’identité managée affectée par le système sur le serveur Azure Arc.
Azure Resource Manager crée un principal de service dans Microsoft Entra ID pour l’identité du serveur. Le principal de service est créé dans le locataire Microsoft Entra approuvé par cet abonnement.
Azure Resource Manager configure l’identité sur le serveur en mettant à jour le point de terminaison d’identité Azure Instance Metadata Service (IMDS) pour Windows ou Linux avec l’ID client et le certificat du principal de service. Le point de terminaison est un point de terminaison REST accessible uniquement à partir du serveur à l’aide d’une adresse IP non routable connue. Ce service fournit un sous-ensemble d’informations de métadonnées sur le serveur Azure Arc pour faciliter sa gestion et sa configuration.
L’environnement d’un serveur avec identité managée est configuré avec les variables suivantes sur un serveur Azure Arc Windows :
IMDS_ENDPOINT : adresse IP
http://localhost:40342
du point de terminaison IMDS pour les serveurs Azure Arc.IDENTITY_ENDPOINT : point de terminaison localhost correspondant à l’identité managée
http://localhost:40342/metadata/identity/oauth2/token
du service.
Le code exécuté sur le serveur peut demander un jeton au point de terminaison d’Azure Instance Metadata Service, qui est accessible uniquement à partir du serveur.
La variable d’environnement système IDENTITY_ENDPOINT permet la découverte du point de terminaison d’identité par les applications. Les applications doivent essayer de récupérer les valeurs IDENTITY_ENDPOINT et IMDS_ENDPOINT et les utiliser. Les applications avec n’importe quel niveau d’accès sont autorisées à effectuer des demandes aux points de terminaison. Les réponses de métadonnées sont gérées normalement et accordées à n’importe quel processus sur la machine. Toutefois, quand une demande effectuée est susceptible d’exposer un jeton, nous exigeons que le client fournisse un secret pour attester qu’il est en mesure d’accéder aux données uniquement disponibles pour les utilisateurs disposant de privilèges plus élevés.
Prérequis
Compréhension des identités managées.
Sur Windows, vous devez être membre du groupe local Administrateurs ou du groupe Applications d’extension de l’agent hybride.
Sur Linux, vous devez être membre du groupe himds.
Un serveur connecté et inscrit auprès des serveurs Azure Arc.
Vous êtes membre du groupe Propriétaire dans l’abonnement ou le groupe de ressources afin d’effectuer les étapes requises de création de ressources et de gestion des rôles.
Un coffre de clés Azure pour stocker et récupérer vos informations d’identification et attribuer à l’identité Azure Arc l’accès au coffre de clés.
- Si vous n’avez pas de coffre de clés créé, consultez Créer un coffre de clés.
- Pour configurer l’accès par l’identité managée utilisée par le serveur, consultez Accorder l’accès pour Linux ou Accorder l’accès pour Windows. Pour l’étape 5, vous allez entrer le nom du serveur Azure Arc. Pour effectuer cette opération à l’aide de PowerShell, consultez Attribuer une stratégie d’accès à l’aide de PowerShell.
Acquisition d’un jeton d’accès à l’aide de l’API REST
La méthode permettant d’obtenir et d’utiliser une identité managée affectée par le système pour s’authentifier auprès de ressources Azure est similaire à celle suivie avec une machine virtuelle Azure.
Pour un serveur Windows Azure Arc, à l’aide de PowerShell, vous appelez la requête web afin d’obtenir le jeton de l’hôte local dans le port spécifique. Spécifiez la requête à l’aide de l’adresse IP ou de la variable d’environnement IDENTITY_ENDPOINT.
$apiVersion = "2020-06-01"
$resource = "https://management.azure.com/"
$endpoint = "{0}?resource={1}&api-version={2}" -f $env:IDENTITY_ENDPOINT,$resource,$apiVersion
$secretFile = ""
try
{
Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{Metadata='True'} -UseBasicParsing
}
catch
{
$wwwAuthHeader = $_.Exception.Response.Headers["WWW-Authenticate"]
if ($wwwAuthHeader -match "Basic realm=.+")
{
$secretFile = ($wwwAuthHeader -split "Basic realm=")[1]
}
}
Write-Host "Secret file path: " $secretFile`n
$secret = cat -Raw $secretFile
$response = Invoke-WebRequest -Method GET -Uri $endpoint -Headers @{Metadata='True'; Authorization="Basic $secret"} -UseBasicParsing
if ($response)
{
$token = (ConvertFrom-Json -InputObject $response.Content).access_token
Write-Host "Access token: " $token
}
La réponse suivante est un exemple qui est retourné :
Pour un serveur Linux Azure Arc, à l’aide de Bash, vous appelez la requête web afin d’obtenir le jeton de l’hôte local dans le port spécifique. Spécifiez la requête suivante à l’aide de l’adresse IP ou de la variable d’environnement IDENTITY_ENDPOINT. Pour effectuer cette étape, vous avez besoin d’un client SSH.
CHALLENGE_TOKEN_PATH=$(curl -s -D - -H Metadata:true "http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https%3A%2F%2Fmanagement.azure.com" | grep Www-Authenticate | cut -d "=" -f 2 | tr -d "[:cntrl:]")
CHALLENGE_TOKEN=$(cat $CHALLENGE_TOKEN_PATH)
if [ $? -ne 0 ]; then
echo "Could not retrieve challenge token, double check that this command is run with root privileges."
else
curl -s -H Metadata:true -H "Authorization: Basic $CHALLENGE_TOKEN" "http://127.0.0.1:40342/metadata/identity/oauth2/token?api-version=2019-11-01&resource=https%3A%2F%2Fmanagement.azure.com"
fi
La réponse suivante est un exemple qui est retourné :
La réponse inclut le jeton d’accès dont vous avez besoin pour accéder à une ressource dans Azure. Pour effectuer la configuration de l’authentification auprès d’Azure Key Vault, consultez Accéder à Key Vault avec Windows ou Accéder à Key Vault avec Linux.
Étapes suivantes
Pour en découvrir plus sur Azure Key Vault, consultez Vue d’ensemble de Key Vault.
Découvrez comment affecter à une identité managée l’accès à une ressource Azure à l’aide de PowerShell ou d’Azure CLI.