Go-apps verifiëren bij Azure-services tijdens lokale ontwikkeling met behulp van service-principals

Tijdens lokale ontwikkeling moeten toepassingen worden geverifieerd bij Azure om toegang te krijgen tot verschillende Azure-services. Twee veelvoorkomende methoden voor lokale verificatie zijn het een ontwikkelaarsaccount of een service-principal te gebruiken. In dit artikel wordt uitgelegd hoe u een toepassingsservice-principal gebruikt. In de volgende secties leert u het volgende:

• Een toepassing registreren bij Microsoft Entra om een service-principal te maken
• Microsoft Entra-groepen gebruiken om machtigingen efficiënt te beheren
• Rollen toewijzen aan scoperechten
• Authenticeren met behulp van een service-principal vanuit uw app-code

Met behulp van service-principals voor toegewezen toepassingen kunt u voldoen aan het principe van minimale bevoegdheden bij het openen van Azure-resources. Machtigingen zijn beperkt tot de specifieke vereisten van de app tijdens de ontwikkeling, waardoor onbedoelde toegang tot Azure-resources wordt voorkomen die zijn bedoeld voor andere apps of services. Deze aanpak helpt ook problemen te voorkomen wanneer de app naar productie wordt verplaatst door ervoor te zorgen dat deze niet te veel bevoegdheden heeft in de ontwikkelomgeving.

Wanneer de toepassing is geregistreerd in Azure, wordt er een toepassingsservice-principal gemaakt. Voor lokale ontwikkeling:

• Maak een afzonderlijke app-registratie voor elke ontwikkelaar die aan de app werkt om ervoor te zorgen dat elke ontwikkelaar een eigen toepassingsservice-principal heeft, zodat er geen referenties hoeven te worden gedeeld.
• Maak een afzonderlijke app-registratie voor elke app om de machtigingen van de app te beperken tot alleen wat nodig is.

Tijdens lokale ontwikkeling worden omgevingsvariabelen ingesteld met de identiteit van de toepassingsservice-principal. De Azure Identity-bibliotheek leest deze omgevingsvariabelen om de app te verifiëren bij de vereiste Azure-resources.

De app registreren in Azure

Toepassingsservice-principalobjecten worden gemaakt via een app-registratie in Azure met behulp van Azure Portal of Azure CLI.

Een Microsoft Entra-groep maken voor lokale ontwikkeling

Maak een Microsoft Entra-groep om de rollen (machtigingen) die de app nodig heeft in lokale ontwikkeling in te kapselen in plaats van de rollen toe te wijzen aan afzonderlijke service-principal-objecten. Deze aanpak biedt de volgende voordelen:

• Elke ontwikkelaar heeft dezelfde rollen toegewezen op groepsniveau.
• Als er een nieuwe rol nodig is voor de app, hoeft deze alleen aan de groep voor de app te worden toegevoegd.
• Als een nieuwe ontwikkelaar lid wordt van het team, wordt er een nieuwe toepassingsservice-principal gemaakt voor de ontwikkelaar en toegevoegd aan de groep, zodat de ontwikkelaar over de juiste machtigingen beschikt om aan de app te werken.

Rollen toewijzen aan de groep

Bepaal vervolgens welke rollen (machtigingen) uw app nodig heeft voor welke resources en wijs deze rollen toe aan de Microsoft Entra-groep die u hebt gemaakt. Aan groepen kan een rol worden toegewezen op het niveau van de bron, bron-groep of abonnement. In dit voorbeeld ziet u hoe u rollen toewijst binnen het bereik van de resourcegroep, omdat de meeste apps al hun Azure-resources groeperen in één resourcegroep.

De omgevingsvariabelen van de app instellen

Het DefaultAzureCredential object zoekt tijdens runtime naar de informatie van de service-principal in een set omgevingsvariabelen. Omdat de meeste ontwikkelaars aan meerdere applicaties werken, is het raadzaam om een pakket zoals godotenv te gebruiken om toegang te krijgen tot een omgeving vanuit een .env bestand dat in de map van de applicatie tijdens de ontwikkeling is opgeslagen. Dit is het bereik van de omgevingsvariabelen die worden gebruikt voor het verifiëren van de toepassing bij Azure, zodat ze alleen door deze toepassing kunnen worden gebruikt.

Het .env bestand wordt nooit ingecheckt bij broncodebeheer omdat het de geheime sleutel van de toepassing voor Azure bevat. Het standaard .gitignore-bestand voor Go sluit het .env bestand automatisch uit van het inchecken.

Als u het godotenv-pakket wilt gebruiken, installeert u eerst het pakket in uw toepassing.

go get github.com/joho/godotenv

Maak vervolgens een .env bestand in de hoofdmap van uw toepassing. Stel de omgevingsvariabelewaarden als volgt in met waarden die zijn verkregen uit het app-registratieproces:

• AZURE_CLIENT_ID → de waarde van de app-id.
• AZURE_TENANT_ID → De waarde van de Tenant-ID.
• AZURE_CLIENT_SECRET → Het wachtwoord/de referentie die voor de app is gegenereerd.

AZURE_CLIENT_ID=00001111-aaaa-2222-bbbb-3333cccc4444
AZURE_TENANT_ID=aaaabbbb-0000-cccc-1111-dddd2222eeee
AZURE_CLIENT_SECRET=Ee5Ff~6Gg7.-Hh8Ii9Jj0Kk1Ll2Mm3_Nn4Oo5Pp6

Gebruik ten slotte in de opstartcode voor uw toepassing de godotenv bibliotheek om de omgevingsvariabelen uit het bestand bij het .env opstarten te lezen.

// Imports of fmt, log, and os omitted for brevity 
import "github.com/joho/godotenv"

environment := os.Getenv("ENVIRONMENT")

if environment == "development" {
	fmt.Println("Loading environment variables from .env file")

	// Load the .env file
	err := godotenv.Load(".env")
	if err != nil {
	    log.Fatalf("Error loading .env file: %v", err)
	}
}

DefaultAzureCredential implementeren in uw toepassing

Als u Azure SDK-clientobjecten wilt verifiëren bij Azure, moet uw toepassing de DefaultAzureCredential klasse van het azidentity pakket gebruiken. In dit scenario detecteert DefaultAzureCredential of de omgevingsvariabelen AZURE_CLIENT_ID, AZURE_TENANT_ID, en AZURE_CLIENT_SECRET zijn ingesteld en leest deze om de service-gebruikergegevens van de applicatie op te halen voor verbinding met Azure.

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-clientobject in uw app wordt gemaakt, 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 hiervan wordt weergegeven in het volgende codesegment.

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