Ověřování aplikací v Pythonu ve službách Azure pomocí sady Azure SDK pro Python
Když 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. Klientská knihovna Azure Identity pro Python poskytuje třídy, které podporují ověřování na základě tokenů a umožňují aplikacím bezproblémově ověřovat prostředky 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
DefaultAzureCredential třída poskytovaná klientskou knihovnou Azure Identity 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 za vás získá a spravuje tokeny Microsoft Entra. Díky tomu se ověřování založené na tokenech snadno používá 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 klientské knihovně azure Identity vždy preferují při ověřování prostředků 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
DefaultAzureCredential je názorná a uspořádaná posloupnost mechanismů pro ověřování v Microsoft Entra ID. Každý mechanismus ověřování je třída, která implementuje tokenCredential protokol a označuje se jako přihlašovací údaje. Za běhu DefaultAzureCredential se pokusí ověřit pomocí prvních přihlašovacích údajů. 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á. Aplikace tak může používat různé přihlašovací údaje v různých prostředích bez psaní kódu specifického pro prostředí.
Pokud chcete použít DefaultAzureCredential v aplikaci v Pythonu, přidejte do aplikace balíček azure-identity .
pip install azure-identity
Ke službám Azure se přistupuje pomocí specializovaných klientských tříd z různých klientských knihoven Azure SDK. 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)
Když předchozí kód běží na místní vývojové pracovní stanici, vyhledá v proměnných prostředí instanční objekt aplikace nebo v místně nainstalovaných vývojářských nástrojích, jako je Azure CLI, pro sadu přihlašovacích údajů vývojáře. K ověření aplikace v prostředcích Azure se dá použít některý z přístupů během místního vývoje.
Při nasazení do Azure může stejný kód také ověřit vaši aplikaci v prostředcích Azure. DefaultAzureCredential může načíst nastavení prostředí a konfigurace spravovaných identit pro automatické ověřování ve službách Azure.