Udostępnij za pomocą

Uwierzytelnianie aplikacji hostowanych na platformie Azure do zasobów platformy Azure przy użyciu zestawu Azure SDK dla języka Python

Podczas hostowania aplikacji w Azure za pomocą usług takich jak Azure App Service, Azure Virtual Machines czy Azure Container Instances, zalecanym podejściem do uwierzytelnienia się aplikacji w zasobach Azure jest użycie tożsamości zarządzanej.

Tożsamość zarządzana zapewnia tożsamość aplikacji, tak aby mogła łączyć się z innymi zasobami platformy Azure bez konieczności używania klucza tajnego lub innego tajnego hasła aplikacji. Wewnętrznie platforma Azure zna tożsamość aplikacji i zasoby, z którymi może się łączyć. Azure używa tych informacji do automatycznego uzyskiwania tokenów Microsoft Entra dla aplikacji, aby umożliwić jej łączenie się z innymi zasobami Azure, wszystko bez konieczności zarządzania sekretami aplikacji.

Uwaga

Aplikacje działające w usłudze Azure Kubernetes Service (AKS) mogą używać tożsamości roboczej do uwierzytelniania się z zasobami platformy Azure. W usłudze AKS tożsamość zadania reprezentuje relację zaufania między tożsamością zarządzaną a kontem usługi Kubernetes. Jeśli aplikacja wdrożona w usłudze AKS jest skonfigurowana z kontem usługi Kubernetes w takim kontekście, DefaultAzureCredential uwierzytelnia aplikację w platformie Azure, korzystając z tożsamości zarządzanej. Uwierzytelnianie przy użyciu tożsamości obciążenia zostało omówione w Use Microsoft Entra Workload ID with Azure Kubernetes Service. Aby uzyskać instrukcje dotyczące konfigurowania tożsamości obciążenia, zobacz Wdrażanie i konfigurowanie tożsamości obciążenia w klastrze usługi Azure Kubernetes Service (AKS).

Typy zarządzanej tożsamości

Istnieją dwa typy tożsamości zarządzanych:

  • Tożsamości zarządzane przydzielane przez system — ten typ tożsamości zarządzanej jest dostarczany i powiązany bezpośrednio z zasobem Azure. Po włączeniu tożsamości zarządzanej w zasobie platformy Azure uzyskasz tożsamość zarządzaną przypisaną przez system dla tego zasobu. Tożsamość zarządzana przypisana przez system jest powiązana z cyklem życia skojarzonego z nim zasobu platformy Azure. Po usunięciu zasobu platforma Azure automatycznie usunie Twoją tożsamość. Ponieważ wszystko, co musisz zrobić, to włączyć tożsamość zarządzaną dla zasobu platformy Azure, na którym jest hostowany kod, to podejście jest najprostszym sposobem korzystania z tożsamości zarządzanej.
  • Zarządzane tożsamości przypisane przez użytkownika — można również utworzyć zarządzaną tożsamość jako autonomiczny zasób Azure. To podejście jest najczęściej używane, gdy rozwiązanie ma wiele obciążeń uruchamianych w wielu zasobach platformy Azure, które muszą współdzielić tę samą tożsamość i te same uprawnienia. Jeśli na przykład rozwiązanie zawiera składniki, które działają w wielu wystąpieniach usługi App Service i maszyn wirtualnych, które wymagają dostępu do tego samego zestawu zasobów platformy Azure, to tożsamość zarządzana przypisana przez użytkownika używana w tych zasobach ma sens.

W tym artykule opisano kroki włączania i używania tożsamości zarządzanej przypisanej przez system dla aplikacji. Jeśli musisz użyć tożsamości zarządzanej przypisanej przez użytkownika, zobacz artykuł Zarządzanie tożsamościami zarządzanymi przypisanymi przez użytkownika, aby zobaczyć, jak utworzyć tożsamość zarządzaną przypisaną przez użytkownika.

Włącz tożsamość zarządzaną w hostującym aplikację zasobie platformy Azure

Pierwszym krokiem jest włączenie tożsamości zarządzanej na zasobie Azure, na którym hostowana jest twoja aplikacja. Jeśli na przykład hostujesz aplikację Django przy użyciu usługi Azure App Service, musisz włączyć tożsamość zarządzaną dla aplikacji internetowej usługi App Service, która hostuje aplikację. Jeśli używasz maszyny wirtualnej do hostowania aplikacji, możesz zezwolić maszynie wirtualnej na korzystanie z tożsamości zarządzanej.

Tożsamość zarządzaną można włączyć dla zasobu platformy Azure przy użyciu portalu Azure lub Azure CLI.

Polecenia interfejsu wiersza polecenia platformy Azure można uruchamiać w usłudze Azure Cloud Shell lub na stacji roboczej z zainstalowanym Azure CLI.

Polecenia Azure CLI używane do włączania tożsamości zarządzanej dla zasobu platformy Azure mają postać az <command-group> identity --resource-group <resource-group-name> --name <resource-name>. Zobacz następujące polecenia dla popularnych usług platformy Azure.

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

Dane wyjściowe wyglądają następująco.

{
  "principalId": "aaaaaaaa-bbbb-cccc-1111-222222222222",
  "tenantId": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "type": "SystemAssigned",
  "userAssignedIdentities": null
}

Wartość principalId jest unikatowym identyfikatorem tożsamości zarządzanej. Zachowaj kopię tych danych wyjściowych, ponieważ będą one potrzebne w następnym kroku.

Przypisywanie ról do tożsamości zarządzanej

Następnie należy określić, jakich ról (uprawnień) potrzebuje twoja aplikacja, i przypisać tożsamość zarządzaną do tych ról na platformie Azure. Tożsamość zarządzana może mieć przypisane role w obrębie zasobu, grupy zasobów lub subskrypcji. W tym przykładzie pokazano, jak przypisywać role w zakresie grupy zasobów, ponieważ większość aplikacji grupuje wszystkie zasoby platformy Azure w jedną grupę zasobów.

Polecenie az role assignment create przypisuje rolę do tożsamości zarządzanej. Dla przypisanego użyj principalId skopiowanego w kroku 1.

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

Aby uzyskać nazwy ról, które można przypisać zasadniczej usłudze, użyj polecenia az role definition list.

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

Aby na przykład zezwolić tożsamości zarządzanej z identyfikatorem aaaaaaaa-bbbb-cccc-1111-222222222222 na odczyt, zapis i usuwanie dostępu do kontenerów obiektów blob usługi Azure Storage i danych we wszystkich kontach magazynu w grupie zasobów msdocs-python-sdk-auth-example w subskrypcji o identyfikatorze aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e, należy przypisać aplikacyjne konto usługi do roli Współautor danych obiektu blob usługi Storage używając następującego polecenia.

az role assignment create --assignee aaaaaaaa-bbbb-cccc-1111-222222222222 \
    --scope /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/msdocs-python-sdk-auth-example \
    --role "Storage Blob Data Contributor"

Aby uzyskać informacje na temat przypisywania uprawnień na poziomie zasobu lub subskrypcji przy użyciu interfejsu wiersza polecenia platformy Azure, zobacz artykuł Przypisywanie ról platformy Azure przy użyciu interfejsu wiersza polecenia platformy Azure.

Implementacja DefaultAzureCredential w aplikacji

Gdy kod jest uruchomiony na platformie Azure, a tożsamość zarządzana jest włączona w zasobie platformy Azure hostowanym przez aplikację, DefaultAzureCredential określa poświadczenia do użycia w następującej kolejności:

  1. Sprawdź środowisko dla jednostki usługi zdefiniowanej przez zmienne środowiskowe AZURE_CLIENT_ID, AZURE_TENANT_ID, oraz AZURE_CLIENT_SECRET lub AZURE_CLIENT_CERTIFICATE_PATH, a opcjonalnie AZURE_CLIENT_CERTIFICATE_PASSWORD.
  2. Sprawdź parametry słów kluczowych dla przypisanej przez użytkownika tożsamości zarządzanej. Możesz podać tożsamość zarządzaną przez użytkownika, określając jej identyfikator klienta w parametrze managed_identity_client_id.
  3. Sprawdź zmienną AZURE_CLIENT_ID środowiskową pod kątem identyfikatora klienta tożsamości zarządzanej przypisanej przez użytkownika.
  4. Jeśli tożsamość zarządzana jest włączona w zasobie platformy Azure, użyj przypisanej przez system tożsamości zarządzanej.

Tożsamości zarządzane można wykluczyć z poświadczeń, ustawiając parametr słowa kluczowego exclude_managed_identity_credentialTrue.

W tym artykule jest używana tożsamość zarządzana przypisana przez system dla aplikacji internetowej usługi Azure App Service. Korzystając z tego podejścia, nie musisz konfigurować tożsamości zarządzanej w środowisku ani przekazywać jej jako parametru. W poniższych krokach pokazano, jak używać polecenia DefaultAzureCredential.

Najpierw dodaj azure.identity pakiet do aplikacji.

pip install azure-identity

Następnie dla dowolnego kodu w języku Python, który tworzy obiekt klienta zestawu Azure SDK w aplikacji:

  1. Zaimportuj klasę DefaultAzureCredential z modułu azure.identity .
  2. Utwórz DefaultAzureCredential obiekt.
  3. Przekaż obiekt DefaultAzureCredential do konstruktora obiektu klienta zestawu SDK Azure.

Przykład tych kroków przedstawiono w następującym segmencie kodu.

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 opisano w artykule Omówienie uwierzytelniania zestawu Azure SDK dla języka Python, DefaultAzureCredential obsługuje wiele metod uwierzytelniania i określa metodę uwierzytelniania używaną w czasie wykonywania. Zaletą tego podejścia jest to, że aplikacja może używać różnych metod uwierzytelniania w różnych środowiskach bez implementowania kodu specyficznego dla środowiska. Gdy powyższy kod jest uruchamiany na stacji roboczej w lokalnym środowisku deweloperskim, DefaultAzureCredential używa jednostki usługi aplikacji określonej przez ustawienia środowiska lub poświadczeń narzędzi deweloperskich do uwierzytelniania się z innymi zasobami platformy Azure. W związku z tym ten sam kod może służyć do uwierzytelniania aplikacji w zasobach platformy Azure zarówno podczas programowania lokalnego, jak i podczas wdrażania na platformie Azure.

  • Last updated on