gebeurtenis
17 mrt, 23 - 21 mrt, 23
Neem deel aan de meetup-serie om schaalbare AI-oplossingen te bouwen op basis van praktijkgebruiksvoorbeelden met collega-ontwikkelaars en experts.
Nu registrerenDeze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
Wanneer een toepassing toegang moet hebben tot een Azure-resource zoals Azure Storage, Azure Key Vault of Azure AI-services, moet de toepassing worden geverifieerd bij Azure. Deze vereiste geldt voor alle toepassingen, ongeacht of deze zijn geïmplementeerd in Azure, on-premises zijn geïmplementeerd of in ontwikkeling zijn op een lokaal ontwikkelwerkstation. In dit artikel worden de aanbevolen methoden beschreven voor het verifiëren van een app bij Azure wanneer u de Azure SDK voor Go gebruikt.
Gebruik verificatie op basis van tokens in plaats van verbindingsreeksen voor uw apps wanneer ze worden geverifieerd bij Azure-resources. De Azure SDK voor Go biedt mechanismen die ondersteuning bieden voor verificatie op basis van tokens. Apps kunnen naadloos worden geverifieerd bij Azure-resources, ongeacht of de app zich in lokale ontwikkeling bevindt, in Azure is geïmplementeerd of op een on-premises server is geïmplementeerd.
Het specifieke type verificatie op basis van tokens dat een app gebruikt om te verifiëren bij Azure-resources, is afhankelijk van waar de app wordt uitgevoerd. De typen verificatie op basis van tokens worden weergegeven in het volgende diagram.
Met het DefaultAzureCredential type dat wordt geleverd door de Azure SDK, kunnen apps verschillende verificatiemethoden gebruiken, afhankelijk van de omgeving waarin ze worden uitgevoerd. Op deze manier kunnen apps worden gepromoveerd van lokale ontwikkeling tot testomgevingen naar productie zonder codewijzigingen.
U configureert de juiste verificatiemethode voor elke omgeving en DefaultAzureCredential
deze verificatiemethode automatisch detecteert en gebruikt. Het gebruik van DefaultAzureCredential
heeft de voorkeur boven het handmatig coderen van voorwaardelijke logica of functievlagmen om verschillende verificatiemethoden in verschillende omgevingen te gebruiken.
Details over het gebruik van het type DefaultAzureCredential
worden besproken in de sectie DefaultAzureCredential gebruiken in een toepassing.
Gebruik verificatie op basis van tokens in plaats van verbindingsreeksen wanneer u apps voor Azure bouwt. Verificatie op basis van tokens biedt de volgende voordelen ten opzichte van verificatie met verbindingsreeksen:
Beperk het gebruik van verbindingsreeksen tot initiële proof-of-concept-apps of prototypen voor ontwikkeling die geen toegang hebben tot productie- of gevoelige gegevens. Anders heeft de verificatie op basis van tokens die beschikbaar is in de Azure SDK altijd de voorkeur bij verificatie bij Azure-resources.
Wanneer u host in een serveromgeving, krijgt elke toepassing een unieke toepassingsidentiteit per omgeving waarin de toepassing wordt uitgevoerd. In Azure wordt een app-identiteit vertegenwoordigd door een service-principal. Dit speciale type beveiligingsprincipaal identificeert en verifieert apps bij Azure. Het type service-principal dat voor uw app moet worden gebruikt, is afhankelijk van waar uw app wordt uitgevoerd:
Verificatiemethode | Beschrijving |
---|---|
Apps die worden gehost in Azure | Apps die worden gehost in Azure, moeten een service-principal voor beheerde identiteit gebruiken. Beheerde identiteiten zijn ontworpen om de identiteit van een app te vertegenwoordigen die wordt gehost in Azure en kan alleen worden gebruikt met door Azure gehoste apps. Aan een Gin web-app die wordt gehost in Azure Container Apps, wordt bijvoorbeeld een beheerde identiteit toegewezen. De beheerde identiteit die aan de app is toegewezen, wordt vervolgens gebruikt om de app te verifiëren bij andere Azure-services. Toepassingen die worden uitgevoerd in Azure Kubernetes Service (AKS) kunnen een workloadidentiteit-referentie gebruiken. Deze referentie is gebaseerd op een beheerde identiteit met een vertrouwensrelatie met een AKS-serviceaccount. |
Apps die buiten Azure worden gehost (bijvoorbeeld on-premises apps) |
Apps die buiten Azure worden gehost (bijvoorbeeld on-premises apps) die verbinding moeten maken met Azure-services, moeten gebruikmaken van een toepassingsservice-principal. Een toepassingsservice-principal vertegenwoordigt de identiteit van de app in Azure en wordt gemaakt via het registratieproces van de toepassing. Denk bijvoorbeeld aan een Gin web-app die on-premises wordt gehost en die gebruikmaakt van Azure Blob Storage. U maakt een toepassingsservice-principal voor de app met behulp van het app-registratieproces. De AZURE_CLIENT_ID , AZURE_TENANT_ID en AZURE_CLIENT_SECRET worden allemaal opgeslagen als omgevingsvariabelen die tijdens runtime door de toepassing moeten worden gelezen en waarmee de app kan worden geverifieerd bij Azure met behulp van de service-principal van de toepassing. |
Wanneer een toepassing wordt uitgevoerd op het werkstation van een ontwikkelaar tijdens de lokale ontwikkeling, moet deze nog steeds worden geverifieerd bij alle Azure-services die door de app worden gebruikt. Er zijn twee belangrijke strategieën voor het verifiëren van apps bij Azure tijdens lokale ontwikkeling:
Verificatiemethode | Beschrijving |
---|---|
Maak specifieke toepassingsservice-principalobjecten aan voor gebruik tijdens lokale ontwikkeling. | In deze methode worden toegewezen toepassingsservice-principal-objecten ingesteld met behulp van het app-registratieproces voor gebruik tijdens lokale ontwikkeling. De identiteit van de service-principal wordt vervolgens opgeslagen als omgevingsvariabelen die toegankelijk zijn voor de app wanneer deze wordt uitgevoerd in lokale ontwikkeling. Met deze methode kunt u de specifieke resourcemachtigingen die de app nodig heeft, toewijzen aan de service-principal-objecten die tijdens de lokale ontwikkeling door ontwikkelaars worden gebruikt. Deze procedure zorgt ervoor dat de toepassing alleen toegang heeft tot de specifieke resources die deze nodig heeft en repliceert de machtigingen die de app in productie heeft. Het nadeel van deze aanpak is dat er afzonderlijke service-principalobjecten moeten worden gemaakt voor elke ontwikkelaar die aan een toepassing werkt. |
Verifieer de app bij Azure met behulp van de referenties van de ontwikkelaar tijdens de lokale ontwikkeling. | In deze methode moet een ontwikkelaar zijn aangemeld bij Azure vanuit de Azure CLI of Azure Developer CLI op hun lokale werkstation. De toepassing heeft vervolgens toegang tot de referenties van de ontwikkelaar vanuit het referentiearchief en gebruikt deze referenties voor toegang tot Azure-resources vanuit de app. Deze methode heeft het voordeel van eenvoudigere installatie omdat een ontwikkelaar zich alleen hoeft aan te melden bij zijn Azure-account via een van de bovengenoemde ontwikkelhulpprogramma's. Het nadeel van deze benadering is dat het account van de ontwikkelaar waarschijnlijk meer machtigingen heeft dan vereist is voor de toepassing. Als gevolg hiervan repliceert de toepassing niet nauwkeurig de machtigingen waarmee deze wordt uitgevoerd in productie. |
DefaultAzureCredential- is een bewust gekozen en geordende reeks van mechanismen voor authenticatie bij Microsoft Entra ID. Elk verificatiemechanisme is een klasse die de TokenCredential-interface implementeert en een referentiewordt genoemd. Tijdens runtime probeert DefaultAzureCredential
te verifiëren met behulp van de eerste referentie. Als deze referentie geen toegangstoken kan verkrijgen, wordt de volgende referentie in de reeks geprobeerd, enzovoort, totdat een toegangstoken is verkregen. Op deze manier kan uw app verschillende referenties in verschillende omgevingen gebruiken zonder omgevingsspecifieke code te schrijven.
Als u DefaultAzureCredential- wilt gebruiken in een Go-app, voegt u het azidentity-pakket toe aan uw toepassing.
go get github.com/Azure/azure-sdk-for-go/sdk/azidentity
In het volgende codevoorbeeld ziet u hoe u een exemplaar van de Azure SDK-client maakt met DefaultAzureCredential
. In dit geval wordt deze azblob
client gebruikt voor toegang tot Azure Blob Storage.
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>)
}
Wanneer de voorgaande code wordt uitgevoerd op uw lokale ontwikkelwerkstation, wordt er gezocht in de omgevingsvariabelen voor een toepassingsservice-principal of bij lokaal geïnstalleerde ontwikkelhulpprogramma's, zoals de Azure CLI, voor een set ontwikkelaarsreferenties. Beide benaderingen kunnen worden gebruikt om de app te verifiëren bij Azure-resources tijdens lokale ontwikkeling.
Wanneer deze wordt geïmplementeerd in Azure, kan dezelfde code uw app ook verifiëren bij Azure-resources.
DefaultAzureCredential
kunt omgevingsinstellingen en beheerde identiteitsconfiguraties ophalen om automatisch te verifiëren bij Azure-services.
gebeurtenis
17 mrt, 23 - 21 mrt, 23
Neem deel aan de meetup-serie om schaalbare AI-oplossingen te bouwen op basis van praktijkgebruiksvoorbeelden met collega-ontwikkelaars en experts.
Nu registrerenTraining
Module
Op rollen gebaseerd toegangsbeheer en beheerde identiteitsverificatie implementeren in Azure OpenAI met .NET.
Certificering
Bouw end-to-end-oplossingen in Microsoft Azure om Azure Functions te maken, web-apps te implementeren en te beheren, oplossingen te ontwikkelen die gebruikmaken van Azure Storage en meer.
Documentatie
In dit artikel wordt beschreven hoe u verificatie configureert voor apps naar Azure-services met de Azure SDK voor Go wanneer de app wordt gehost in een Azure-service, zoals Azure App Service, Azure Container Apps of Azure Virtual Machines.
Aanvullende methoden voor verificatie bij Azure-resources vanuit Go-apps - Go on Azure
In dit artikel worden aanvullende, minder gangbare methoden beschreven die u kunt gebruiken om uw Go-app te verifiëren bij Azure-resources.
Referentieketens in de Azure Identity-clientbibliotheek voor Go - Go on Azure
In dit artikel worden de klassen DefaultAzureCredential en ChainedTokenCredential in de Azure Identity-clientbibliotheek voor Go beschreven.
In dit artikel wordt beschreven hoe u uw toepassing verifieert bij Azure-services wanneer u de Azure SDK voor Go gebruikt tijdens lokale ontwikkeling met behulp van ontwikkelaarsaccounts.