Ověřování aplikací hostovaných v Azure v prostředcích Azure pomocí sady Azure SDK pro Python

Když hostujete aplikaci v Azure pomocí služeb, jako jsou Aplikace Azure Service, Azure Virtual Machines nebo Azure Container Instances, doporučuje se ověřit aplikaci v prostředcích Azure se spravovanou identitou.

Spravovaná identita poskytuje identitu pro vaši aplikaci, aby se dokázala připojit k jiným prostředkům Azure bez nutnosti používat tajný klíč nebo jiný tajný klíč aplikace. Azure interně zná identitu vaší aplikace a prostředky, ke které se může připojit. Azure tyto informace používá k automatickému získání tokenů Microsoft Entra pro aplikaci, aby se mohla připojit k dalším prostředkům Azure, aniž byste museli spravovat tajné kódy aplikací.

Typy spravovaných identit

Existují dva typy spravovaných identit:

  • Spravované identity přiřazené systémem – Tento typ spravované identity je poskytován a svázán přímo s prostředkem Azure. Když povolíte spravovanou identitu u prostředku Azure, získáte spravovanou identitu přiřazenou systémem pro tento prostředek. Spravovaná identita přiřazená systémem je svázaná s životním cyklem prostředku Azure, ke kterému je přidružená. Když se prostředek odstraní, Azure automaticky odstraní identitu za vás. Vzhledem k tomu, že stačí povolit spravovanou identitu pro prostředek Azure hostující váš kód, je tento přístup nejjednodušším typem spravované identity, která se má použít.
  • Spravované identity přiřazené uživatelem – Spravovanou identitu můžete vytvořit také jako samostatný prostředek Azure. Tento přístup se nejčastěji používá, když má vaše řešení více úloh, které běží na několika prostředcích Azure, které potřebují sdílet stejnou identitu a stejná oprávnění. Pokud například vaše řešení obsahovalo komponenty, které běží na několika instancích služby App Service a virtuálních počítačů, které potřebují přístup ke stejné sadě prostředků Azure, pak dává smysl spravovaná identita přiřazená uživatelem, která se v těchto prostředcích používá.

Tento článek popisuje postup povolení a použití spravované identity přiřazené systémem pro aplikaci. Pokud potřebujete použít spravovanou identitu přiřazenou uživatelem, přečtěte si článek Správa spravovaných identit přiřazených uživatelem a zjistěte, jak vytvořit spravovanou identitu přiřazenou uživatelem.

1. Povolení spravované identity v prostředku Azure hostujícím aplikaci

Prvním krokem je povolení spravované identity na prostředku Azure hostujícím vaši aplikaci. Pokud například hostujete aplikaci Django pomocí služby Aplikace Azure Service, musíte pro webovou aplikaci App Service, která hostuje vaši aplikaci, povolit spravovanou identitu. Pokud k hostování aplikace používáte virtuální počítač, povolili byste virtuálnímu počítači používat spravovanou identitu.

Spravovanou identitu můžete povolit pro prostředek Azure pomocí webu Azure Portal nebo Azure CLI.

Příkazy Azure CLI je možné spouštět v Azure Cloud Shellu nebo na pracovní stanici s nainstalovaným Azure CLI.

Příkazy Azure CLI, které slouží k povolení spravované identity pro prostředek Azure, jsou ve formuláři az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Níže jsou uvedeny konkrétní příkazy pro oblíbené služby Azure.

az webapp identity assign --resource-group <resource-group-name> -name <web-app-name>

Výstup bude vypadat následovně.

{
  "principalId": "99999999-9999-9999-9999-999999999999",
  "tenantId": "33333333-3333-3333-3333-333333333333",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

Hodnota principalId je jedinečné ID spravované identity. Ponechte kopii tohoto výstupu, protože tyto hodnoty budete potřebovat v dalším kroku.

2. Přiřazení rolí ke spravované identitě

Dále musíte určit, jaké role (oprávnění) vaše aplikace potřebuje, a přiřadit spravovanou identitu těmto rolím v Azure. Spravovanou identitu je možné přiřadit role v oboru prostředku, skupiny prostředků nebo předplatného. Tento příklad ukazuje, jak přiřadit role v oboru skupiny prostředků, protože většina aplikací seskupuje všechny prostředky Azure do jedné skupiny prostředků.

Spravovaná identita má přiřazenou roli v Azure pomocí příkazu az role assignment create . Pro přiřazeného uživatele použijte principalId zkopírované v kroku 1.

az role assignment create --assignee {managedIdentityprincipalId} \
    --scope /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} \
    --role "{roleName}" 

Pokud chcete získat názvy rolí, ke kterým je možné instanční objekt přiřadit, použijte příkaz az role definition list .

az role definition list \
    --query "sort_by([].{roleName:roleName, description:description}, &roleName)" \
    --output table

Pokud chcete například povolit spravovanou identitu s ID 99999999-9999-9999-9999-999999999999 čtení, zápisu a odstranění přístupu ke kontejnerům objektů blob služby Azure Storage a datům ve všech účtech úložiště ve skupině prostředků msdocs-python-sdk-auth-example v předplatném s ID 11111111-1111-1111-1111-111111111111, přiřadili byste instanční objekt aplikace k roli Přispěvatel dat objektů blob služby Storage pomocí následujícího příkazu.

az role assignment create --assignee 99999999-9999-9999-9999-999999999999 \
    --scope /subscriptions/11111111-1111-1111-1111-111111111111/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

Informace o přiřazování oprávnění na úrovni prostředku nebo předplatného pomocí Azure CLI najdete v článku Přiřazení rolí Azure pomocí Azure CLI.

3. Implementace defaultAzureCredential ve vaší aplikaci

Když je váš kód spuštěný v Azure a spravovaná identita je povolená na prostředku Azure hostujícím vaši aplikaci, určuje přihlašovací údaje, DefaultAzureCredential které se mají použít v následujícím pořadí:

  1. Zkontrolujte prostředí instančního objektu definovaného proměnnými AZURE_CLIENT_IDprostředí , AZURE_TENANT_IDa to buď AZURE_CLIENT_SECRET nebo AZURE_CLIENT_CERTIFICATE_PATH (volitelně) AZURE_CLIENT_CERTIFICATE_PASSWORD.
  2. Zkontrolujte parametry klíčových slov pro spravovanou identitu přiřazenou uživatelem. Spravovanou identitu přiřazenou uživatelem můžete předat zadáním ID klienta v parametru managed_identity_client_id .
  3. Zkontrolujte proměnnou AZURE_CLIENT_ID prostředí pro ID klienta spravované identity přiřazené uživatelem.
  4. Pokud je povolená, použijte spravovanou identitu přiřazenou systémem pro prostředek Azure.

Spravované identity můžete z přihlašovacích údajů vyloučit nastavením parametru Trueklíčového exclude_managed_identity_credential slova .

V tomto článku používáme spravovanou identitu přiřazenou systémem pro webovou aplikaci Aplikace Azure Service, takže nemusíme konfigurovat spravovanou identitu v prostředí ani ji předávat jako parametr. Následující kroky ukazují, jak používat DefaultAzureCredential.

Nejprve přidejte azure.identity balíček do aplikace.

pip install azure-identity

V dalším kroku pro libovolný kód Pythonu, který ve vaší aplikaci vytvoří objekt klienta sady Azure SDK, budete chtít:

  1. Naimportujte třídu DefaultAzureCredential z azure.identity modulu.
  2. Vytvoření objektu DefaultAzureCredential
  3. DefaultAzureCredential Předejte objekt konstruktoru klientského objektu sady Azure SDK.

Příklad těchto kroků je znázorněn v následujícím segmentu kódu.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

# Acquire a credential object
token_credential = DefaultAzureCredential()

blob_service_client = BlobServiceClient(
        account_url="https://<my_account_name>.blob.core.windows.net",
        credential=token_credential)

Jak je popsáno v článku s přehledem ověřování v sadě Azure SDK pro Python, DefaultAzureCredential podporuje více metod ověřování a určuje metodu ověřování, která se používá za běhu. Výhodou tohoto přístupu je, že vaše aplikace může používat různé metody ověřování v různých prostředích bez implementace kódu specifického pro prostředí. Pokud se předchozí kód spustí na pracovní stanici během místního vývoje, DefaultAzureCredential použije instanční objekt aplikace určený nastavením prostředí nebo přihlašovací údaje vývojářského nástroje k ověření s jinými prostředky Azure. Stejný kód se tedy dá použít k ověření aplikace v prostředcích Azure během místního vývoje i při nasazení do Azure.