与 Azure Key Vault 一起使用时，Microsoft Entra ID 提供了一种可靠且安全的方法来向需要访问密钥或凭据的 Azure 服务和第三方平台对应用程序进行身份验证。 这种组合无需在应用程序代码中硬编码机密，而是依赖于托管标识、基于角色的访问控制（RBAC）和通过 Key Vault 集中的机密管理。 此方法简化了标识管理，并增强了云环境中的安全态势。
本演练通过 GitHub 存储库中提供的实际示例探索这些身份验证机制： github.com/Azure-Samples/python-integrated-authentication。
此示例演示 Python 应用程序如何：
使用 DefaultAzureCredential 通过 Azure 进行身份验证
在不存储凭据的情况下访问 Azure Key Vault 机密
与其他 Azure 服务（例如 Azure 存储、Cosmos DB 等）安全通信
本文是一系列教程的一部分，其中详细介绍了如何使用 Azure Python SDK azure-identity 库通过 Microsoft Entra ID、Azure Key Vault 和 Azure 队列存储对 Python 应用进行身份验证。
第 1 部分：背景
虽然许多 Azure 服务完全依赖于基于角色的访问控制（RBAC），而其他服务则要求通过机密或密钥进行访问。 此类服务包括 Azure 存储、数据库、Foundry 工具、Key Vault 和事件中心
生成与这些服务交互的云应用程序时，开发人员可以使用 Azure 门户、CLI 或 PowerShell 生成和配置特定于服务的访问密钥。 这些密钥绑定到特定的访问策略，以防止未经授权的访问。 但是，此模型要求应用程序显式管理密钥，并使用每个服务单独进行身份验证，此过程既繁琐又容易出错。
直接在代码中嵌入机密或在开发人员计算机上存储机密可能会暴露这些机密：
- 源代码管理
- 不安全的本地环境
- 意外产生的日志或配置导出
Azure 提供两项关键服务来改进安全性并简化身份验证：
- Azure Key Vault Azure Key Vault 为机密提供安全的基于云的存储，包括访问密钥、连接字符串和证书。 通过在运行时仅从 Key Vault 检索机密，应用程序可避免在源代码或配置文件中公开敏感数据。
- 使用 Microsoft Entra 托管标识，应用程序可以使用 Microsoft Entra ID 进行身份验证一次。 在此处，它可以访问其他 Azure 服务（包括 Key Vault），而无需直接管理凭据。
此方法提供：
- 无凭据代码（源代码管理中没有机密）
- 与 Azure 服务无缝集成
- 环境一致性：相同的代码在本地和云中运行，配置最少
本演练演示如何在同一应用中同时使用 Microsoft Entra 托管标识和 Key Vault。 通过将 Microsoft Entra ID 和 Key Vault 一起使用，应用永远不需要使用单个 Azure 服务对自身进行身份验证，并且可以轻松安全地访问第三方服务所需的任何密钥。
重要
本文使用通用的通用术语“密钥”来指 Azure Key Vault 中存储为“机密”的内容，例如 REST API 的访问密钥。 此用法不应与 Key Vault 对 加密密钥 的管理混淆，这是 Key Vault 机密的单独功能。
示例云应用方案
若要更深入地了解 Azure 的身份验证过程，请考虑以下方案：Flask Web 应用程序部署到 Azure 应用服务。 它公开公共的未经身份验证的 API 终结点，该终结点返回 JSON 数据以响应 HTTP 请求。
为了生成其响应，API 调用需要访问密钥的第三方 API。 应用不使用将此密钥存储在代码或配置文件中，而是使用 Microsoft Entra 托管标识从 Azure Key Vault 在运行时安全地检索它。
在将响应返回到客户端之前，应用会将消息写入 Azure 存储队列进行异步处理。 尽管下游处理不是此方案的重点，但消息可能表示任务、日志或信号。
注释
尽管公共 API 终结点通常受其自己的访问密钥或身份验证机制的保护，但本演练假定终结点已打开且未经身份验证。
这种简化有助于将应用的内部身份验证要求（例如访问 Azure Key Vault 和 Azure 存储）与与外部客户端相关的任何身份验证问题隔离开来。
场景只聚焦于应用程序的行为，不涉及或演示外部调用方如何与终结点进行身份验证。