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

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

建議的應用程式驗證方法

對 Azure 資源進行驗證時，請使用令牌型驗證，而不是針對您的應用程式 連接字串。 適用於 Python 的 Azure SDK 提供支援令牌型驗證的類別。 無論應用程式是在本機開發中、部署至 Azure 或部署至內部部署伺服器，應用程式都可以順暢地向 Azure 資源進行驗證。

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

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

DefaultAzureCredential

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

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

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

權杖型驗證的優點

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

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

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

伺服器環境中的驗證

當您在伺服器環境中裝載時，每個應用程式都會為每個執行應用程式的環境指派唯 一的應用程式身分 識別。 在 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

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

pip install azure-identity

下列程式代碼範例示範如何具現化 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)

物件 DefaultAzureCredential 會自動偵測為應用程式設定的驗證機制，並取得向 Azure 驗證應用程式所需的令牌。 如果應用程式使用多個 SDK 用戶端，您可以搭配每個 SDK 用戶端物件使用相同的認證物件。

當您使用 DefaultAzureCredential 時，驗證方法的順序

在內部，DefaultAzureCredential 會實作認證提供者鏈結，向 Azure 資源驗證應用程式。 每個認證提供者都可以偵測是否已針對應用程式設定該類型的認證。 物件 DefaultAzureCredential 會依序檢查每個提供者的順序，並使用已設定認證之第一個提供者的認證。

下圖和表格顯示尋找認證的順序 DefaultAzureCredential ：

認證類型	描述
Environment	物件 DefaultAzureCredential 會讀取一組環境變數，以判斷是否已為應用程式設定應用程式服務主體（應用程式使用者）。 如是，DefaultAzureCredential 則會使用這些值向 Azure 驗證應用程式。 此方法最常用於伺服器環境，但您也可以在本機開發時使用它。
工作負載身分識別	如果應用程式部署至已啟用 DefaultAzureCredential 受控識別的 Azure Kubernetes Service （AKS），請使用該受控識別向 Azure 驗證應用程式。 工作負載身分識別代表使用者指派的受控識別與AKS服務帳戶之間的信任關聯性。 使用工作負載身分識別的驗證會在 AKS 一文中討論搭配 Azure Kubernetes Service 使用 Microsoft Entra 工作負載 ID。
受控識別	如果應用程式部署至已啟用受控識別的 Azure 主機， DefaultAzureCredential 請使用該受控識別向 Azure 驗證應用程式。 使用受控識別的驗證會在伺服器環境中的驗證一節中討論。 只有在應用程式裝載於 Azure 時，才能使用 Azure App 服務、Azure Functions 或 Azure 虛擬機器 等服務來使用此方法。
Azure CLI	如果您已使用 az login Azure CLI 中的 命令向 Azure 進行驗證， DefaultAzureCredential 請使用相同的帳戶向 Azure 驗證應用程式。
Azure PowerShell	如果您已使用來自 Azure PowerShell 的 Connect-AzAccount Cmdlet 向 Azure 進行驗證， DefaultAzureCredential 請使用相同的帳戶向 Azure 驗證應用程式。
Azure 開發人員 CLI	如果您已使用 azd auth login Azure 開發人員 CLI 中的 命令向 Azure 進行驗證， DefaultAzureCredential 請使用相同的帳戶向 Azure 驗證應用程式。
互動式	如果已啟用， DefaultAzureCredential 請透過目前系統的默認瀏覽器，以互動方式驗證您。 預設會停用這個選項。

注意

由於 已知問題， VisualStudioCodeCredential 已從 DefaultAzureCredential 令牌鏈結中移除。 在未來版本中解決此問題時，將會還原此變更。 如需詳細資訊，請參閱 適用於 Python 的 Azure 身分識別客戶端連結庫。