Delen via

Authentiseren van Azure-gehoste apps bij Azure-resources met behulp van de Azure SDK voor Go

  • Artikel

Wanneer u een app in Azure host met behulp van services zoals Azure App Service, Azure Virtual Machines of Azure Container Instances, is de aanbevolen methode voor het verifiëren van een app voor Azure-resources met beheerde identiteit.

Een beheerde identiteit biedt een identiteit voor uw app, zodat deze verbinding kan maken met andere Azure-resources zonder dat u een geheime sleutel of een ander toepassingsgeheim hoeft te gebruiken. Intern kent Azure de identiteit van uw app 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, allemaal zonder dat u toepassingsgeheimen hoeft te beheren.

Notitie

Apps die worden uitgevoerd op Azure Kubernetes Service (AKS) kunnen een workloadidentiteit gebruiken om te verifiëren met Azure-resources. In AKS vertegenwoordigt een workloadidentiteit een vertrouwensrelatie tussen een beheerde identiteit en een Kubernetes-serviceaccount. Als een toepassing die is geïmplementeerd in AKS is geconfigureerd met een Kubernetes-serviceaccount in een dergelijke relatie, DefaultAzureCredential de app verifieert bij Azure met behulp van de beheerde identiteit. Verificatie met behulp van een workloadidentiteit wordt besproken in Microsoft Entra-workload-id gebruiken met Azure Kubernetes Service. Zie Workloadidentiteit implementeren en configureren in een AKS-cluster (Azure Kubernetes Service)voor stappen voor het configureren van de identiteit van workloads.

Typen beheerde identiteiten

Er zijn twee typen beheerde identiteiten:

  • door het systeem toegewezen beheerde identiteiten: dit type beheerde identiteit wordt geleverd door en rechtstreeks gekoppeld aan een Azure-resource. Wanneer u beheerde identiteit inschakelt voor een Azure-resource, krijgt u een door het systeem toegewezen beheerde identiteit voor die resource. Een door het systeem toegewezen beheerde identiteit is gekoppeld aan de levenscyclus van de Azure-resource waaraan deze is gekoppeld. Wanneer de resource wordt verwijderd, verwijdert Azure de identiteit automatisch voor u. Omdat u alleen beheerde identiteit moet inschakelen voor de Azure-resource die als host fungeert voor uw code, is deze benadering het eenvoudigste type beheerde identiteit dat moet worden gebruikt.
  • door de gebruiker toegewezen beheerde identiteiten: u kunt ook een beheerde identiteit maken als een zelfstandige Azure-resource. Deze benadering wordt het vaakst gebruikt wanneer uw oplossing meerdere workloads heeft die worden uitgevoerd op meerdere Azure-resources die allemaal dezelfde identiteit en dezelfde machtigingen moeten delen. Als uw oplossing bijvoorbeeld onderdelen had die worden uitgevoerd op meerdere App Service- en virtuele-machine-exemplaren die allemaal toegang nodig hebben tot dezelfde set Azure-resources, is een door de gebruiker toegewezen beheerde identiteit die in deze resources wordt gebruikt logisch.

In dit artikel worden de stappen beschreven voor het inschakelen en gebruiken van een door het systeem toegewezen beheerde identiteit voor een app. Als u een door de gebruiker toegewezen beheerde identiteit wilt gebruiken, raadpleegt u het artikel Door de gebruiker toegewezen beheerde identiteiten beheren om te zien hoe u een door de gebruiker toegewezen beheerde identiteit maakt.

1 - Beheerde identiteit inschakelen in de Azure-resource die als host fungeert voor de app

De eerste stap is het inschakelen van een beheerde identiteit in Azure-resource die als host fungeert voor uw app. Als u bijvoorbeeld een Gin-toepassing host met behulp van Azure Container Apps, moet u een beheerde identiteit inschakelen voor de container-app. Als u een virtuele machine gebruikt om uw app te hosten, stelt u uw VIRTUELE machine in staat om beheerde identiteit te gebruiken.

U kunt een beheerde identiteit inschakelen voor een Azure-resource met behulp van De Azure-portal of de Azure CLI.

Azure CLI-opdrachten kunnen worden uitgevoerd in de Azure Cloud Shell- of op een werkstation waarop de Azure CLI is geïnstalleerd.

De Azure CLI-opdrachten die worden gebruikt om beheerde identiteit voor een Azure-resource in te schakelen, zijn van het formulier az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Hieronder ziet u specifieke opdrachten voor populaire Azure-services.

az containerapp identity assign \
    --resource-group <resource-group-name> \
    --name <container-app-name> \
    --system-assigned

De uitvoer ziet er als volgt uit.

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

De principalId waarde is de unieke id van de beheerde identiteit. Bewaar een kopie van deze uitvoer omdat u deze waarden nodig hebt in de volgende stap.

2 - Rollen toewijzen aan de beheerde identiteit

Vervolgens moet u bepalen welke rollen (machtigingen) uw app nodig heeft en de beheerde identiteit toewijzen aan die rollen in Azure. Aan een beheerde identiteit kunnen rollen worden toegewezen voor een resource, resourcegroep of abonnementsbereik. In dit voorbeeld ziet u hoe u rollen toewijst aan het bereik van de resourcegroep, omdat de meeste toepassingen al hun Azure-resources groeperen in één resourcegroep.

Aan een beheerde identiteit wordt een rol in Azure toegewezen met behulp van de opdracht az role assignment create. Gebruik voor de toegewezene de principalId die u in stap 1 hebt gekopieerd.

az role assignment create --assignee {managedIdentityprincipalId} \
    --scope /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} \
    --role "{roleName}"

Om de rolnamen te verkrijgen waaraan een service-principal kan worden toegewezen, gebruikt u de opdracht az role definition list.

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

Als u bijvoorbeeld de beheerde identiteit met de id van aaaaaaaa-bbbb-cccc-1111-222222222222 lees-, schrijf- en verwijdertoegang wilt geven tot Azure Storage-blobcontainers en -gegevens in alle opslagaccounts in de uw-resourcegroep-naam resourcegroep binnen het abonnement met id aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e, wijst u de toepassingsservice-principal toe aan de rol van Storage Blob Data Contributor met de volgende opdracht.

az role assignment create --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/your-resource-group-name \
    --role "Storage Blob Data Contributor"

Zie het artikel Azure-rollen toewijzen met behulp van de Azure CLIvoor meer informatie over het toewijzen van machtigingen op resource- of abonnementsniveau.

3 - DefaultAzureCredential implementeren in uw toepassing

Wanneer uw code wordt uitgevoerd in Azure en beheerde identiteit is ingeschakeld voor de Azure-resource die als host fungeert voor uw app, bepaalt de DefaultAzureCredential de referenties die moeten worden gebruikt in de volgende volgorde:

  1. Controleer de omgeving op een service-principal zoals gedefinieerd door de omgevingsvariabelen AZURE_CLIENT_ID, AZURE_TENANT_ID, en AZURE_CLIENT_SECRET of AZURE_CLIENT_CERTIFICATE_PATH en (optioneel) AZURE_CLIENT_CERTIFICATE_PASSWORD.
  2. Controleer de AZURE_CLIENT_ID omgevingsvariabele voor de client-id van een door de gebruiker toegewezen beheerde identiteit.
  3. Gebruik de door het systeem toegewezen beheerde identiteit voor de Azure-resource als deze is ingeschakeld.

In dit artikel gebruiken we de door het systeem toegewezen beheerde identiteit voor een Azure Container App, dus we hoeven geen beheerde identiteit in de omgeving te configureren of door te geven als parameter. In de volgende stappen ziet u hoe u DefaultAzureCredentialkunt gebruiken.

Voeg eerst het azidentity-pakket toe aan uw toepassing.

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

Voor elke Go-code waarmee een Azure SDK-client in uw app wordt geïnstitueert, wilt 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 eerder genoemde code wordt uitgevoerd op uw werkstation tijdens lokale ontwikkeling, gebruikt DefaultAzureCredential een service principal van de applicatie, zoals bepaald door omgevingsinstellingen of ontwikkelaarstoolreferenties, om zich te verifiëren bij 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.

Belangrijk

DefaultAzureCredential vereenvoudigt verificatie bij het ontwikkelen van toepassingen die in Azure worden geïmplementeerd door referenties te combineren die worden gebruikt in Azure-hostingomgevingen en -referenties die worden gebruikt in lokale ontwikkeling. In productie is het beter om een specifiek referentietype te gebruiken, zodat verificatie voorspelbaarder en eenvoudiger te opsporen is.

4 - ManagedIdentityCredential implementeren in uw toepassing

De stappen voor het implementeren van ManagedIdentityCredential zijn hetzelfde als het gebruik van DefaultAzureCredential type.

Voeg eerst het azidentity-pakket toe aan uw toepassing.

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

Voor elke Go-code waarmee een Azure SDK-client in uw app wordt geïnstitueert, wilt u het volgende doen:

  1. Importeer het azidentity-pakket.
  2. Maak een exemplaar van het type ManagedIdentityCredential.
  3. Geef het exemplaar van ManagedIdentityCredential door aan de Azure SDK-client-constructor.

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.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>)
}