Řetězy přihlašovacích údajů v klientské knihovně Azure Identity pro Python
Klientská knihovna Azure Identity poskytuje přihlašovací údaje – veřejné třídy, které implementují protokol 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ězeny dohromady a vytvořit seřazenou posloupnost ověřovacích mechanismů, které se mají pokusit.
Jak funguje zřetězený přihlašovací údaje
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:
Proč používat řetězy přihlašovacích údajů
Zřetězený přihlašovací údaje můžou nabídnout následující výhody:
Rozpoznávání 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"): credential = ManagedIdentityCredential(client_id=user_assigned_client_id) else: credential = AzureCliCredential()
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 náhradní mechanismus, který se přesune na další přihlašovací údaje, když se předchozí pokus o získání přístupového tokenu nezdaří.
Výběr zřetězených přihlašovacích údajů
Existují dvě různorodé filozofie pro řetězení přihlašovacích údajů:
- "Odbourat" řetězec: Začněte předkonfigurovaným řetězem a vylučte, co nepotřebujete. Tento přístup najdete v části s přehledem DefaultAzureCredential.
- "Sestavte" řetězec: Začněte prázdným řetězem a zahrňte pouze to, co potřebujete. Tento přístup najdete v části Přehled ChainedTokenCredential.
Přehled defaultAzureCredential
DefaultAzureCredential je 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:
Pořadí, ve kterém DefaultAzureCredential
se pokoušíte o přihlašovací údaje, následuje.
Objednávka | Reference | Popis | Povoleno ve výchozím nastavení? |
---|---|---|---|
0 | Prostředí | Načte kolekci proměnných prostředí a určí, jestli je pro aplikaci nakonfigurovaný instanční objekt aplikace (uživatel aplikace). Pokud ano, DefaultAzureCredential použije tyto hodnoty 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. |
Ano |
2 | Identita úloh | Pokud je aplikace nasazená na hostitele Azure s povolenou identitou úloh, ověřte tento účet. | Ano |
3 | Spravovaná identita | Pokud je aplikace nasazená na hostitele Azure s povolenou spravovanou identitou, ověřte ji v Azure pomocí této spravované identity. | Ano |
4 | Mezipaměť sdílených tokenů | Pokud se vývojář ověřil v Azure přihlášením k sadě Visual Studio, ověřte aplikaci do Azure pomocí stejného účtu. (Jenom Windows.) | Ano |
5 | 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. |
Ano |
6 | Azure PowerShell | Pokud se vývojář ověřil v Azure pomocí rutiny Azure PowerShellu Connect-AzAccount , ověřte aplikaci v Azure pomocí stejného účtu. |
Ano |
7 | Azure Developer CLI | Pokud se vývojář ověřil v Azure pomocí příkazu Azure Developer CLI azd auth login , ověřte ho pomocí daného účtu. |
Ano |
8 | Interaktivní prohlížeč | Pokud je tato možnost povolená, interaktivně ověřte vývojáře prostřednictvím výchozího prohlížeče aktuálního systému. | No |
V nejjednodušší podobě můžete použít bezparametrovou verzi DefaultAzureCredential
následujícím způsobem:
from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient
# Acquire a credential object
credential = DefaultAzureCredential()
blob_service_client = BlobServiceClient(
account_url="https://<my_account_name>.blob.core.windows.net",
credential=credential
)
Přizpůsobení defaultAzureCredential
Pokud chcete odebrat přihlašovací údaje, DefaultAzureCredential
použijte odpovídající exclude
parametr klíčového slova s předponou . Příklad:
credential = DefaultAzureCredential(
exclude_environment_credential=True,
exclude_workload_identity_credential=True,
managed_identity_client_id=user_assigned_client_id
)
V předchozí ukázce EnvironmentCredential
kódu a WorkloadIdentityCredential
jsou odebrány z řetězu přihlašovacích údajů. V důsledku toho je prvním pokusem o ManagedIdentityCredential
přihlašovací údaje . Upravený řetězec vypadá takto:
Poznámka:
InteractiveBrowserCredential
je ve výchozím nastavení vyloučena, a proto se v předchozím diagramu nezobrazuje. Chcete-li zahrnout InteractiveBrowserCredential
, nastavte parametr klíčového exclude_interactive_browser_credential
slova při False
volání konstruktoru DefaultAzureCredential
.
Vzhledem k tomu, že jsou exclude
parametry klíčového slova s předponou nastaveny na True
(konfigurují se vyloučení přihlašovacích údajů), výhody použití DefaultAzureCredential
se snižují. V takových případech ChainedTokenCredential
je lepší volbou a vyžaduje méně kódu. Pro ilustraci se tyto dvě ukázky kódu chovají stejným způsobem:
credential = DefaultAzureCredential(
exclude_environment_credential=True,
exclude_workload_identity_credential=True,
exclude_shared_token_cache_credential=True,
exclude_azure_powershell_credential=True,
exclude_azure_developer_cli_credential=True,
managed_identity_client_id=user_assigned_client_id
)
Přehled ChainedTokenCredential
ChainedTokenCredential je prázdný řetězec, ke kterému přidáváte přihlašovací údaje, které vyhovují potřebám vaší aplikace. Příklad:
credential = ChainedTokenCredential(
ManagedIdentityCredential(client_id=user_assigned_client_id),
AzureCliCredential()
)
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ů. Varianta spravované identity ManagedIdentityCredential
přiřazená uživatelem se nejprve pokusí a v případě potřeby následuje AzureCliCredential
. V grafické podobě řetězec vypadá takto:
Tip
Pokud chcete dosáhnout vyššího výkonu, optimalizujte řazení přihlašovacích údajů v ChainedTokenCredential
produkčním prostředí. Přihlašovací údaje určené k použití v místním vývojovém prostředí by měly být přidány jako poslední.
Pokyny k použití pro DefaultAzureCredential
DefaultAzureCredential
je nepochybně nejjednodušší způsob, jak začít s klientskou knihovnou Azure Identity, ale s tímto pohodlím přichází kompromisy. Po nasazení aplikace do Azure byste měli porozumět požadavkům na ověřování aplikace. Z tohoto důvodu důrazně zvažte přechod z DefaultAzureCredential
jednoho z následujících řešení:
- Konkrétní implementace přihlašovacích údajů, například
ManagedIdentityCredential
. - Pared-down
ChainedTokenCredential
implementace optimalizovaná pro prostředí Azure, ve kterém vaše aplikace běží.
Tady je důvod:
- Problémy s laděním: Při selhání ověřování může být náročné ladit a identifikovat odsunuté 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 najdete v tématu Ladění zřetězených přihlašovacích údajů.
- Režie na výkon: Proces postupného pokusu o více přihlašovacích údajů může představovat režii 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áno prostřednictvím odpovídajícíexclude
vlastnosti -prefixed. - 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.
Ladění zřetězených přihlašovacích údajů
Pokud chcete diagnostikovat neočekávaný problém nebo zjistit, co dělá zřetězený přihlašovací údaj, povolte protokolování v aplikaci. Volitelně můžete protokoly filtrovat jenom na události generované z klientské knihovny Azure Identity. Příklad:
import logging
from azure.identity import DefaultAzureCredential
# Set the logging level for the Azure Identity library
logger = logging.getLogger("azure.identity")
logger.setLevel(logging.DEBUG)
# Direct logging output to stdout. Without adding a handler,
# no logging output is visible.
handler = logging.StreamHandler(stream=sys.stdout)
logger.addHandler(handler)
# Optional: Output logging levels to the console.
print(
f"Logger enabled for ERROR={logger.isEnabledFor(logging.ERROR)}, "
f"WARNING={logger.isEnabledFor(logging.WARNING)}, "
f"INFO={logger.isEnabledFor(logging.INFO)}, "
f"DEBUG={logger.isEnabledFor(logging.DEBUG)}"
)
Pro účely ilustrace předpokládejme, že se k ověření požadavku na účet úložiště objektů blob používá bez DefaultAzureCredential
parametrů. Aplikace běží v místním vývojovém prostředí a vývojář se ověřil v Azure pomocí Azure CLI. Předpokládejme také, že úroveň protokolování je nastavena na logging.DEBUG
. Při spuštění aplikace se ve výstupu zobrazí následující relevantní položky:
Logger enabled for ERROR=True, WARNING=True, INFO=True, DEBUG=True
No environment configuration found.
ManagedIdentityCredential will use IMDS
EnvironmentCredential.get_token failed: EnvironmentCredential authentication unavailable. Environment variables are not fully configured.
Visit https://aka.ms/azsdk/python/identity/environmentcredential/troubleshoot to troubleshoot this issue.
ManagedIdentityCredential.get_token failed: ManagedIdentityCredential authentication unavailable, no response from the IMDS endpoint.
SharedTokenCacheCredential.get_token failed: SharedTokenCacheCredential authentication unavailable. No accounts were found in the cache.
AzureCliCredential.get_token succeeded
[Authenticated account] Client ID: 00001111-aaaa-2222-bbbb-3333cccc4444. Tenant ID: aaaabbbb-0000-cccc-1111-dddd2222eeee. User Principal Name: unavailableUpn. Object ID (user): aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb
DefaultAzureCredential acquired a token from AzureCliCredential
V předchozím výstupu si všimněte, že:
EnvironmentCredential
,ManagedIdentityCredential
aSharedTokenCacheCredential
každý z nich se nepodařilo získat přístupový token Microsoft Entra v daném pořadí.- Volání
AzureCliCredential.get_token
proběhne úspěšně a výstup také indikuje, žeDefaultAzureCredential
získal token zAzureCliCredential
. Od té doby, coAzureCliCredential
bylo úspěšné, se nepoužily žádné přihlašovací údaje.
Poznámka:
V předchozím příkladu je úroveň protokolování nastavena na logging.DEBUG
. Při použití této úrovně protokolování buďte opatrní, protože může vypíše citlivé informace. V tomto případě například ID klienta, ID tenanta a ID objektu instančního objektu vývojáře v Azure. Všechny informace o zpětném trasování byly z výstupu odebrány, aby bylo jasné.