共用方式為

使用適用於 Python 的 Azure SDK 向 Azure 服務驗證 Python 應用程式

  • 發行項

當應用程式需要存取 Azure 資源，例如 Azure 儲存體、Azure 金鑰保存庫 或 Azure AI 服務時，應用程式必須向 Azure 進行驗證。 無論是部署至 Azure、部署在內部部署還是開發於本機開發人員工作站上，所有應用程式的需求都是如此。 本文說明當您使用適用於 Python 的 Azure SDK 時，向 Azure 驗證應用程式的建議方法。

對 Azure 資源進行驗證時，請使用令牌型驗證，而不是針對您的應用程式 連接字串。 適用於 Python 的 Azure 身分識別用戶端連結庫提供支援令牌型驗證的類別，並允許應用程式順暢地向 Azure 資源進行驗證，無論是在本機開發中、部署至 Azure，還是部署到內部部署伺服器。

應用程式用來向 Azure 資源驗證的特定令牌型驗證類型取決於應用程式執行的位置。 下圖顯示令牌型驗證的類型。

此圖顯示應用程式的建議令牌型驗證策略，視應用程式執行位置而定。

  • 當開發人員在本機開發期間執行應用程式時： 應用程式會使用應用程式服務主體進行本機開發或開發人員的 Azure 認證，向 Azure 進行驗證。 這些選項會在本機開發期間驗證一節中討論。
  • 在 Azure 上裝載應用程式時： 應用程式會使用受控識別向 Azure 資源進行驗證。 此選項會在伺服器環境中的驗證一節中討論。
  • 當應用程式裝載並部署於內部部署時： 應用程式會使用應用程式服務主體向 Azure 資源進行驗證。 此選項會在伺服器環境中的驗證一節中討論。

DefaultAzureCredential

Azure 身分識別客戶端連結庫所提供的 DefaultAzureCredential 類別可讓應用程式根據執行所在的環境使用不同的驗證方法。 如此一來，應用程式就可以從本機開發升級至測試環境，而不需變更程序代碼。

您可以為每個環境設定適當的驗證方法，並 DefaultAzureCredential 自動偵測並使用該驗證方法。 使用 DefaultAzureCredential 優先於手動編碼條件式邏輯或功能旗標，以在不同的環境中使用不同的驗證方法。

關於使用 DefaultAzureCredential 類別的詳細數據，請參閱在應用程式中使用DefaultAzureCredential一節中討論。

權杖型驗證的優點

當您建置 Azure 應用程式時，請使用令牌型驗證，而不是使用 連接字串。 令牌型驗證提供下列優點，比使用 連接字串 進行驗證：

  • 本文所述的令牌型驗證方法可讓您在 Azure 資源上建立應用程式所需的特定許可權。 這種做法遵循 最低許可權原則。 反之，連接字串會授與完整權限給 Azure 資源。
  • 具有 連接字串 的任何人或任何應用程式都可以連線到 Azure 資源，但令牌型驗證方法會將資源的存取範圍限定為只想要存取資源的應用程式。
  • 使用受控識別時，沒有應用程式秘密可儲存。 應用程式更安全，因為沒有 連接字串 或應用程式秘密可能會遭到入侵。
  • azure 身分識別套件會為您取得和管理Microsoft Entra 令牌。 這讓使用令牌型驗證變得容易做為 連接字串。

將 連接字串的使用限制為無法存取生產或敏感數據的初始概念證明應用程式或開發原型。 否則，在向 Azure 資源進行驗證時，Azure 身分識別用戶端連結庫中提供的令牌型驗證類別一律是慣用的。

伺服器環境中的驗證

當您在伺服器環境中裝載時，每個應用程式都會為每個執行應用程式的環境指派唯 一的應用程式身分 識別。 在 Azure 中，應用程式身分識別是由 服務主體表示。 這種特殊的安全性主體類型可識別及驗證應用程式至 Azure。 應用程式要使用的服務主體類型取決於您的應用程式執行位置：

驗證方法 描述
Azure 裝載的應用程式 裝載在 Azure 中的應用程式應該使用 受控識別服務主體。 受控識別的設計目的是代表裝載在 Azure 中的應用程式身分識別，且只能與 Azure 裝載的應用程式搭配使用。

例如，裝載於 Azure App 服務 的 Django Web 應用程式會指派受控識別。 指派給應用程式的受控識別接著會用來向其他 Azure 服務驗證應用程式。

在 Azure Kubernetes Service 中執行的應用程式可以使用工作負載身分識別認證。 此認證是以與 AKS 服務帳戶有信任關係的受控識別為基礎。
,

了解 Azure 裝載應用程式的驗證
Azure 外部裝載的應用程式
（例如，內部部署應用程式）		 裝載於 Azure 外部的應用程式（例如，內部部署應用程式）需要連線到 Azure 服務的應用程式應該使用 應用程式服務主體。 應用程式服務主體代表 Azure 中應用程式的身分識別，並透過應用程式註冊程式建立。

例如，假設裝載於內部部署的 Django Web 應用程式會使用 Azure Blob 儲存體。 您將使用應用程式註冊程式，為應用程式建立應用程式服務主體。 AZURE_CLIENT_ID、 AZURE_TENANT_ID和 AZURE_CLIENT_SECRET 全都會儲存為環境變數，以便應用程式在運行時間讀取，並允許應用程式使用應用程式服務主體向 Azure 進行驗證。

了解 Azure 外部裝載的應用程式驗證

本機開發期間的驗證

當應用程式在本機開發期間於開發人員的工作站上執行時，它仍必須向應用程式使用的任何 Azure 服務進行驗證。 在本機開發期間，向 Azure 驗證應用程式有兩個主要策略：

驗證方法 描述
建立專用的應用程式服務主體物件，以在本機開發期間使用。 在此方法中，專用 的應用程式服務主體 物件是使用應用程式註冊程式來設定，以在本機開發期間使用。 服務主體的身分識別接著會儲存為應用程式在本機開發中執行時要存取的環境變數。

透過此方法，您可將應用程式所需的特定資源權限指派給開發人員在本機開發期間使用的服務主體物件。 這種做法可確保應用程式只能存取它所需的特定資源，並復寫應用程式在生產環境中將擁有的許可權。

此方法的缺點是需要為每個在應用程式上工作的開發人員建立個別的服務主體物件。

瞭解使用開發人員服務主體進行驗證
在本機開發期間，使用開發人員的認證向 Azure 驗證應用程式。 在此方法中，開發人員必須在其本機工作站上，從 Azure CLI、Azure PowerShell 或 Azure 開發人員 CLI 登入 Azure。 該應用程式便可從認證存放區存取開發人員的認證，並使用這些認證存取 Azure 資源。

此方法的優點是更容易設定，因為開發人員只需要透過上述其中一個開發人員工具登入其 Azure 帳戶。 此方法的缺點是，開發人員帳戶具備的權限可能比應用程式所需的更多。 因此，應用程式不會準確地復寫在生產環境中執行的許可權。

瞭解如何使用開發人員帳戶進行驗證

使用應用程式中的 DefaultAzureCredential

DefaultAzureCredential 是一種有意見、已排序的機制序列，用於驗證至Microsoft Entra ID。 每個驗證機制都是實作 TokenCredential 通訊協議的類別，稱為 認證。 在執行階段中，DefaultAzureCredential 會嘗試使用第一個認證進行驗證。 如果該認證無法取得存取權杖，則會嘗試序列中的下一個認證，以此類推，直到成功取得存取權杖為止。 因此，您的應用程式可以在相異環境中使用不同的認證，而不需要撰寫環境特定程式碼。

若要在 Python 應用程式中使用DefaultAzureCredential，請將 azure-identity 套件新增至您的應用程式。

pip install azure-identity

使用來自各種 Azure SDK 用戶端程式庫的特殊用戶端類別以存取 Azure 服務。 下列程式代碼範例示範如何具現化 DefaultAzureCredential 物件，並將其與 Azure SDK 用戶端類別搭配使用。 在此情況下，它是BlobServiceClient用來存取 Azure Blob 儲存體 的物件。

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)

當上述程式代碼在本機開發工作站上執行時，它會在應用程式服務主體的環境變數中，或在本機安裝的開發人員工具，例如 Azure CLI 中尋找一組開發人員認證。 在本機開發期間，您可以使用任一方法向 Azure 資源驗證應用程式。

部署至 Azure 時，此相同程式代碼也可以向 Azure 資源驗證您的應用程式。 DefaultAzureCredential 可以擷取環境設定和受控識別組態，以自動向 Azure 服務進行驗證。

相關內容