Řetězce přihlašovacích údajů v knihovně Azure Identity pro Go

Knihovna identit Azure poskytuje přihlašovací údaje– veřejné typy, které implementují rozhraní TokenCredential knihovny Azure Core. Přihlašovací údaje představují jedinečný tok ověřování pro získání přístupového tokenu z ID Microsoft Entra. Tyto přihlašovací údaje je možné zřetězit dohromady k vytvoření seřazené posloupnosti ověřovacích mechanismů, které budou použity.

Jak funguje zřetězený přihlašovací údaj

Za běhu se řetěz přihlašovacích údajů pokusí ověřit pomocí prvních přihlašovacích údajů sekvence. Pokud se tento přihlašovací údaj nepodaří získat přístupový token, pokusí se další přihlašovací údaje v této sekvenci atd., dokud se přístupový token úspěšně nezíská. Toto chování znázorňuje následující sekvenční diagram:

diagram, který zobrazuje posloupnost řetězu přihlašovacích údajů

Proč používat řetězy přihlašovacích údajů

Zřetězený přihlašovací údaj může nabídnout následující výhody:

  • povědomí o prostředí: Automaticky vybere nejvhodnější přihlašovací údaje na základě prostředí, ve kterém je aplikace spuštěná. Bez něj byste museli psát kód takto:

    // Set up credential based on environment (Azure or local development)
    if os.Getenv("WEBSITE_HOSTNAME") != "" {
        clientID := azidentity.ClientID("abcd1234-...")
        opts := azidentity.ManagedIdentityCredentialOptions{ID: clientID}
        credential, err = azidentity.NewManagedIdentityCredential(&opts)
    
        if err != nil {
          // TODO: handle error
        }
    } else {
        // Use Azure CLI Credential
        credential, err = azidentity.NewAzureCLICredential(nil)
    
        if err != nil {
          // TODO: handle error
        }
    }
    
  • bezproblémové přechody: Aplikace se může přesunout z místního vývoje do přípravného nebo produkčního prostředí beze změny ověřovacího kódu.

  • vylepšená odolnost: Zahrnuje záložní mechanismus, který se přesune na další přihlašovací údaje, pokud se předchozí pokus o získání přístupového tokenu nezdaří.

Jak vybrat zřetězené přihlašovací údaje

Pokud používáte Go, existují dvě možnosti pro řetězení uživatelských údajů:

  • Použít předkonfigurovaný řetěz: Použijte předkonfigurovaný řetězec implementovaný typem DefaultAzureCredential. Tento přístup najdete v části přehledu DefaultAzureCredential.
  • Vytvoření vlastního řetězu přihlašovacích údajů: Začněte prázdným řetězem a zahrňte jenom to, co potřebujete. Tento přístup najdete v části ChainedTokenCredential - přehled.

Přehled DefaultAzureCredential

DefaultAzureCredential je dogmatický, předkonfigurovaný řetězec přihlašovacích údajů. Je navržená tak, aby podporovala mnoho prostředí spolu s nejběžnějšími toky ověřování a vývojářskými nástroji. Základní řetězec v grafické podobě vypadá takto:

diagram znázorňující tok ověřování DefaultAzureCredential

Pořadí, ve kterém se DefaultAzureCredential pokusí přihlašovací údaje, je následující.

Objednávka Pověření Popis
1 prostředí Načte kolekci proměnných prostředí , aby zjistil, zda je pro aplikaci nakonfigurovaný služební hlavní objekt aplikace (uživatel aplikace). Pokud ano, DefaultAzureCredential tyto hodnoty použije k ověření aplikace v Azure. Tato metoda se nejčastěji používá v serverových prostředích, ale dá se použít také při místním vývoji.
2 Identita pracovní zátěže Pokud je aplikace nasazená na hostitele Azure s povolenou identitou úloh, ověřte tento účet.
3 spravované identity Pokud je aplikace nasazená na hostitele Azure s povolenou spravovanou identitou, ověřte ji v Azure pomocí této spravované identity.
4 Azure CLI Pokud se vývojář ověřil v Azure pomocí příkazu azure CLI az login, ověřte aplikaci v Azure pomocí stejného účtu.
5 Azure Developer CLI Pokud se vývojář ověřil v Azure pomocí azd auth login příkazu Azure Developer CLI, ověřte ho pomocí daného účtu.
6 Azure PowerShell Pokud se vývojář ověřil v Azure pomocí rutiny Azure PowerShellu Connect-AzAccount , ověřte se pomocí daného účtu.

V nejjednodušší podobě můžete použít bezparametrovou verzi DefaultAzureCredential následujícím způsobem:

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

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

// create a Blob service client 
accountURL := "https://<my_account_name>.blob.core.windows.net"
client, err := azblob.NewClient(accountURL, credential, nil)
if err != nil {
    // TODO: handle error
}

Jak přizpůsobit DefaultAzureCredential

Následující části popisují strategie pro řízení, které přihlašovací údaje jsou zahrnuty v řetězci.

Vyloučení kategorie typu přihlašovacích údajů

Chcete-li vyloučit všechny přihlašovací údaje Developer tool nebo Deployed service, nastavte proměnnou prostředí AZURE_TOKEN_CREDENTIALS na prod nebo dev. Pokud se použije hodnota prod, základní řetězec přihlašovacích údajů vypadá takto:

Diagram znázorňující defaultAzureCredential s AZURE_TOKEN_CREDENTIALS nastaveným na

Pokud se použije hodnota dev , řetězec vypadá takto:

Diagram znázorňující defaultAzureCredential s AZURE_TOKEN_CREDENTIALS nastaveným na

Důležité

Proměnná AZURE_TOKEN_CREDENTIALS prostředí je podporována ve azidentity verzích modulu 1.10.0 a novějších.

Pokud chcete zajistit, aby byla proměnná prostředí definovaná, nastavte možnost RequireAzureTokenCredentials na true:

opts := azidentity.DefaultAzureCredentialOptions{RequireAzureTokenCredentials: true}
credential, err := azidentity.NewDefaultAzureCredential(&opts)
if err != nil {
    // TODO: handle error
}

Použití konkrétních přihlašovacích údajů

Pokud chcete vyloučit všechny přihlašovací údaje kromě jednoho, nastavte proměnnou AZURE_TOKEN_CREDENTIALS prostředí na název přihlašovacích údajů. Můžete například zmenšit řetěz DefaultAzureCredential na AzureCLICredential tím, že nastavíte AZURE_TOKEN_CREDENTIALS na AzureCLICredential. Porovnání řetězců se provádí bez rozlišování velkých a malých písmen. Platné řetězcové hodnoty pro proměnnou prostředí zahrnují:

  • AzureCLICredential
  • AzureDeveloperCLICredential
  • AzurePowerShellCredential
  • EnvironmentCredential
  • ManagedIdentityCredential
  • WorkloadIdentityCredential

Důležité

Proměnná AZURE_TOKEN_CREDENTIALS prostředí podporuje jednotlivé názvy přihlašovacích údajů v azidentity modulech verze 1.11.0 a novějších.

Pokud chcete zajistit, aby byla proměnná prostředí definovaná, nastavte možnost RequireAzureTokenCredentials na true:

opts := azidentity.DefaultAzureCredentialOptions{RequireAzureTokenCredentials: true}
credential, err := azidentity.NewDefaultAzureCredential(&opts)
if err != nil {
    // TODO: handle error
}

Přehled ChainedTokenCredential

ChainedTokenCredential je prázdný řetězec, ke kterému přidáte přihlašovací údaje podle potřeb vaší aplikace. Například:

azCLI, err := azidentity.NewAzureCLICredential(nil)
if err != nil {
  // handle error
}

azdCLI, err := azidentity.NewAzureDeveloperCLICredential(nil)
if err != nil {
  // handle error
}

chain, err := azidentity.NewChainedTokenCredential([]azcore.TokenCredential{azCLI, azdCLI}, nil)
if err != nil {
  // handle error
}

Předchozí ukázka kódu vytvoří přizpůsobený řetěz přihlašovacích údajů složený ze dvou přihlašovacích údajů. Nejprve se provede AzureCLICredential, a pokud je to nutné, následuje AzureDeveloperCLICredential. V grafické podobě řetězec vypadá takto:

diagram znázorňující tok ověřování pro instanci ChainedTokenCredential, která se skládá z Azure CLI a přihlašovacích údajů Azure Developer CLI

Spropitné

Pokud chcete dosáhnout vyššího výkonu, optimalizujte řazení přihlašovacích údajů v ChainedTokenCredential od většiny po nejméně používané přihlašovací údaje.

Pokyny k použití pro DefaultAzureCredential

DefaultAzureCredential je nepochybně nejjednodušší způsob, jak začít s knihovnou identit Azure, ale toto pohodlí s sebou přináší i určitá omezení. Po nasazení aplikace do Azure byste měli porozumět požadavkům na ověřování aplikace. Z tohoto důvodu nahraďte DefaultAzureCredential konkrétní implementací TokenCredential, například ManagedIdentityCredential.

Tady je důvod:

  • výzvy při ladění: Při selhání ověřování může být náročné ladit a identifikovat chybné přihlašovací údaje. Abyste viděli průběh z jednoho pověření na další a stav úspěchu/selhání každého z nich, musíte povolit protokolování. Další informace naleznete v tématu Ladění zřetězených přihlašovacích údajů.
  • režijní náklady na výkon: Proces postupného pokusu o více přihlašovacích údajů může představovat režijní náklady na výkon. Například při spuštění na místním vývojovém počítači není spravovaná identita k dispozici. V důsledku toho ManagedIdentityCredential vždy selže v místním vývojovém prostředí, pokud není explicitně zakázána příslušnou vlastností s předponou exclude.
  • nepředvídatelné chování: DefaultAzureCredential kontroluje přítomnost určitých proměnných prostředí . Je možné, že někdo může přidat nebo upravit tyto proměnné prostředí na úrovni systému na hostitelském počítači. Tyto změny platí globálně a proto mění chování DefaultAzureCredential za běhu v libovolné aplikaci spuštěné na tomto počítači.

Odladění zřetězených přihlašovacích údajů

Pokud chcete diagnostikovat neočekávaný problém, nebo pochopit, co dělá zřetězený přihlašovací údaj, povolte protokolování ve vaší aplikaci. Volitelně můžete protokoly filtrovat jenom na události generované z klientské knihovny Azure Identity. Například:

import azlog "github.com/Azure/azure-sdk-for-go/sdk/azcore/log"
// print log output to stdout
azlog.SetListener(func(event azlog.Event, s string) {
    fmt.Println(s)
})
// include only azidentity credential logs
azlog.SetEvents(azidentity.EventAuthentication)

Pokyny k řešení chyb z konkrétních typů přihlašovacích údajů najdete v průvodci odstraňováním potíží .