# 使用托管身份访问 Azure Front Door 的 Key Vault 证书

**作者：吉祥法师**

## 核心概念

在现代云原生应用架构中，证书管理是保障通信安全的关键环节。Azure Front Door 作为微软提供的内容分发网络（CDN）和应用程序防火墙服务，通常需要加载 TLS/SSL 证书来加密客户端与边缘节点之间的数据传输。传统方式下，这些证书存储在 Azure Key Vault 中，而 Front Door 需要通过某种身份验证机制来安全地获取这些证书。

托管身份（Managed Identities）是微软 Entra ID（原 Azure Active Directory）提供的一项功能，它为 Azure 资源提供自动管理的服务主体身份，使资源能够安全地访问其他受 Entra ID 保护的服务，而无需在代码中硬编码凭据或管理密钥。当启用托管身份后，Azure Front Door 实例可以通过该身份向 Azure Key Vault 进行身份验证，从而安全地获取和管理 TLS 证书。

Azure Front Door 支持两种类型的托管身份：

- **系统分配身份**：与服务生命周期绑定。创建服务时自动创建身份，删除服务时身份也会被删除。每个服务只能拥有一个系统分配身份。
- **用户分配身份**：作为独立的 Azure 资源存在，拥有自己的生命周期。一个服务可以分配多个用户分配身份，从而支持更复杂的权限管理场景。

需要注意的是，托管身份与 Azure 订阅所在的 Microsoft Entra 租户绑定。如果订阅被移动到不同的目录，则需要重新创建和配置身份。

## 文章背景与适用场景

本文适用于 Azure Front Door Standard 和 Azure Front Door Premium 两个层级。配置托管身份的核心价值在于：

1. **自动化证书轮换**：托管身份使 Front Door 能够自动获取 Key Vault 中更新的证书，无需手动干预。
2. **增强安全性**：避免了使用长期有效的客户端密钥或证书，消除了凭据泄露风险。
3. **简化运维**：不再需要手动管理服务主体凭据，降低运维复杂度。

相反，如果未正确配置托管身份和 Key Vault 权限，自定义证书的自动轮换和新证书添加操作将失败。值得注意的是，如果禁用托管身份，Azure Front Door 将回退到使用原始的 Microsoft Entra 应用配置，这种方式不推荐使用，且将在未来被弃用。

## 必要条件

在开始配置之前，需要确保满足以下前置条件：

1. **有效的 Azure 订阅**：需要一个激活状态的 Azure 账户。如果尚无账户，可以免费创建一个。
2. **Azure Front Door 配置文件**：需要已创建 Standard 或 Premium 层级的 Front Door 配置文件。如果尚未创建，可以参考 Microsoft Learn 文档中的指南进行创建。

## 启用托管身份配置步骤

### 进入身份设置页面

首先，登录到 Azure 门户（Azure Portal），导航至现有的 Azure Front Door 配置文件。在左侧菜单栏中找到“安全性”（Security）部分，点击“标识”（Identity）选项。在此页面中，可以选择配置系统分配或用户分配的托管身份。

### 配置系统分配身份

系统分配身份是配置最简单的方案，适合大多数使用场景。操作步骤如下：

1. 在“系统分配”（System assigned）选项卡中，将“状态”（Status）切换为“开启”（On）。
2. 点击“保存”（Save）按钮。
3. 在弹出的确认对话框中，点击“是”（Yes）以确认创建系统管理的托管身份。

身份创建完成后，系统会显示一个对象（主体）ID（Object Principal ID），该 ID 已注册到 Microsoft Entra ID 中。后续配置 Key Vault 访问权限时，需要使用这个对象 ID 来授予 Azure Front Door 访问密钥保管库的权限。

### 配置用户分配身份

如果企业有更复杂的权限管理需求，或者需要在多个服务之间共享身份，可以选择用户分配托管身份。具体步骤如下：

1. 首先，确保已存在一个用户分配的托管身份资源。如果尚未创建，需要先在 Azure 门户中创建该资源。
2. 在“用户分配”（User assigned）选项卡中，点击“+ 添加”（+ Add）按钮。
3. 在弹出的搜索框中，查找并选择需要添加的用户分配托管身份。
4. 点击“添加”（Add）确认操作。

添加完成后，所选用户分配托管身份的名称会出现在 Azure Front Door 配置文件中，表示已经成功关联。

## 配置 Key Vault 访问权限

启用托管身份后，接下来需要在 Azure Key Vault 中配置相应的访问权限。Azure Key Vault 支持两种访问控制方式：

- **基于角色的访问控制（RBAC）**：利用 Azure Resource Manager 提供精细的访问控制。
- **访问策略**：使用 Key Vault 原生访问控制机制。

### 使用基于角色的访问控制（RBAC）

RBAC 方式在 Azure 中更为通用，提供了集中化、细粒度的权限管理。操作步骤如下：

1. 在 Azure 门户中导航至目标 Azure Key Vault。
2. 在左侧菜单的“设置”（Settings）下，选择“访问控制 (IAM)”（Access control (IAM)）。
3. 点击“+ 添加”（+ Add），然后选择“添加角色分配”（Add role assignment）。
4. 在“添加角色分配”页面中，搜索“Key Vault 密钥用户”（Key Vault Secret User）角色，并从搜索结果中选择该角色。
5. 切换到“成员”（Members）选项卡，将“分配访问权限至”（Assign access to）设置为“托管身份”（Managed identity）。
6. 点击“+ 选择成员”（+ Select members），在弹出的面板中选择与 Azure Front Door 关联的系统分配或用户分配托管身份，然后点击“选择”（Select）。
7. 点击“查看 + 分配”（Review + assign）以完成角色分配。

通过这种方式，Key Vault 密钥用户角色将授予托管身份读取密钥保管库中机密（包括证书）的权限。

### 使用访问策略

如果企业更倾向于使用 Key Vault 原生的访问控制方式，可以选择访问策略机制。具体步骤如下：

1. 在 Azure 门户中打开目标 Azure Key Vault。
2. 在左侧菜单的“设置”（Settings）下，选择“访问策略”（Access policies），然后点击“+ 创建”（+ Create）。
3. 在“创建访问策略”页面中，切换到“权限”（Permissions）选项卡。
4. 在“密钥权限”（Secret permissions）下，勾选“列出”（List）和“获取”（Get）权限。
5. 点击“下一步”（Next）进入“主体”（Principal）选项卡。
6. 在主体选项卡中，输入系统分配托管身份的对象（主体）ID，或者输入用户分配托管身份的名称。
7. 点击“查看 + 创建”（Review + create）。应用程序选项卡将被跳过，因为 Azure Front Door 已被自动选中。
8. 在最终确认页面，检查访问策略设置是否正确，然后点击“创建”（Create）完成操作。

## 验证访问配置

完成上述配置后，需要验证托管身份是否能够正常访问证书。验证步骤如下：

1. 导航至启用了托管身份的 Azure Front Door 配置文件。
2. 在左侧菜单的“安全性”（Security）下，选择“密钥”（Secrets）。
3. 确认在 Front Door 中使用的证书对应的“访问角色”（Access role）列中，显示为“托管身份”（Managed identity）。

如果是首次配置托管身份，可能需要先在 Front Door 中添加一个证书，才能看到该列的数据。这一确认步骤确保托管身份已成功与证书建立关联，并具备访问权限。

## 架构解析与技术要点

### 托管身份的工作机制

托管身份的工作原理基于 Microsoft Entra ID 的服务主体机制。当启用系统分配托管身份时，Azure 平台会自动在 Entra ID 中创建一个对应的服务主体，该服务主体的生命周期与 Azure 资源（这里是 Front Door 配置文件）绑定。当 Front Door 需要访问 Key Vault 中的证书时，它可以使用此服务主体来获取访问令牌，而无需任何代码层面的凭据管理。

### 安全最佳实践

- 遵循最小权限原则，仅为托管身份授予必要的 Key Vault 权限。在 RBAC 方式下，只分配“Key Vault 密钥用户”角色，而非更宽泛的角色如“Key Vault 管理员”。
- 定期审查托管身份的权限配置，确保没有过度授权。
- 如果使用用户分配身份，应避免在多个环境中共享同一身份，以降低安全风险。
- 企业应建立监控机制，跟踪 Front Door 获取证书的日志，确保证书轮换过程正常进行。

### 常见故障排查思路

如果配置后证书访问仍然失败，可以从以下几个方面排查：

1. **检查托管身份是否已启用**：在 Front Door 的“标识”页面确认状态为“开启”。
2. **检查 Key Vault 权限配置**：确认 RBAC 角色分配或访问策略中已包含正确的托管身份。
3. **检查网络与防火墙设置**：确保 Key Vault 的防火墙规则不会阻止托管身份的访问请求。
4. **检查订阅目录一致性**：确保 Front Door 与 Key Vault 位于同一 Entra ID 租户中。

## 相关扩展内容

### 端到端 TLS 加密

启用托管身份访问 Key Vault 证书后，Azure Front Door 可以加载这些证书，实现端到端的 TLS 加密。这包括：

- **前端 TLS 加密**：加密用户与 Front Door 边缘节点之间的通信。
- **源站 TLS 加密**：加密 Front Door 与后端源服务器之间的通信。

### 自定义域名的 HTTPS 配置

对于使用自定义域名的场景，Front Door 需要为每个自定义域名配置 HTTPS 证书。通过托管身份从 Key Vault 获取证书，可以自动化此过程，确保域名证书始终保持最新状态。

## 总结

托管身份为 Azure Front Door 与 Key Vault 之间的证书访问提供了一种安全、自动化的解决方案。通过配置系统分配或用户分配托管身份，并结合 RBAC 或访问策略授予相应权限，企业能够显著提升证书管理的安全性和效率。该方案不仅消除了手动管理凭据的负担，还支持证书的自动轮换和持续可用性，是 Azure 云环境中管理 TLS 证书的最佳实践之一。随着微软逐步弃用传统的 Entra ID 应用方式，采用托管身份势在必行。企业应尽早完成迁移，以确保其 Front Door 服务的证书管理符合未来的平台发展方向。