Azure Local 部署之 Azure 准备（v2修订版）

Microsoft Learn --- Azure Local 官方文档（azloc-2606 当前 GA）

范围：部署 Azure Local 实例之前，需要在 Azure 侧完成的环境准备工作。不含：机房网络/物理硬件/AD DS 域准备（属于 Part 3 On-Premises Readiness）。

0. 顶层心智模型与术语分层

Azure Local 是混合架构：集群跑在本地，但通过 Azure Arc 由 Azure 控制面统一管理。Azure 侧准备工作的本质，就是为"Arc 注册 + 控制面调用 + 数据平面连接"铺路。

0.1 三层表述约定（贯穿全文）

|-------------------------|------------------------------------------------------------|--------|
| 层 | 含义 | 标识 |
| 官方硬要求 | Microsoft Learn 明确说"必须 / 不支持" | 文中标 ⚠️ |
| Portal/Toolkit 默认行为 | Portal Wizard 或 azurelocal-toolkit 默认实现，不代表 Azure Local 限制 | 文中标 📌 |
| 企业最佳实践 / 推荐 | CAF/WAF 等行业推荐 | 文中标 💡 |

整个 Azure 准备按 azurelocal.cloud 的 Phase 划分（与 Part 2 对齐）：

|-----------|-----------|------------------------------------------------------------------|-------------------------------------|
| Phase | Stage | 主题 | 典型执行人 |
| 01 | 03 | Landing Zones（MG / 订阅 / RG） | Tenant 级管理员 |
| 02 | 04 | Resource Provider 注册 | Subscription Owner |
| 03 | 05 | RBAC：建部署 SPN + 分配角色 | User Access Admin |
| 04 | 06 | Management 基础（VNet / VPN / KV / Log Analytics / Bastion / 管理 VM） | Contributor |
| 05 | 07 | Identity & Security（PIM + CA + Break-Glass） | Global Admin / PRA / Security Admin |

权限过渡点（来自社区文档）：Phase 03 Task 02 完成后，部署 SPN 与部署用户拿到所需 RBAC，后续 Stage 可不再使用 Elevated Admin。⚠️ 该结论源自 azurelocal.cloud 社区文档；Microsoft Learn 官方文档并未将这一过渡作为强制顺序。

1. Phase 01 --- Landing Zones

1.1 官方硬要求 vs 企业最佳实践

|------------------|---------------|-------------------------------|
| 项 | 官方硬要求 | 企业最佳实践 |
| Subscription | ⚠️ 必须存在一个 | 💡 按功能切分多个 |
| Resource Group | ⚠️ 集群资源需放入 RG | 💡 按职能拆 RG |
| Management Group | ✅ 不要求 | 💡 企业级推荐 CAF Enterprise-Scale |
| Landing Zone 架构 | ✅ 不要求 | 💡 大规模/合规场景推荐 |

结论：💡 单订阅 + 单 RG 即可满足 Azure Local 部署的最低要求；企业级 / 多集群 / 合规场景建议采用 CAF Landing Zone 架构。

1.2 为什么 Landing Zone 对 Azure Local 有价值（即使非强制）

每个 Azure Local 节点注册为 Arc-enabled Server → 需要 RG 接住
多个 Resource Provider 在 Subscription 级注册（见 Phase 02）
Entra ID 集成沿 MG 层级继承
Azure Policy 在 MG scope 应用，管控所有下属集群
Hub-Spoke / Direct connectivity 取决于订阅拓扑

1.3 两种部署模型对比

|--------------|------------------------------|-------------------------|
| 维度 | Full CAF/WAF | Single Subscription |
| MG | 完整 CAF Enterprise-Scale（10+） | Root MG + LZ MG（2） |
| Subscription | 5+ 按功能划分 | 单一订阅 |
| RG | 每订阅多个 | 每集群单一 |
| 策略 | MG 级继承 | Subscription 级 |
| RBAC | MG 级 + 订阅边界 | RG 级 |
| 适用 | 多集群 / 合规 / 多团队 | 单集群 / PoC / 实验室 |
| 复杂度 | 高 | 1 小时内可投产 |

1.4 架构示例

Full CAF/WAF 模型（IIC 示例）：

复制代码

Tenant Root Group
└── cmp-iic-root                       # 组织根 MG
    ├── cmp-platform-iic              # 平台服务
    │   ├── cmp-platform-management-iic      # 监控 / Log Analytics / Automation
    │   ├── cmp-platform-connectivity-iic    # Hub VNet / VPN / ExpressRoute
    │   └── cmp-platform-identity-iic        # Entra ID Connect
    ├── cmp-landing-zones-iic         # Landing Zone
    │   ├── cmp-lz-corp-iic                  # 内网 / Azure Local 工作负载
    │   └── cmp-lz-online-iic                # 对外网工作负载
    ├── cmp-sandbox-iic               # 非生产实验
    └── cmp-decommissioned-iic        # 待删除资源

Single Subscription 模型：

复制代码

Tenant Root Group
└── cmp-iic-root
    └── cmp-landing-zones-iic
        └── iic-lz-azurelocal-001 (Subscription)
            └── rg-c01-azl-eus-01      # 集群 RG
                ├── Azure Local cluster 资源
                ├── Arc-enabled servers
                ├── Key Vault
                └── Storage Account

1.5 Azure Local 特定考量

|-------------------|----------------------------------------------------------------------------------|
| 项 | 说明 |
| Arc 注册 | 每个节点 → Arc-enabled server → RG 需先存在 |
| Resource Provider | 必须注册核心 RP（见 Phase 02） |
| Region | ⚠️ 必须选 Azure Local 支持 region；💡 尽量靠近部署地点以降低存储见证/日志/备份的网络延迟（控制面流量小，region 远近影响不大） |
| 命名 | 沿用 CAF 命名规范；Arc 注册名一旦写入难改名 |
| Tag | RG 创建时打 Tag → 流向成本/策略/运维仪表盘 |

1.6 任务清单

|----------|-------------|-----------------------------|
| Task | 描述 | 文档路径 |
| Task 01 | 配置完整 MG 层级 | Configure Management Groups |
| Task 02 | 创建按功能切分的订阅 | Create Subscriptions |
| Task 03 | 在每个订阅中创建 RG | Create Resource Groups |

（Single Subscription 简化版对应：01 Configure MG / 02 Create Subscription / 03 Create RGs）

2. Phase 02 --- Resource Providers

2.1 分层：核心 RP（必需）vs 扩展 RP（按需）

|-----------------------------------|-------------------------------|-------------------------------|
| Namespace | 用途 | 类别 |
| Microsoft.AzureStackHCI | Azure Local 集群管理（核心） | ⚠️ 核心 RP |
| Microsoft.HybridCompute | Azure Arc-enabled servers | ⚠️ 核心 RP |
| Microsoft.GuestConfiguration | Azure Policy guest config | ⚠️ 核心 RP |
| Microsoft.HybridConnectivity | Arc 混合连接 | 📌 部署时默认需要 |
| Microsoft.ExtendedLocation | Arc 自定义位置 | 📌 部署时默认需要 |
| Microsoft.ResourceConnector | Azure Arc Resource Bridge | 📌 ARB 部署时需要 |
| Microsoft.Storage | 部署 Storage Account（witness 等） | 📌 部署时默认需要 |
| Microsoft.Insights | 监控 / 日志 / 诊断设置 | 📌 监控相关需要 |
| Microsoft.Kubernetes | Arc-enabled K8s | 💡 仅启用 AKS on Azure Local 时需要 |
| Microsoft.KubernetesConfiguration | K8s 配置 | 💡 同上 |
| Microsoft.HybridContainerService | 混合容器工作负载 | 💡 同上 |
| Microsoft.Attestation | 安全证明 | 💡 受信任启动 / 证明场景 |

📌 azurelocal-toolkit 默认一次性注册全部 12 个 RP，作为兜底策略可避免后续启用 AKS / Defender / 监控时因缺 RP 而失败。官方并未要求一次性全部注册 ，但建议至少注册前 8 个，其余按后续功能启用需要再补。

2.2 Microsoft.Insights 的实际影响

|---------------------------------------------------------------------------------|----------|
| 表述 | 是否准确 |
| "不注册 Microsoft.Insights 会导致 Azure Local 集群部署失败" | ❌ 官方无此说法 |
| "不注册 Microsoft.Insights 会导致 Monitor / AMA / Log Analytics / 诊断设置无法创建，影响部署后监控能力" | ✅ 准确表述 |

修正说明：Microsoft.Insights 与集群创建（Cluster Create）无直接依赖，但与 Azure Monitor、Azure Monitor Agent、Log Analytics Workspace、诊断设置（Diagnostic Settings） 直接相关。未注册会导致部署之后配置监控链路时报错。

2.3 权限要求

⚠️ RP 注册需要 Subscription 级 Contributor 或 Owner
RG 级权限不够（RP 注册是订阅级操作）

2.4 实操（简化版 CLI）

复制代码

SUBSCRIPTION_ID="<subscription-id>"
az account set --subscription $SUBSCRIPTION_ID

# 建议：核心 + 扩展全部注册（azurelocal-toolkit 默认行为）
for provider in \
  Microsoft.HybridCompute \
  Microsoft.GuestConfiguration \
  Microsoft.HybridConnectivity \
  Microsoft.AzureStackHCI \
  Microsoft.Kubernetes \
  Microsoft.KubernetesConfiguration \
  Microsoft.ExtendedLocation \
  Microsoft.ResourceConnector \
  Microsoft.HybridContainerService \
  Microsoft.Attestation \
  Microsoft.Storage \
  Microsoft.Insights
do
  az provider register --namespace $provider
done

# 验证全部 Registered
az provider list --query "[?registrationState!='Registered']" -o table
# 期望：返回空表

2.5 验证标准

全部目标 RP 状态 = Registered
没有任何 NotRegistered / Unregistered / Registering
Azure Activity Log 可见成功注册事件

3. Phase 03 --- RBAC Permissions

3.1 Portal 自动分配 vs 人工准备

Microsoft Learn 关于 Deploy via Azure portal 的明确要求：订阅级 User Access Administrator + Contributor。

|---------------------------------------------------------------------|---------------------|----------------------------|
| 角色 | 角色定义 | 来源 |
| Contributor | 创建/管理 Azure 资源 | ⚠️ 官方必需 |
| User Access Administrator | 管理 RBAC 角色分配 | ⚠️ 官方必需 |
| Reader | 读 Azure 资源/配置 | 📌 Portal Wizard 过程中可能自动补充 |
| Azure Stack HCI Administrator | 管理 Azure Local 集群资源 | 📌 Portal Wizard 可能自动补充 |
| Key Vault Secrets Officer / Data Access Administrator / Contributor | 集群 RG 上的数据面权限 | 📌 Portal Wizard 可能自动补充 |
| Azure Connected Machine Onboarding / Resource Administrator | Arc 注册相关 | 📌 Portal Wizard 可能自动补充 |

📌 关键说明 ：上述非"必需"角色，Portal Deployment Wizard 在执行过程中会按需自动分配 。社区文档列出"完整 10 角色矩阵"是按 azurelocal-toolkit / 严格 CAF 流程准备的人工 RBAC 清单，便于 ARM 模板、CI/CD 或无 Portal 场景使用。如果走纯 Portal 部署，实际人工准备只需 Contributor + UAA。

3.2 部署 SPN 设计（CI/CD / ARM 场景需要）

|-------|--------------------------------------|
| 项 | 建议 |
| 名称 | sp-azurelocal-deploy |
| 类型 | App registration + Service Principal |
| 凭据 | Client Secret（生成后立即写入平台 KV） |
| 用途 | CI/CD、ARM 模板、ARB 安装 |

Portal 部署不需要预先建 SPN；SPN 是 CI/CD 自动化场景的产物。

3.3 RBAC 角色分配（Subscription 级）

赋给 SPN + 部署用户（CI/CD 场景）：

|-------------------------------|---------------------|
| 角色 | 用途 |
| Contributor | 创建/管理 Azure 资源 |
| User Access Administrator | 管理 RBAC 角色分配 |
| Azure Stack HCI Administrator | 管理 Azure Local 集群资源 |
| Reader | 读 Azure 资源/配置 |

3.4 RBAC 角色分配（Cluster RG 级）

赋给 SPN + 部署用户 ，作用域必须挂在集群 RG而非平台 KV RG：

复制代码

/subscriptions/<subscription-id>/resourceGroups/<cluster-resource-group>

|------------------------------------------------|-------------------------------|
| 角色 | 用途 |
| Key Vault Data Access Administrator | 部署 KV 数据面权限 |
| Key Vault Secrets Officer | 读/写 KV 密钥 |
| Key Vault Contributor | 创建/管理 KV |
| Storage Account Contributor | 创建 Storage Account（witness 等） |
| Azure Connected Machine Onboarding | 把机器注册到 Arc |
| Azure Connected Machine Resource Administrator | 管 Arc-enabled machine 资源 |

3.5 验证标准

✅ SPN sp-azurelocal-deploy 在 Entra ID 存在（CI/CD 场景）
✅ 凭据已存到平台 KV（CI/CD 场景）
✅ Subscription 级 Contributor + UAA 已分配（人工必需）
✅ Cluster RG 级 6 个角色已分配（CI/CD 场景）

4. Phase 04 --- Azure Management Infrastructure

这一段是 Azure 侧"对接集群的管理面"。Site-to-Site VPN 或 ExpressRoute 是前置 ------ 否则 Azure 上的管理 VM 碰不到本地集群。

4.1 部署模式选择

|----------------------------------------------|-----------------------------|
| 模式 | 何时用 |
| CI/CD Pipeline（azurelocal-toolkit Terraform） | 生产、追求 IaC、可重复 |
| 手动 | 自定义 Landing Zone、纯 PoC、特殊合规 |

azurelocal-toolkit 的限制（📌 是示例模板限制，非 Azure Local 限制）：

❌ 不含 VM OS 级配置（AD DS / WAC / NDM 部署是手动作业）
📌 示例模板默认采用 Single Subscription 模型；改造模板支持多订阅是 Terraform 工程问题，不是 Azure Local 限制
📌 RG 命名/结构在示例中已固定

4.2 必须部署的基础设施（Management Mode，环境级一次）

|---------------------------|-------------------------------|---------------|--------|
| 资源 | 用途 | CI/CD | 手动 |
| Virtual Network + Subnets | Azure Local 管理网络 | ✅ | ✅ |
| VPN Gateway | 到本地的 S2S | ✅ | ✅ |
| VPN Connection | 建立隧道 | ✅ | ✅ |
| Azure Bastion | 安全 RDP/SSH 到 VM | ✅ | ✅ |
| NSG | 子网级安全规则 | ✅ | ✅ |
| NAT Gateway | 管理 VM 出站公网 | ✅ | ✅ |
| Arc Gateway（可选） | Azure Arc 混合连接（见 §4.6） | ✅ | ✅ |
| Log Analytics Workspace | 监控 + HCI Insights | ✅ | ✅ |
| Key Vault | 存放密码/密钥 | ✅ | ✅ |
| 管理 VM | DC、Utility/Jumpbox、WAC、Syslog | ⚠️ 可选（见 §4.5） | ⚠️ 可选 |

4.3 必须部署的集群专属资源（Cluster Mode，每集群一次）

|-----------------------------------------------------|---------|
| 资源 | 备注 |
| VPN Connection (Local Network Gateway + Connection) | 每个站点一个 |
| Cluster Key Vault | 见集群部署阶段 |
| Cluster Log Analytics | 见集群部署阶段 |

4.4 网络设计要点

Management IP 子网 ：⚠️ 至少 6 个连续可用 IP（第 1 个用于故障转移集群）------ 官方硬要求
Storage VLAN ：
- 📌 azurelocal-toolkit 默认 = 711 + 712
- 💡 Network ATC 推荐使用连续 VLAN；企业可根据现有 VLAN 规划调整，前提是 ATC 仍能识别
- 不是官方强制
DNS IP ：⚠️ 不能落在 10.96.0.0/12 或 10.244.0.0/16（K8s 保留）
Jumbo Frame：可选 1514 / 4088 / 9014
RDMA：iWARP / RoCE / RoCEv2 三选一
DCB：流量优先级、带宽分配通过 PFC 配置

4.5 Key Vault 命名/合规约束

|------------------|---------------------------------------------------------------------------------------|
| 项 | 说明 |
| 名称 | 3-24 字符，全局唯一，仅字母数字和 - |
| Private Endpoint | ⚠️Azure Local Portal Deployment 当前不支持用启用了 Private Endpoint 的 KV 部署集群 |
| 多实例共享 | ⚠️ 当前 Portal Deployment 要求每个集群使用独立 Key Vault；未来行为可能随产品版本变化，应以 Microsoft Learn 当前版本为准。 |
| Soft-delete | 7-90 天可设，创建后不可改 |
| Private Link 支持 | 💡 已在 Roadmap，未来可能放开 |

4.6 管理 VM ------ 不是 Azure Local 必需

|-------------------------------|----------------------------------|------------------|-------------------------|
| Server | variables.yml key | 角色 | 配置阶段 |
| Domain Controllers (dc1, dc2) | compute.vms.management.dc1/dc2 | AD DS + DNS | 环境特定 |
| Jumpbox / Utility | compute.vms.management.jumpbox | 跳板机 | Part 5 Phase 02 Task 05 |
| Windows Admin Center | compute.vms.management.wac | 集群 Web 管理 | Part 5 Phase 02 Task 05 |
| Syslog / NDM | compute.vms.management.syslog | Syslog + SNMP 接收 | Part 5 Phase 02 Task 07 |

关键说明 ：以上 4 类管理 VM 均非 Azure Local 必需组件 。企业已有 AD DS / DNS / Jumpbox / Syslog 时，直接复用现有基础设施即可 ，不需要在 Azure 上重建。Azure 上部署它们是 azurelocal-toolkit 的默认模板选择，企业可按实际需要取舍。deployment_target: azure | azurelocal | onprem 字段决定每台 server 落在何处。

4.7 Storage Witness

|--------------------|-----------------------------------------------------------------------------|
| 项 | 说明 |
| 必需性 | ⚠️ 两节点集群必须有 witness |
| 类型 | 可选 Cloud Witness（Azure Storage Account）或 File Share Witness |
| Storage Account 数量 | ⚠️ 当前 Portal 部署要求每集群独立 SA；技术上同一 SA 可承载多个 witness 文件，Portal Wizard 会强制检查 |
| 容量 | 每个 witness < 1 KB |

4.8 验证标准

✅ VPN 通
✅ DC 可达、DNS 解析正常
✅ Jumpbox 能 SSH/RDP 到 Azure Local 节点
✅ variables.yml 里管理 server 变量齐全
✅ Log Analytics 已经在收数据

5. Phase 05 --- Identity & Security（PIM + Conditional Access）

5.1 这一阶段覆盖什么 / 不覆盖什么

覆盖：

PIM（Azure 资源 + Entra ID 角色两套）
Conditional Access（CA001/CA002/CA003 三套策略）
Break-Glass 紧急账户

不覆盖（推迟到 Part 6 Operational Foundations）：

Defender for Cloud
Azure Policy 安全基准
Security Baselines
Data Collection Rules

5.2 适用场景

|------------------------------|------------------------------|
| 场景 | 处理建议 |
| 企业生产 + Entra ID P2 / M365 E5 | 完整执行本 Phase |
| 企业生产但无 Entra ID P2 | 评估升级许可或接受风险后跳过 |
| 非生产 / PoC / 实验室 | 可完全省略本 Phase，直接进入 Part 3 |

💡 P2 许可缺失时，不要硬上 PIM / 风险型 CA。可先做基础 MFA + 强密码策略，等许可到位再补 PIM/CA。文档/部署记录里需注明此决策。

5.3 必须配置项（生产 + 有 P2 许可时）

|-------------------------|-----------------------------|--------------------------------|
| 组件 | 目的 | Azure 资源 |
| PIM for Azure Resources | 订阅级 JIT 特权访问 | Privileged Identity Management |
| PIM for Entra ID Roles | 目录角色的 JIT 访问 | Privileged Identity Management |
| Conditional Access | 上下文感知的 MFA + 旧认证拦截 | Entra ID CA |
| Break-Glass 账户 | 紧急通道 --- 必须从所有 CA 策略豁免 | Entra ID |

5.4 推荐 Conditional Access 策略

|--------|------------------|-------------|
| 策略 | 模式 | 说明 |
| CA001 | Report-Only → On | 针对管理员强制 MFA |
| CA002 | Report-Only → On | 阻止旧协议认证 |
| CA003 | Report-Only → On | 阻止高风险登录 |

流程：先用 Report-Only 跑一段时间分析影响，确认无误再转 On。

5.5 Break-Glass 账户铁律

⚠️ 至少 2 个 break-glass 账户
⚠️ 全局管理员角色
⚠️ 必须排除出所有 CA 策略
⚠️ 凭据线下密封保存 + 定期演练

5.6 Phase 退出标准

✅ PIM 启用：Owner、Contributor、UAA（订阅级）
✅ PIM 启用：Global Admin、Security Admin、PRA（Entra ID 角色级）
✅ 为部署团队配置了 eligible 分配
✅ 2 个 break-glass 已建、文档化、CA 排除
✅ CA001/CA002/CA003 先 Report-Only 评审，再转 On

6. 官方 Azure 准备核对表（Microsoft Learn）

参考官方 Deployment prerequisites 和 Deploy via Azure portal：

|--------------------------|-----------------------------------------------------------|---------|
| 项 | 取值规则 / 要求 | 性质 |
| 机器名 | 每台机器一个唯一名 | ⚠️ |
| AD OU | 新建 OU，DN 格式，不能包含 & " ' < > | ⚠️ |
| AD 域 | FQDN | ⚠️ |
| AD 部署账户 | 长度 ≥ 14 字符，含大小写+数字+特殊字符；不能用 admin 作用户名 | ⚠️ |
| Management IP 子网 | ⚠️ 至少 6 个连续可用 IP | ⚠️ |
| 2 个 Storage VLAN | Network ATC 推荐；📌 Toolkit 默认 711/712 | 💡 |
| DNS IP | ⚠️ 不能落在 10.96.0.0/12 或 10.244.0.0/16 | ⚠️ |
| Local Admin 凭据 | 同上 14 字符复杂度规则 | ⚠️ |
| Custom Location 名 | 可选，Azure 上创建 VM 时区分用 | 💡 |
| Subscription ID | 部署用户在该订阅上需 ⚠️ User Access Administrator + Contributor | ⚠️ |
| Storage Account（witness） | 两节点集群必备；📌 Portal 当前要求每集群独立 SA | ⚠️ + 📌 |
| Key Vault | 部署时必须存在；⚠️ 当前不支持用启用了 Private Endpoint 的现有 KV | ⚠️ |
| 出站连通性 | 跑 Environment Checker 验证（见 §7） | ⚠️ |

7. 部署前必做：Environment Checker 与 Outbound URL

7.1 Environment Checker

工具：Test-AzStackHciEnvironmentChecker（PowerShell 模块）
来源：Microsoft Learn Use Environment Checker
时机：Portal 部署 wizard 之前 、Cluster Deployment 之前都建议跑一次
检查范围：硬件、驱动、固件、网络、AD、DNS、Arc 联通、出站 URL 等
性质：Microsoft Learn 强烈建议在部署前运行，用于提前发现环境问题。

安装与运行

Install-Module -Name AzStackHci.EnvironmentChecker -Force
$ip = "10.0.0.10" # 节点 IP Invoke-AzStackHciEnvironmentChecker -MachineIp$ ip

7.2 Outbound Connectivity / Firewall Requirements

来源：Microsoft Learn Firewall requirements

需要在本地防火墙 / 代理放行的关键端点（节选，以官方表为准）：

|----------------------------------|----------------------------|
| 端点 | 用途 |
| *.arc.azure.com | Arc 控制面 |
| *.his.arc.azure.com | Arc 混合 Identity Service |
| management.azure.com | ARM |
| login.microsoftonline.com | Entra ID 认证 |
| *.guestconfiguration.azure.com | Guest Configuration |
| *.blob.core.windows.net | Storage Account（含 witness） |
| *.vault.azure.net | Key Vault |
| dc.services.visualstudio.com | 遥测 |
| aka.ms | 安装脚本跳转 |

⚠️ 官方端点列表会持续更新；务必以 Firewall requirements 当期版本为准。Azure 准备完毕、Environment Checker 通过前，不要启动 Cluster Deployment。

8. Azure Arc Gateway

8.1 为什么需要 Arc Gateway

|---------------------|--------------------------------------|
| 场景 | 价值 |
| 企业出站受限（严格防火墙） | 大幅缩减需放行的 Azure 端点数量 |
| 多集群统一代理 | 一个 Arc Gateway 给多个集群共用 |
| Disconnected / 代理环境 | 走 Arc Gateway 而非直连 *.arc.azure.com |
| 减少 DNS 复杂度 | 只需解析 Arc Gateway FQDN |

8.2 部署前提

部署在 Azure 侧（与本地集群同 region 最佳）
需要 VNet + 子网 + 公网 IP（Standard）
需要 DNS A 记录或 CNAME 到 Gateway 公网 IP

8.3 与 Cluster 关系

集群节点 Arc Agent 改连 *.gw.arc.azure.com（Gateway FQDN）
启用 Gateway 后，可移除大量 *.arc.azure.com / *.his.arc.azure.com 直连放行

💡 建议：企业代理、受限出站、多集群场景推荐部署 Arc Gateway；单集群实验室可暂不部署，直接放行 Arc 端点。

9. Azure Policy（与 Landing Zone 配套）

Microsoft Learn 在 azloc-2606 把 Azure Policy 列为部署 Azure Local 的推荐管控手段。

9.1 推荐内置策略

|------------------------------------------------------------|--------------------------------|
| 策略 | 作用 |
| Allowed locations | 限定资源可创建 region |
| Allowed resource types | 限定可创建的资源类型 |
| Require tag and its value | 强制 Tag（如 CostCenter、Env） |
| Audit diagnostic setting | 审计关键资源是否配置 Diagnostic Settings |
| DeployIfNotExists --- Diagnostic Settings to Log Analytics | 自动部署诊断设置到 LAW |
| Inherit tag from RG | RG Tag 自动继承到子资源 |

9.2 实践建议

在 MG 级或 Landing Zone MG 级统一定义
Policy 分配 + Initiative（策略集）一并下发
用 Policy 强制 Arc-enabled server / Azure Local 集群使用合规 SKU / region

💡 Azure Policy 不是部署 Azure Local 的硬性条件，但企业级场景建议与 Landing Zone 同步落地。Azure Policy不影响Azure Local部署成功，仅用于部署后的治理和持续合规。

10. 完整交付物清单

✅ Management Group 层级（按企业规模选择 CAF/WAF 或 Single Subscription）
✅ Subscription 已创建并挂在正确 MG 下
✅ RG 已创建，带命名规范和 Tag
✅ 核心 RP（AzureStackHCI / HybridCompute / GuestConfiguration）+ 部署必需 RP 已 Registered
✅ 订阅级 Contributor + UAA 已分配（人工必需）；其余 8 角色按需
✅ Cluster RG 级 6 个 RBAC 角色（CI/CD 场景）
✅ 部署 SPN sp-azurelocal-deploy + 凭据入 KV（CI/CD 场景）
✅ Hub VNet + 子网 + NSG + NAT Gateway
✅ VPN Gateway + VPN Connection（到本地）
✅ Azure Bastion
✅ Log Analytics Workspace
✅ 平台 Key Vault
✅ Azure Arc Gateway（企业 / 多集群场景推荐）
✅ 管理 VM 按需部署（可复用现有 AD/DNS/Jumpbox/Syslog）
✅ Azure Policy 初始化（企业级推荐）
✅ PIM 启用（Azure 资源 + Entra ID 角色两套；P2 许可 + 生产环境）
✅ Conditional Access 三套策略（先 Report-Only 后 On；同上）
✅ Break-Glass 账户 2 个，凭据密封保管
✅ Environment Checker 通过
✅ Outbound URL 防火墙放行核对完毕

11. 关键风险与避坑

|-------|--------------------------------------------|----------------------------------------|
| # | 风险点 | 性质 |
| 1 | Microsoft.Insights 未注册 → 监控/诊断设置/Law 链路失败 | 准确，但不会导致 Cluster Create 失败 |
| 2 | RG 级角色挂在平台 KV RG 而非集群 RG | Arc 注册 / KV 密钥读写全部失败 |
| 3 | 给部署实例用的 KV 开了 Private Endpoint | ⚠️ Portal 当前拒绝，未来可能放开 |
| 4 | Witness SA 跨集群共享 | 📌 Portal 当前强制独立 SA；技术上可承载多 witness 文件 |
| 5 | DNS IP 落在 10.96.0.0/12 或 10.244.0.0/16 | ⚠️ K8s 保留段冲突 |
| 6 | Storage VLAN 脱离 ATC 默认未提前规划 | 后果 = 交换机透传失败 |
| 7 | PIM 未启用就长期分 Owner | 违反最少权限；先 PIM eligible 后按需激活 |
| 8 | Break-Glass 未在 CA 中排除 | 紧急时刻全员锁出 |
| 9 | OU path 含 & " ' < > | ⚠️ DN 解析直接失败 |
| 10 | region 不在 Azure Local 支持列表 | ⚠️ Portal 选项灰 |
| 11 | 出站 URL 未放行 / Environment Checker 未跑 | 部署后连接 Arc 失败、ARB 拉镜像失败等隐蔽问题 |
| 12 | 没启用 Arc Gateway 而企业代理只放行少量端点 | Arc Agent 通信失败 |

12. 完成后 → 下一步

Azure 准备完毕后，进入 Part 3 --- On-Premises Readiness（本地侧准备）：

Azure Local 部署之 Azure 准备（v2修订版）

0. 顶层心智模型与术语分层

0.1 三层表述约定（贯穿全文）

1. Phase 01 --- Landing Zones

1.1 官方硬要求 vs 企业最佳实践

1.2 为什么 Landing Zone 对 Azure Local 有价值（即使非强制）

1.3 两种部署模型对比

1.4 架构示例

1.5 Azure Local 特定考量

1.6 任务清单

2. Phase 02 --- Resource Providers

2.1 分层：核心 RP（必需）vs 扩展 RP（按需）

2.2 Microsoft.Insights 的实际影响

2.3 权限要求

2.4 实操（简化版 CLI）

2.5 验证标准

3. Phase 03 --- RBAC Permissions

3.1 Portal 自动分配 vs 人工准备

3.2 部署 SPN 设计（CI/CD / ARM 场景需要）

3.3 RBAC 角色分配（Subscription 级）

3.4 RBAC 角色分配（Cluster RG 级）

3.5 验证标准

4. Phase 04 --- Azure Management Infrastructure

4.1 部署模式选择

4.2 必须部署的基础设施（Management Mode，环境级一次）

4.3 必须部署的集群专属资源（Cluster Mode，每集群一次）

4.4 网络设计要点

4.5 Key Vault 命名/合规约束

4.6 管理 VM ------ 不是 Azure Local 必需

4.7 Storage Witness

4.8 验证标准

5. Phase 05 --- Identity & Security（PIM + Conditional Access）

5.1 这一阶段覆盖什么 / 不覆盖什么

5.2 适用场景

5.3 必须配置项（生产 + 有 P2 许可时）

5.4 推荐 Conditional Access 策略

5.5 Break-Glass 账户铁律

5.6 Phase 退出标准

6. 官方 Azure 准备核对表（Microsoft Learn）

7. 部署前必做：Environment Checker 与 Outbound URL

7.1 Environment Checker

安装与运行

7.2 Outbound Connectivity / Firewall Requirements

8. Azure Arc Gateway

8.1 为什么需要 Arc Gateway

8.2 部署前提

8.3 与 Cluster 关系

9. Azure Policy（与 Landing Zone 配套）

9.1 推荐内置策略

9.2 实践建议

10. 完整交付物清单

11. 关键风险与避坑

12. 完成后 → 下一步

参考链接

azurelocal.cloud（社区文档站）

Microsoft Learn 官方文档（azloc-2606 当前 GA）