使用用于 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 服务(AKS)中运行的应用可以使用工作负荷标识凭据。 此凭据基于与 AKS 服务帐户具有信任关系的托管标识。 , |
托管在 Azure 外部的应用 (例如,本地应用) |
在 Azure 外部托管的应用(例如,需要连接到 Azure 服务的本地应用)应使用 应用程序服务主体。 应用程序服务主体表示 Azure 中的应用的标识,是通过应用程序注册过程创建的。 例如,请考虑在本地托管的 Django Web 应用,该应用使用 Azure Blob 存储。 使用应用注册过程为应用创建应用程序服务主体。 这 AZURE_CLIENT_ID 一点 AZURE_TENANT_ID ,并将 AZURE_CLIENT_SECRET 全部存储为在运行时由应用程序读取的环境变量,并允许应用使用应用程序服务主体向 Azure 进行身份验证。 |
在本地开发期间进行身份验证
当应用程序在本地开发期间在开发人员工作站上运行时,它仍必须向应用使用的任何 Azure 服务进行身份验证。 在本地开发期间,有两个主要策略用于向 Azure 验证应用:
身份验证方法 | 说明 |
---|---|
创建在本地开发期间要使用的专用应用程序服务主体对象。 | 在此方法中,使用应用注册过程设置专用 应用程序服务主体 对象,以便在本地开发期间使用。 然后,服务主体的标识将存储为环境变量,供应用在本地开发环境中运行时访问。 使用此方法可将应用所需的特定资源权限分配给开发人员在本地开发期间使用的服务主体对象。 这种做法可确保应用程序仅有权访问它所需的特定资源,并副本 (replica)应用在生产环境中拥有的权限。 此方法的缺点是,需要为每个在应用程序中工作的开发人员创建单独的服务主体对象。 |
在本地开发期间,使用开发人员的凭据向 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
对象会自动检测为应用配置的身份验证机制,并获取对应用进行身份验证所需的令牌。 如果应用程序使用多个 SDK 客户端,则可以将同一凭据对象用于每个 SDK 客户端对象。
使用 DefaultAzureCredential 时的身份验证方法序列
在内部,DefaultAzureCredential
实现凭据提供程序链,以便对访问 Azure 资源的应用程序进行身份验证。 每个凭据提供程序都可以检测是否为应用配置了该类型的凭据。 该DefaultAzureCredential
对象按顺序检查每个提供程序的顺序,并使用配置了凭据的第一个提供程序中的凭据。
下图和表中显示了查找凭据的顺序 DefaultAzureCredential
:
凭据类型 | 说明 |
---|---|
环境 | 该 DefaultAzureCredential 对象读取一组环境变量,以确定是否为应用设置了应用程序服务主体(应用程序用户)。 如果是,则 DefaultAzureCredential 将使用这些值对访问 Azure 的应用进行身份验证。此方法最常用于服务器环境,但也可以在本地开发时使用它。 |
工作负载标识 | 如果应用程序部署到启用了DefaultAzureCredential 托管标识的 Azure Kubernetes 服务 (AKS),请使用该托管标识向 Azure 验证应用。 工作负荷标识表示用户分配的托管标识与 AKS 服务帐户之间的信任关系。 AKS 文章将 Microsoft Entra 工作负荷 ID 与 Azure Kubernetes 服务 配合使用,讨论了使用工作负荷标识进行身份验证。 |
托管的标识 | 如果应用程序部署到启用了托管标识的 Azure 主机, DefaultAzureCredential 请使用该托管标识向 Azure 验证应用。 使用托管标识进行身份验证在服务器环境中的“身份验证”部分中进行了讨论。仅当应用程序通过使用Azure App 服务、Azure Functions 或 Azure 虚拟机等服务在 Azure 中托管时,此方法才可用。 |
Azure CLI | 如果使用 Azure CLI 中的命令向 Azure az login 进行身份验证, DefaultAzureCredential 请使用同一帐户向 Azure 验证应用。 |
Azure PowerShell | 如果已使用 Azure PowerShell 中的 Connect-AzAccount cmdlet 向 Azure 进行身份验证, DefaultAzureCredential 请使用同一帐户向 Azure 验证应用。 |
Azure 开发人员 CLI | 如果使用 Azure 开发人员 CLI 中的命令向 Azure azd auth login 进行身份验证, DefaultAzureCredential 请使用同一帐户向 Azure 验证应用。 |
交互 | 如果启用, DefaultAzureCredential 请通过当前系统的默认浏览器以交互方式对你进行身份验证。 默认情况下禁用此选项。 |
注意
由于已知 问题, VisualStudioCodeCredential
已从 DefaultAzureCredential
令牌链中删除。 在将来的版本中解决此问题时,将还原此更改。 有关详细信息,请参阅 适用于 Python 的 Azure 标识客户端库。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈