技能介绍

要解决什么问题

在 Azure 上跑 Python 服务时，数据库连接串、API 密钥和 TLS 证书往往不能写进代码或配置文件。Key Vault 是集中存放这些敏感材料的托管服务，但 SDK 里客户端类型多（机密、密钥、证书、加解密），鉴权方式也容易在本地与生产之间踩坑。

技能如何组织内容

本技能围绕 Azure Key Vault Python SDK 的常用路径展开：

机密（Secrets）：SecretClient 的创建、读写与版本相关操作。
密钥（Keys）：KeyClient 管理密钥；CryptographyClient 做加密、解密、签名与验签。
证书（Certificates）：CertificateClient 的签发与管理流程。

文档在开头固定两条工程约定，并建议生产代码始终遵守：

优先 DefaultAzureCredential：本地可用 Azure CLI / VS Code / Developer CLI；在 Azure 内可走托管标识或工作负载标识，避免连接字符串和静态 API 密钥绕过 Entra 审计与轮换。
客户端与异步凭据放在上下文管理器里：同步用 with ... as client，异步用 async with 包裹客户端，并对 azure.identity.aio 的 DefaultAzureCredential 同样使用 async with，以便释放 HTTP 传输与令牌缓存。

另附客户端类型对照表、异步客户端说明、错误处理，以及十条最佳实践（同步/异步不混用、RBAC、软删除、机密版本轮换、App Service Key Vault 引用、适度缓存、高吞吐用异步等）。references/ 下还有能力清单与非主路径场景补充。

适用边界与注意点

技能聚焦 SDK 使用模式与运维习惯，不替代 Azure 门户里的 Vault 创建、网络隔离或合规审计策略。生产环境可通过 AZURE_TOKEN_CREDENTIALS 收紧凭据链；权限模型上文档倾向 RBAC 而非旧式访问策略。同一调用链内不要混用同步与 azure.*.aio 异步客户端。

截图预览

使用场景

在 Azure App Service 或 Functions 上部署 Python 服务，需用 `SecretClient` 从 Key Vault 读取数据库连接串，并避免在配置里写死密钥。
本地用 Azure CLI 开发、上线后切托管标识，希望同一套代码通过 `DefaultAzureCredential` 完成鉴权，不再维护连接字符串。
业务需要在服务端对敏感字段做加解密或签名验签，计划用 `KeyClient` 与 `CryptographyClient` 在 Vault 中托管密钥并调用加密 API。
运维脚本要轮换 TLS 证书或跟踪机密版本，需按 `CertificateClient` 与 Secret 版本机制完成签发、更新与回滚。

适合人员

在 Azure 上维护 Python 微服务或 API 的后端工程师，要把配置中的明文密钥迁到 Key Vault 并接入应用配置引用。
负责身份与权限的平台工程师，需要为 Python 作业配置 RBAC、托管标识，并收紧生产环境的凭据链（如 `AZURE_TOKEN_CREDENTIALS`）。
编写数据保护或合规相关逻辑的开发者，需在 Python 中调用 Key Vault 密钥完成加解密或签名，且要求客户端用上下文管理器正确释放资源。
高并发 Azure 工作负载的维护者，计划在同一模块内统一采用异步 `azure-keyvault-*` 客户端以减少 Vault API 调用压力。