Door Azure gehoste Go-apps verifiëren bij Azure-resources met behulp van een door het systeem toegewezen beheerde identiteit

De aanbevolen methode voor het verifiëren van een door Azure gehoste app voor andere Azure-resources is het gebruik van een beheerde identiteit. Deze benadering wordt ondersteund voor de meeste Azure-services, waaronder apps die worden gehost op Azure App Service, Azure Container Apps en Azure Virtual Machines. Ontdek meer over verschillende verificatietechnieken en benaderingen op de overzichtspagina voor verificatie . In de volgende secties leert u het volgende:

• Essentiële concepten voor beheerde identiteiten
• Een door het systeem toegewezen beheerde identiteit voor uw app maken
• Rollen toewijzen aan de door het systeem toegewezen beheerde identiteit
• Verifiëren met behulp van de door het systeem toegewezen beheerde identiteit vanuit uw app-code

Essentiële concepten voor beheerde identiteiten

Met een beheerde identiteit kan uw app veilig verbinding maken met andere Azure-resources zonder gebruik te maken van geheime sleutels of andere toepassingsgeheimen. Intern houdt Azure de identiteit bij en met welke resources verbinding mag worden gemaakt. Azure gebruikt deze informatie om automatisch Microsoft Entra-tokens voor de app te verkrijgen, zodat deze verbinding kan maken met andere Azure-resources.

Er zijn twee typen beheerde identiteiten waarmee u rekening moet houden bij het configureren van uw gehoste app:

• Door het systeem toegewezen beheerde identiteiten worden rechtstreeks ingeschakeld op een Azure-resource en zijn gekoppeld aan de levenscyclus. Wanneer de resource wordt verwijderd, verwijdert Azure de identiteit automatisch voor u. Door het systeem toegewezen identiteiten bieden een minimalistische benadering voor het gebruik van beheerde identiteiten.
• Door de gebruiker toegewezen beheerde identiteiten worden gemaakt als zelfstandige Azure-resources en bieden meer flexibiliteit en mogelijkheden. Ze zijn ideaal voor oplossingen met meerdere Azure-resources die dezelfde identiteit en machtigingen moeten delen. Als bijvoorbeeld meerdere virtuele machines toegang moeten hebben tot dezelfde set Azure-resources, biedt een door de gebruiker toegewezen beheerde identiteit herbruikbaar en geoptimaliseerd beheer.

In de volgende secties worden de stappen beschreven voor het inschakelen en gebruiken van een door het systeem toegewezen beheerde identiteit voor een door Azure gehoste app. Als u een door de gebruiker toegewezen beheerde identiteit wilt gebruiken, gaat u naar het artikel met door de gebruiker toegewezen beheerde identiteiten voor meer informatie.

Een door het systeem toegewezen beheerde identiteit inschakelen in de Azure-hostingresource

Als u aan de slag wilt gaan met een door het systeem toegewezen beheerde identiteit met uw app, schakelt u de identiteit in op de Azure-resource die als host fungeert voor uw app, zoals een Azure App Service, Azure Container App of azure Virtual Machine.

U kunt een door het systeem toegewezen beheerde identiteit inschakelen voor een Azure-resource met behulp van Azure Portal of de Azure CLI.

az webapp identity assign \
    --resource-group <resource-group-name> \
    --name <web-app-name>

az vm identity assign \
    --resource-group <resource-group-name> \
    --name <virtual-machine-name>

{
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

Rollen toewijzen aan de beheerde identiteit

Bepaal vervolgens welke rollen uw app nodig heeft en wijs deze rollen toe aan de beheerde identiteit. U kunt rollen toewijzen aan een beheerde identiteit op de volgende bereiken:

• Resource: De toegewezen rollen zijn alleen van toepassing op die specifieke resource.
• Resourcegroep: De toegewezen rollen zijn van toepassing op alle resources in de resourcegroep.
• Abonnement: De toegewezen rollen zijn van toepassing op alle resources in het abonnement.

In het volgende voorbeeld ziet u hoe u rollen toewijst binnen het bereik van de resourcegroep, omdat veel apps al hun gerelateerde Azure-resources beheren met één resourcegroep.

az role assignment create \
    --assignee "{managedIdentityId}" \
    --role "{roleName}" \
    --scope "{scope}"

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

az role assignment create \
    --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --role "Storage Blob Data Contributor" \
    --scope "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/msdocs-sdk-auth-example"

Verifiëren bij Azure-services vanuit uw app

De azidentity-module biedt verschillende referenties : implementaties die zijn aangepast aan de ondersteuning van TokenCredential verschillende scenario's en Microsoft Entra-verificatiestromen. Omdat beheerde identiteit niet beschikbaar is wanneer deze lokaal wordt uitgevoerd, laten de stappen zien welke referenties moeten worden gebruikt in welk scenario:

• Lokale ontwikkelomgeving: gebruik tijdens alleen lokale ontwikkelingDefaultAzureCredential voor een vooraf geconfigureerde keten van referenties. DefaultAzureCredential detecteert gebruikersreferenties vanuit uw lokale ontwikkelhulpprogramma's, zoals de Azure CLI. Het biedt ook flexibiliteit en gemak voor nieuwe pogingen, wachttijden voor antwoorden en ondersteuning voor meerdere verificatieopties. Ga naar het artikel Verifiëren bij Azure-services tijdens lokale ontwikkeling voor meer informatie.
• Door Azure gehoste apps: wanneer uw app wordt uitgevoerd in Azure, gebruikt u ManagedIdentityCredential om de beheerde identiteit die is geconfigureerd voor uw app veilig te detecteren. Als u dit exacte type referentie opgeeft, voorkomt u dat andere beschikbare referenties onverwacht worden opgehaald.

De code implementeren

Voeg de azidentity-module toe.

Navigeer in een terminal van uw keuze naar de projectmap van de toepassing en voer de volgende opdrachten uit:

go get github.com/Azure/azure-sdk-for-go/sdk/azidentity

Azure-services worden geopend met behulp van gespecialiseerde clients uit de verschillende Azure SDK-clientbibliotheken. Voor Go-code die een Azure SDK-client in uw app instantieert, moet u het volgende doen:

1. Importeer het azidentity-pakket.
2. Maak een instantie van het DefaultAzureCredential-type.
3. Geef het exemplaar van DefaultAzureCredential door aan de Azure SDK-clientconstructor.

Een voorbeeld van deze stappen wordt weergegeven in het volgende codesegment met een Azure Storage Blob-client.

import (
	"context"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)

const (
	account       = "https://<replace_with_your_storage_account_name>.blob.core.windows.net/"
	containerName = "sample-container"
	blobName      = "sample-blob"
	sampleFile    = "path/to/sample/file"
)

func main() {
	// create a credential
	cred, err := azidentity.NewDefaultAzureCredential(nil)
	if err != nil {
	  // TODO: handle error
	}

	// create a client for the specified storage account
	client, err := azblob.NewClient(account, cred, nil)
	if err != nil {
	  // TODO: handle error
	}

	// TODO: perform some action with the azblob Client
	// _, err = client.DownloadFile(context.TODO(), <containerName>, <blobName>, <target_file>, <DownloadFileOptions>)
}

Zoals besproken in het artikel Azure SDK voor Go-authenticatieoverzicht, ondersteunt DefaultAzureCredential meerdere authenticatiemethoden en bepaalt welke authenticatiemethode wordt gebruikt tijdens runtime. Het voordeel van deze aanpak is dat uw app verschillende verificatiemethoden in verschillende omgevingen kan gebruiken zonder omgevingsspecifieke code te implementeren. Wanneer de voorgaande code wordt uitgevoerd op uw werkstation tijdens lokale ontwikkeling, DefaultAzureCredential gebruikt ofwel een toepassingsservice-principal, zoals wordt bepaald door de omgevingsinstellingen, of de referenties van ontwikkelaarshulpprogramma's om zich te authenticeren met andere Azure-resources. Daarom kan dezelfde code worden gebruikt om uw app te verifiëren bij Azure-resources tijdens zowel lokale ontwikkeling als wanneer deze wordt geïmplementeerd in Azure.

Een alternatief voor DefaultAzureCredential is om ManagedIdentityCredential te gebruiken. De stappen voor het gebruik ManagedIdentityCredential zijn hetzelfde als voor het gebruik van het DefaultAzureCredential type.

Een voorbeeld van deze stappen wordt weergegeven in het volgende codesegment met een Azure Storage Blob-client.

import (
	"context"
	"github.com/Azure/azure-sdk-for-go/sdk/azidentity"
	"github.com/Azure/azure-sdk-for-go/sdk/storage/azblob"
)

const (
                    // Replace placeholder text with your storage account name
	account       = "https://<replace_with_your_storage_account_name>.blob.core.windows.net/"
	containerName = "sample-container"
	blobName      = "sample-blob"
	sampleFile    = "path/to/sample/file"
)

func main() {
	// create a credential
	cred, err := azidentity.NewManagedIdentityCredential(nil)
	
	// When using User Assigned Managed Identity use this instead and pass your client id in the options
	// clientID := azidentity.ClientID("abcd1234-...")
	// opts := azidentity.ManagedIdentityCredentialOptions{ID: clientID}
	// cred, err := azidentity.NewManagedIdentityCredential(&opts)
	
	if err != nil {
	  // TODO: handle error
	}
	
	// create a client for the specified storage account
	client, err := azblob.NewClient(account, cred, nil)
	if err != nil {
	  // TODO: handle error
	}
	
	// TODO: perform some action with the azblob Client
	// _, err = client.DownloadFile(context.TODO(), <containerName>, <blobName>, <target_file>, <DownloadFileOptions>)
}

De voorgaande code gedraagt zich anders, afhankelijk van de omgeving waarin deze wordt uitgevoerd:

• Op uw lokale ontwikkelwerkstation DefaultAzureCredential zoekt u in de omgevingsvariabelen naar een toepassingsservice-principal of op lokaal geïnstalleerde ontwikkelhulpprogramma's, zoals Azure CLI, voor een set ontwikkelaarsreferenties.
• Wanneer deze wordt geïmplementeerd in Azure, ManagedIdentityCredential detecteert u uw configuraties voor beheerde identiteiten om automatisch te verifiëren bij andere services.