Ověřování aplikací v Pythonu ve službách Azure pomocí sady Azure SDK pro Python
Pokud aplikace potřebuje přístup k prostředku Azure, jako je Azure Storage, Azure Key Vault nebo služby Azure AI, musí se aplikace ověřit v Azure. Tento požadavek platí pro všechny aplikace, ať už jsou nasazené v Azure, nasazené místně nebo ve vývoji na místní vývojářské pracovní stanici. Tento článek popisuje doporučené přístupy k ověřování aplikace v Azure při použití sady Azure SDK pro Python.
Doporučený přístup k ověřování aplikací
Při ověřování prostředků Azure místo připojovací řetězec pro vaše aplikace používejte ověřování založené na tokenech. Sada Azure SDK pro Python poskytuje třídy, které podporují ověřování založené na tokenech. Aplikace se můžou bez problémů ověřovat u prostředků Azure bez ohledu na to, jestli je aplikace v místním vývoji, nasazená v Azure nebo nasazená na místním serveru.
Konkrétní typ ověřování na základě tokenů, který aplikace používá k ověření prostředků Azure, závisí na tom, kde se aplikace spouští. Typy ověřování založeného na tokenech jsou znázorněny v následujícím diagramu.
- Když vývojář spouští aplikaci během místního vývoje: Aplikace se ověří v Azure pomocí instančního objektu aplikace pro místní vývoj nebo přihlašovacích údajů Azure vývojáře. Tyto možnosti jsou popsány v části Ověřování během místního vývoje.
- Když je aplikace hostovaná v Azure: Aplikace se ověřuje u prostředků Azure pomocí spravované identity. Tato možnost je popsána v části Ověřování v serverových prostředích.
- Když je aplikace hostovaná a nasazená místně: Aplikace se ověřuje u prostředků Azure pomocí instančního objektu aplikace. Tato možnost je popsána v části Ověřování v serverových prostředích.
DefaultAzureCredential
Třída DefaultAzureCredential poskytovaná sadou Azure SDK umožňuje aplikacím používat různé metody ověřování v závislosti na prostředí, ve kterém se spouští. Tímto způsobem je možné zvýšit úroveň aplikací z místního vývoje na testovací prostředí do produkčního prostředí beze změn kódu.
Nakonfigurujete odpovídající metodu ověřování pro každé prostředí a DefaultAzureCredential automaticky zjistí a použije tuto metodu ověřování. Použití DefaultAzureCredential je upřednostňované před ručním kódováním podmíněné logiky nebo příznaků funkcí pro použití různých metod ověřování v různých prostředích.
Podrobnosti o použití DefaultAzureCredential třídy jsou popsány v části Použití DefaultAzureCredential v aplikaci.
Výhody ověřování založeného na tokenech
Při vytváření aplikací pro Azure používejte ověřování založené na tokenech místo použití připojovací řetězec. Ověřování na základě tokenů nabízí následující výhody oproti ověřování pomocí připojovací řetězec:
- Metody ověřování založené na tokenech popsané v tomto článku umožňují vytvořit konkrétní oprávnění potřebná aplikací v prostředku Azure. Tento postup se řídí principem nejnižšího oprávnění. Naproti tomu připojovací řetězec uděluje úplná práva k prostředku Azure.
- Kdokoli nebo jakákoli aplikace s připojovací řetězec se může připojit k prostředku Azure, ale metody ověřování založené na tokenech umožňují přístup k prostředku jenom aplikacím určeným pro přístup k prostředku.
- U spravované identity neexistuje žádný tajný kód aplikace, který se má uložit. Aplikace je bezpečnější, protože neexistuje žádný připojovací řetězec ani tajný kód aplikace, který by se mohl ohrozit.
- Balíček azure.identity v sadě Azure SDK spravuje tokeny za vás na pozadí. Spravované tokeny usnadňují použití ověřování na základě tokenů jako připojovací řetězec.
Omezte použití připojovací řetězec na počáteční prototypy testování konceptu nebo prototypů vývoje, které nepřistupují k produkčním nebo citlivým datům. V opačném případě se třídy ověřování založené na tokenech dostupné v sadě Azure SDK vždy preferují, když se ověřují v prostředcích Azure.
Ověřování v serverových prostředích
Když hostujete v serverovém prostředí, každé aplikaci se přiřadí jedinečná identita aplikace pro každé prostředí, ve kterém se aplikace spouští. V Azure je identita aplikace reprezentována instančním objektem. Tento speciální typ objektu zabezpečení identifikuje a ověřuje aplikace v Azure. Typ instančního objektu, který se má použít pro vaši aplikaci, závisí na tom, kde je vaše aplikace spuštěná:
| Metoda ověřování | Popis |
|---|---|
| Aplikace hostované v Azure | Aplikace hostované v Azure by měly používat instanční objekt spravované identity. Spravované identity jsou navržené tak, aby představovaly identitu aplikace hostované v Azure a dají se používat jenom s aplikacemi hostovanými v Azure. Například webová aplikace Django hostovaná ve službě Aplikace Azure Service by byla přiřazena spravovaná identita. Spravovaná identita přiřazená aplikaci by se pak použila k ověření aplikace v jiných službách Azure. Aplikace spuštěné ve službě Azure Kubernetes Service (AKS) můžou používat přihlašovací údaje identity úloh. Tyto přihlašovací údaje jsou založené na spravované identitě, která má vztah důvěryhodnosti s účtem služby AKS. , |
| Aplikace hostované mimo Azure (například místní aplikace) |
Aplikace hostované mimo Azure (například místní aplikace), které se potřebují připojit ke službám Azure, by měly používat instanční objekt aplikace. Instanční objekt aplikace představuje identitu aplikace v Azure a vytvoří se prostřednictvím procesu registrace aplikace. Představte si například webovou aplikaci Django hostované místně, která využívá službu Azure Blob Storage. Pomocí procesu registrace aplikace byste pro aplikaci vytvořili instanční objekt aplikace. A AZURE_CLIENT_IDAZURE_TENANT_IDAZURE_CLIENT_SECRET všechny by byly uloženy jako proměnné prostředí, které aplikace musí číst za běhu a umožnit aplikaci ověřit v Azure pomocí instančního objektu aplikace. |
Ověřování během místního vývoje
Když aplikace běží na pracovní stanici vývojáře během místního vývoje, musí se stále ověřovat ve všech službách Azure, které aplikace používá. Při místním vývoji existují dvě hlavní strategie ověřování aplikací v Azure:
| Metoda ověřování | Popis |
|---|---|
| Vytvořte vyhrazené objekty instančního objektu aplikace, které se použijí při místním vývoji. | V této metodě jsou vyhrazené objekty instančního objektu aplikace nastaveny pomocí procesu registrace aplikace pro použití během místního vývoje. Identita instančního objektu se pak uloží jako proměnné prostředí, ke které má aplikace přistupovat, když se spustí v místním vývoji. Tato metoda umožňuje přiřadit konkrétní oprávnění k prostředkům potřebným aplikací k objektům instančního objektu, které používají vývojáři během místního vývoje. Tento postup zajistí, že aplikace má přístup jenom ke konkrétním prostředkům, které potřebuje, a replikuje oprávnění, která bude aplikace mít v produkčním prostředí. Nevýhodou tohoto přístupu je nutnost vytvořit samostatné objekty instančního objektu pro každého vývojáře, který pracuje na aplikaci. |
| Ověřte aplikaci v Azure pomocí přihlašovacích údajů vývojáře během místního vývoje. | V této metodě musí být vývojář přihlášený k Azure z Azure CLI, Azure PowerShellu nebo Azure Developer CLI na místní pracovní stanici. Aplikace pak může přistupovat k přihlašovacím údajům vývojáře z úložiště přihlašovacích údajů a pomocí těchto přihlašovacích údajů získat přístup k prostředkům Azure z aplikace. Tato metoda má výhodu jednoduššího nastavení, protože vývojář se musí přihlásit ke svému účtu Azure jenom prostřednictvím některého z výše uvedených vývojářských nástrojů. Nevýhodou tohoto přístupu je, že účet vývojáře má pravděpodobně více oprávnění, než vyžaduje aplikace. V důsledku toho aplikace přesně nereplikuje oprávnění, která bude spouštět v produkčním prostředí. |
Použití DefaultAzureCredential v aplikaci
Pokud chcete použít DefaultAzureCredential v aplikaci v Pythonu, přidejte do své aplikace balíček azure.identity .
pip install azure-identity
Následující příklad kódu ukazuje, jak vytvořit instanci objektu DefaultAzureCredential a použít ho s klientskou třídou sady Azure SDK. V tomto případě se jedná o objekt používaný pro přístup ke službě BlobServiceClient Azure Blob Storage.
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)
Objekt DefaultAzureCredential automaticky rozpozná ověřovací mechanismus nakonfigurovaný pro aplikaci a získá potřebné tokeny pro ověření aplikace v Azure. Pokud aplikace používá více než jednoho klienta sady SDK, můžete použít stejný objekt přihlašovacích údajů s každým objektem klienta sady SDK.
Posloupnost metod ověřování při použití DefaultAzureCredential
Interně DefaultAzureCredential implementuje řetězec zprostředkovatelů přihlašovacích údajů pro ověřování aplikací v prostředcích Azure. Každý zprostředkovatel přihlašovacích údajů může zjistit, jestli jsou pro aplikaci nakonfigurované přihlašovací údaje daného typu. Objekt DefaultAzureCredential postupně kontroluje každého zprostředkovatele v pořadí a používá přihlašovací údaje od prvního zprostředkovatele, který má nakonfigurované přihlašovací údaje.
Pořadí, ve kterém DefaultAzureCredential hledá přihlašovací údaje, se zobrazuje v následujícím diagramu a tabulce:
| Typ přihlašovacích údajů | Popis |
|---|---|
| Prostředí | Objekt DefaultAzureCredential načte sadu proměnných prostředí, aby určil, jestli byl pro aplikaci nastavený 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ýchprostředích |
| Identita úloh | V Azure Kubernetes Service (AKS) představuje identita úlohy vztah důvěryhodnosti mezi spravovanou identitou a účtem služby Kubernetes. Pokud je aplikace nasazená do AKS nakonfigurovaná s účtem služby Kubernetes v takové relaci, DefaultAzureCredential ověří aplikaci v Azure pomocí spravované identity. Ověřování pomocí identity úlohy je popsáno v tématu Použití ID úloh Microsoft Entra se službou Azure Kubernetes Service. |
| Spravovaná identita | Pokud je aplikace nasazená na hostitele Azure s povolenou spravovanou identitou, DefaultAzureCredential ověří ji v Azure pomocí této spravované identity. Ověřování pomocí spravované identity je popsáno v části Ověřování v serverových prostředích.Tato metoda je dostupná jenom v případě, že je aplikace hostovaná v Azure pomocí služby, jako je služba Aplikace Azure Service, Azure Functions nebo Azure Virtual Machines. |
| Azure CLI | Pokud jste se ověřili v Azure pomocí az login příkazu v Azure CLI, DefaultAzureCredential ověří aplikaci v Azure pomocí stejného účtu. |
| Azure PowerShell | Pokud jste se ověřili v Azure pomocí rutiny Connect-AzAccount z Azure PowerShellu, DefaultAzureCredential ověří aplikaci do Azure pomocí stejného účtu. |
| Azure Developer CLI | Pokud jste se ověřili v Azure pomocí azd auth login příkazu v Azure Developer CLI, DefaultAzureCredential ověří aplikaci v Azure pomocí stejného účtu. |
| Interaktivní | Pokud je tato možnost povolená, DefaultAzureCredential interaktivně vás ověřuje prostřednictvím výchozího prohlížeče aktuálního systému. Ve výchozím nastavení je tato možnost zakázaná. |
Poznámka:
Kvůli známému problémuVisualStudioCodeCredential se odebral z řetězu DefaultAzureCredential tokenů. Po vyřešení problému v budoucí verzi se tato změna vrátí. Další informace najdete v klientské knihovně Azure Identity pro Python.