Dela via


Ansluta från ditt program till resurser utan att hantera autentiseringsuppgifter

Azure-resurser med stöd för hanterade identiteter ger alltid ett alternativ för att ange en hanterad identitet för att ansluta till Azure-resurser som stöder Microsoft Entra-autentisering. Stöd för hanterade identiteter gör det onödigt för utvecklare att hantera autentiseringsuppgifter i kod. Hanterade identiteter är det rekommenderade autentiseringsalternativet när du arbetar med Azure-resurser som stöder dem. Läs en översikt över hanterade identiteter.

Den här sidan visar hur du konfigurerar en App Service så att den kan ansluta till Azure Key Vault, Azure Storage och Microsoft SQL Server. Samma principer kan användas för alla Azure-resurser som stöder hanterade identiteter och som ansluter till resurser som stöder Microsoft Entra-autentisering.

Kodexemplen använder Azure Identity-klientbiblioteket, vilket är den rekommenderade metoden eftersom det automatiskt hanterar många av stegen åt dig, inklusive att hämta en åtkomsttoken som används i anslutningen.

Vilka resurser kan hanterade identiteter ansluta till?

En hanterad identitet kan ansluta till alla resurser som stöder Microsoft Entra-autentisering. I allmänhet krävs inget särskilt stöd för resursen för att tillåta att hanterade identiteter ansluter till den.

Vissa resurser stöder inte Microsoft Entra-autentisering, eller så har deras klientbibliotek inte stöd för autentisering med en token. Fortsätt läsa för att se vår vägledning om hur du använder en hanterad identitet för att på ett säkert sätt komma åt autentiseringsuppgifterna utan att behöva lagra dem i din kod- eller programkonfiguration.

Skapa en hanterad identitet

Det finns två typer av hanterade identiteter: systemtilldelade och användartilldelade. Systemtilldelade identiteter är direkt länkade till en enda Azure-resurs. När Azure-resursen tas bort, så är även identiteten. En användartilldelad hanterad identitet kan associeras med flera Azure-resurser och dess livscykel är oberoende av dessa resurser.

Vi rekommenderar att du använder en användartilldelad hanterad identitet i de flesta scenarier. Om källresursen som du använder inte stöder användartilldelade hanterade identiteter bör du läsa den resursproviderns dokumentation för att lära dig hur du konfigurerar den så att den har en systemtilldelad hanterad identitet.

Viktigt!

Kontot som används för att skapa hanterade identiteter behöver en roll som "Hanterad identitetsdeltagare" för att skapa en ny användartilldelad hanterad identitet.

Skapa en användartilldelad hanterad identitet med det alternativ du föredrar:

När du har skapat en användartilldelad hanterad identitet bör du anteckna värdena clientId principalId och som returneras när den hanterade identiteten skapas. Du använder principalId när du lägger till behörigheter och clientId i programmets kod.

Konfigurera App Service med en användartilldelad hanterad identitet

Innan du kan använda den hanterade identiteten i koden måste vi tilldela den till den App Service som ska använda den. Processen för att konfigurera en App Service för att använda en användartilldelad hanterad identitet kräver att du anger den hanterade identitetens resursidentifierare i appkonfigurationen.

Lägga till behörigheter till identiteten

När du har konfigurerat Din App Service att använda en användartilldelad hanterad identitet beviljar du identiteten nödvändiga behörigheter. I det här scenariot använder vi den här identiteten för att interagera med Azure Storage, så du måste använda RBAC-systemet (Azure Role Based Access Control) för att bevilja resursen användartilldelade hanterade identitetsbehörigheter.

Viktigt!

Du behöver en roll som "Administratör för användaråtkomst" eller "Ägare" för målresursen för att lägga till rolltilldelningar. Se till att du beviljar den lägsta behörighet som krävs för att programmet ska kunna köras.

Alla resurser som du vill komma åt kräver att du beviljar identitetsbehörigheter. Om du till exempel begär en token för att få åtkomst till Key Vault måste du också lägga till en åtkomstprincip som innehåller appens eller funktionens hanterade identitet. Annars avvisas dina anrop till Key Vault, även om du använder en giltig token. Detsamma gäller för Azure SQL Database. Mer information om vilka resurser som stöder Microsoft Entra-token finns i Azure-tjänster som stöder Microsoft Entra-autentisering.

Använda hanterade identiteter i koden

När du har slutfört stegen ovan har Din App Service en hanterad identitet med behörighet till en Azure-resurs. Du kan använda den hanterade identiteten för att hämta en åtkomsttoken som din kod kan använda för att interagera med Azure-resurser, i stället för att lagra autentiseringsuppgifter i koden.

Vi rekommenderar att du använder Azure Identity-biblioteket för önskat programmeringsspråk. Biblioteket hämtar åtkomsttoken åt dig, vilket gör det enkelt att ansluta till målresurser.

Läs mer om Azure Identity-biblioteken nedan:

Använda Azure Identity-biblioteket i utvecklingsmiljön

Azure Identity-biblioteken anger var och en en DefaultAzureCredential typ. DefaultAzureCredential försöker automatiskt autentisera via flera mekanismer, inklusive miljövariabler eller en interaktiv inloggning. Autentiseringstypen kan användas i utvecklingsmiljön med dina egna autentiseringsuppgifter. Den kan också användas i din Azure-produktionsmiljö med hjälp av en hanterad identitet. Inga kodändringar krävs när du distribuerar ditt program.

Om du använder användartilldelade hanterade identiteter bör du också uttryckligen ange den användartilldelade hanterade identitet som du vill autentisera med genom att skicka in identitetens klient-ID som en parameter. Du kan hämta klient-ID:t genom att bläddra till identiteten i Azure Portal.

Åtkomst till en blob i Azure Storage

using Azure.Identity;
using Azure.Storage.Blobs;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);                        

var blobServiceClient1 = new BlobServiceClient(new Uri("<URI of Storage account>"), credential);
BlobContainerClient containerClient1 = blobServiceClient1.GetBlobContainerClient("<name of blob>");
BlobClient blobClient1 = containerClient1.GetBlobClient("<name of file>");

if (blobClient1.Exists())
{
    var downloadedBlob = blobClient1.Download();
    string blobContents = downloadedBlob.Value.Content.ToString();                
}

Komma åt en hemlighet som lagras i Azure Key Vault

using Azure.Identity;
using Azure.Security.KeyVault.Secrets;
using Azure.Core;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};
var credential = new DefaultAzureCredential(credentialOptions);        

var client = new SecretClient(
    new Uri("https://<your-unique-key-vault-name>.vault.azure.net/"),
    credential);
    
KeyVaultSecret secret = client.GetSecret("<my secret>");
string secretValue = secret.Value;

Åtkomst till Azure SQL Database

using Azure.Identity;
using Microsoft.Data.SqlClient;

// code omitted for brevity

// Specify the Client ID if using user-assigned managed identities
var clientID = Environment.GetEnvironmentVariable("Managed_Identity_Client_ID");
var credentialOptions = new DefaultAzureCredentialOptions
{
    ManagedIdentityClientId = clientID
};

AccessToken accessToken = await new DefaultAzureCredential(credentialOptions).GetTokenAsync(
    new TokenRequestContext(new string[] { "https://database.windows.net//.default" }));                        

using var connection = new SqlConnection("Server=<DB Server>; Database=<DB Name>;")
{
    AccessToken = accessToken.Token
};
var cmd = new SqlCommand("select top 1 ColumnName from TableName", connection);
await connection.OpenAsync();
SqlDataReader dr = cmd.ExecuteReader();
while(dr.Read())
{
    Console.WriteLine(dr.GetValue(0).ToString());
}
dr.Close();	

Ansluta till resurser som inte stöder Microsoft Entra-ID eller tokenbaserad autentisering i bibliotek

Vissa Azure-resurser har antingen inte stöd för Microsoft Entra-autentisering ännu, eller så har deras klientbibliotek inte stöd för autentisering med en token. Dessa resurser är vanligtvis tekniker med öppen källkod som förväntar sig ett användarnamn och lösenord eller en åtkomstnyckel i en anslutningssträng.

Om du vill undvika att lagra autentiseringsuppgifter i koden eller programkonfigurationen kan du lagra autentiseringsuppgifterna som en hemlighet i Azure Key Vault. Med exemplet ovan kan du hämta hemligheten från Azure KeyVault med hjälp av en hanterad identitet och skicka autentiseringsuppgifterna till din anslutningssträng. Den här metoden innebär att inga autentiseringsuppgifter behöver hanteras direkt i din kod eller miljö.

Riktlinjer om du hanterar token direkt

I vissa scenarier kanske du vill hämta token för hanterade identiteter manuellt i stället för att använda en inbyggd metod för att ansluta till målresursen. Dessa scenarier omfattar inget klientbibliotek för det programmeringsspråk som du använder eller målresursen som du ansluter till eller ansluter till resurser som inte körs i Azure. När du hämtar token manuellt tillhandahåller vi följande riktlinjer:

Cachelagrar de token som du hämtar

För prestanda och tillförlitlighet rekommenderar vi att ditt program cachelagrar token i lokalt minne eller krypteras om du vill spara dem på disk. Eftersom hanterade identitetstoken är giltiga i 24 timmar finns det ingen fördel med att begära nya token regelbundet, eftersom en cachelagrad token returneras från den token som utfärdar slutpunkten. Om du överskrider begärandegränserna kommer du att vara begränsad och få ett HTTP 429-fel.

När du skaffar en token kan du ange att din tokencache upphör att gälla 5 minuter före den expires_on (eller motsvarande egenskap) som returneras när token genereras.

Tokenkontroll

Programmet bör inte förlita sig på innehållet i en token. Tokens innehåll är endast avsett för målgruppen (målresursen) som används, inte den klient som begär token. Tokeninnehållet kan ändras eller krypteras i framtiden.

Exponera eller flytta inte token

Token ska behandlas som autentiseringsuppgifter. Exponera dem inte för användare eller andra tjänster. till exempel loggnings-/övervakningslösningar. De bör inte flyttas från källresursen som använder dem, förutom för att autentisera mot målresursen.

Nästa steg