Azure Local离线模式Azure Policy（系列篇十五）
特别说明：由于Azure Local离线模式OEM商用版还未发布，微软也对一些技术未正式公开，新发布的时候技术上会有一些出入，到时作者交会更新博客不准确的描述。Azure Local 离线版的OEM商业正式版预估在2026年年底或2027年年初发布。
0. 关键事实
Azure Local Disconnected Operations 的 Azure Policy 与 Azure 公有云 Policy不是同一套完整实现——主要差异：
维度 | Azure 公有云 Policy | Azure Local Disconnected Policy |
范围 | 全 Azure Resource Provider | 仅 Arc-enabled Kubernetes + Arc-enabled Servers |
内置 Policy 数 | 数千 | 当前仅数十（Tags + AKS + Guest Configuration） |
自定义 Policy Definition | ✔ | ❌ 不支持（官方未说明） |
Compliance Dashboard | ✔ | ❌ 不支持 |
Remediation Actions | ✔ | ❌ 不支持 |
Policy Exemptions | ✔ | ❌ 不支持 |
Policy 评估周期 | 默认 24h | 官方未说明 |
⚠️ 上表中"❌ 不支持"项均直接引用 Microsoft Learn 当前文档——这不是推测。
1. Policy 范围
✅ 官方要求（Microsoft Learn 原文）
"In Azure Local disconnected operations, policy enforcement supports Arc-enabled Kubernetes and Arc-enabled servers."
- ✔ 仅生效于Arc-enabled Kubernetes
- ✔ 仅生效于Arc-enabled Servers
- ❌不生效于原生 Azure 服务（Storage、Compute 等大部分）
🔍 技术分析
虽然原文未明确说明 Policy Engine 的内部架构，但从整体设计可推断：
- Azure Policy Engine并不是完整 Azure 公有云 Policy
- 是 Azure Local Offline Control Plane 中集成的一部分 Policy Runtime
- 仅支持目前列出的资源类型（Arc-enabled 资源）
Azure Local 没有 Azure Storage Account、Azure VM、Azure SQL 等 Azure Resource Provider。 因此 Azure 公有云中大量针对 Compute / Storage / Networking Resource Provider 的 Policy Definition 不适用于离线模式。
💡 企业最佳实践
- 不要把公有云 Policy Definition 直接套用到 disconnected 环境
- 关注内置 Policy 列表时，只看 Tag / AKS / Guest Configuration三个类别
- 不要假设"公用 Policy Definition 通过 manifest 也能导入"——官方未说明
2. 内置 Policy Definition
✅ 官方要求
离线模式部署自带一批内置 Policy Definition。
Microsoft Learn 原文（关于 built-in policies 章节）： The following table summarizes the built-in policies supported for Azure Local disconnected operations.
Microsoft Learn 文档明确归类的三个 Category：
2.1 Category: Tags（16 项）
子组 | Policy | 关键行为 |
Add or replace |
| 创建/更新时增/改 tag；可触发 remediation；不动 RG |
| 创建/更新 RG 时增/改 tag | |
| 通过 remediation 增/改订阅 tag | |
Add |
| 仅对缺失该 tag 的资源新增；存在但值不同则不改 |
| 同上，仅对 RG | |
| 通过 remediation 新增订阅 tag | |
Inherit (replace) |
| 从 RG 继承，可触发 remediation |
Inherit (if missing) |
| 缺失时从 subscription 继承 |
| 缺失时从 RG 继承 | |
Append |
| 追加 tag；不修改已有 tag 的值 |
| 追加；不影响 RG | |
| 追加到 RG | |
Require |
| 强制 tag + 值 |
| 强制存在性 | |
| 强制 RG tag + 值 | |
| 强制 RG 存在性 |
⚠️重要：上述表格中所有提到"remediation task / can be remediated"的描述，直接沿用 Azure 公有云 Policy 描述——但 Azure Local Disconnected 明确将 Remediation Actions 列为Unsupported Features（详见 §5）。
因此：这些描述不能用来推断离线模式支持 Remediation。
2.2 Category: Azure Kubernetes Service（3 项）
Policy | 说明 |
Kubernetes cluster containers CPU and memory resource limits shouldn't exceed the specified limits | 限制容器 CPU/内存上限（GA for AKS，Preview for Arc K8s） |
Kubernetes cluster containers should only use allowed images | 仅允许可信镜像 |
Kubernetes cluster pod hostPath volumes should only use allowed host paths | 限制 hostPath 挂载 |
2.3 Category: Guest configuration（6 项）
Policy | 说明 |
Configure Linux Server to disable local users | 创建 Guest Configuration assignment，禁用本地用户 |
Configure secure communication protocols (TLS 1.2/1.3) on Windows servers | Windows TLS 协议配置 |
Configure time zone on Windows machines | Windows 时区配置 |
Requires resources to not have a specific tag | 反向 tag 约束 |
Inherit a tag from the subscription | 从 subscription 继承 tag |
Windows web servers should be configured to use secure communication protocols | Windows Web Server TLS 配置 |
⚠️不再有"Allowed Locations" / "Allowed SKUs" 类别——官方最新文档（2602+）已无此分类。
也不要假设内置 Policy 列表是封闭的——发布版本可能新增。
🔍 技术分析
- 内置 Policy 共16 + 3 + 6 = 25 项（截至 2606）
- 实际数量可能随 Azure Local 后续 release 调整
- 全部由 Azure Local Disconnecteddeployment 自带——不需要"额外安装"
💡 企业最佳实践
- 直接使用这 25 项内置 Policy 即可覆盖大多数治理诉求
- Tag 治理是首要落地场景（合规、分账、追踪）
- AKS 治理是 K8s 场景的强制项（resource limits + allowed images + hostPath）
- Guest Configuration适合 OS 加固场景（Linux 禁用本地用户、Windows TLS / 时区）
3. 启用 Policy 流程（示例：强制 RG tag）
✅ 官方要求（Microsoft Learn 原文步骤）
3.1 Set up the basics
- 本地 portal →Policy
- Authoring→Assignments→+ Assign policy
- 填：Scope/Policy definition/Assignment name
- Policy enforcement=Enabled
- Parameters进入下一步
3.2 Set the parameters
- Tag name= 必填
- 选 tag 名字 →Review + create
结果：任何没带该 tag 的资源组都无法创建。
🔍 技术分析
- 与 Azure 公有云的 Assignment model底层类似
- 区别在于 enforcement 后的动作——详见 §5
💡 企业最佳实践
- 从 RG 强制 tag 入手——这是最低风险、最高收益的起点
- Scope 选择：先用 Subscription 根 scope，再逐步收窄到 RG
- Enforcement 模式：
Enabled（强制）= 阻止不合规创建Disabled（audit）= 仅记录不合规——用于先观察再强制
4. 前置条件
✅ 官方要求
条件 | 说明 |
已部署 Azure Local + disconnected operations | 必须 |
已查看 Supported built-in policies 列表 | 推荐 |
选定要 assignment 的 Policy Definition | 必须 |
💡 企业最佳实践
- 先做 Tag 治理：所有 RG 必须带
CostCenter/Environment/Owner - 再做 AKS 治理：开启 resource limits + allowed images
- 最后做 Guest Configuration：OS 加固是质量更高的运营动作，优先级排在后
5. ⚠️ Unsupported Features（最关键的一节）
Microsoft Learn 原文（Latest 2602+）：
Unsupported features
The compliance dashboard, remediation actions, and policy exemptions aren't supported.
官方明文：不支持的功能
功能 | 状态 | 说明 |
Compliance Dashboard | ❌不支持 | 不提供合规性可视化仪表板 |
Remediation Actions | ❌不支持 | 不提供自动修复（即使 Built-in 描述沿用了"can be remediated"的措辞） |
Policy Exemptions | ❌不支持 | 不提供豁免机制 |
🔍 技术分析
关键判定：
- 很多 Built-in Policy 描述中保留了
"Existing resources can be remediated by triggering a remediation task."
- 这是因为 Built-in Policy直接引用 Azure 公有云 Policy 描述
- 不能凭此推断 Azure Local Disconnected 支持 Remediation
✔ 准确表述：虽然 Built-in Policy 描述沿用了 Azure Policy 的 Remediation 能力，但 Azure Local Disconnected 当前版本明确将 Remediation Actions 列为 Unsupported Features，因此目前无法自动执行 Remediation Task。
💡 企业最佳实践
- 不要依赖Remediation Action：
- 不要设计"先部署、不合规再自动修复"的流程
- 改走"先 enforcement / 阻止创建 + 手动对齐"的路径
- Compliance 缺口：缺失 Compliance Dashboard → 用本地脚本聚合（CLI + 周期性 export）替代
- Exemption 缺口：缺失 Policy Exemptions → 用单独 Group / Scope 隔离替代——把"已知不合规"资源放在独立 scope，不要通过 Policy 自身豁免
6. 已知开放问题（官方未明示——本研究工程推断）
⚠️ 以下项目官方文档未说明——仅供企业部署时参考，不要替微软做未来承诺。
6.1 自定义 Policy Definition（Custom Policy Definition）
- ❌官方完全未提支持 Import Custom Policy
- Azure 公有云通过
Microsoft.Authorization/policyDefinitions支持自定义 Policy Definition - Azure Local Disconnected Operations 是否开放：官方没有任何文档说明
- ❌不能推测支持
✔ 准确表述：官方尚未说明是否支持导入自定义 Policy Definition，目前文档仅说明支持内置 Policy。
6.2 Policy Evaluation（评估周期）
- 公有云默认 24h 评估周期
- Azure Local Disconnected Operations 是否一致：官方没有说明
- 可能模式：Event Driven / Local Scheduler / Resource Change Trigger
- 不能推测
✔ 准确表述：官方尚未公开离线模式下的 Policy Evaluation 调度机制。
6.3 Assignment 数量上限
- 官方未提供任何关于 Assignment 数量的数据
- 不要猜测"每 scope 几十到几百"
✔ 准确表述：官方未公布 Assignment 数量上限。
6.4 Portal 已知问题
来自 Known Issues 文档：Policy portal 存在已知问题，推荐使用CLI / PowerShell替代。
6.5 未 Arc 化资源是否被纳管
- 官方明确支持：Arc-enabled Kubernetes + Arc-enabled Servers
- ❓官方未说明：未 Arc 化的 Azure Local 基础设施资源是否纳入 Policy 管理范围
- 不替代微软做推断
✔ 准确表述：当前官方仅声明支持 Arc-enabled Kubernetes 与 Arc-enabled Servers，尚未说明未 Arc 化的 Azure Local 基础设施资源是否纳入 Azure Policy 管理范围。
7. 官方要求 vs 企业建议 对照表
维度 | 官方要求 | 企业建议（非微软强制） |
Policy 范围 | Arc-enabled Kubernetes + Arc-enabled Servers | 不要把公有云 Policy Definition 直接套用 |
内置 Policy | 25 项（Tags / AKS / Guest Configuration） | 不要假设Allowed Locations / SKUs 等类别仍然支持 |
启用流程 | Portal Policy → Assignments → Assign policy | 永远配 ACL：Tag → AKS → Guest Configuration 三阶段 |
Remediation Actions | ❌ 不支持 | 不要设计"先创建不合规、再 remediation"的流程；改走"enforcement + 手动对齐" |
Compliance Dashboard | ❌ 不支持 | 本地脚本聚合 compliance 状态作为替代 |
Policy Exemptions | ❌ 不支持 | 用独立 scope隔离已知不合规资源，不靠 Policy 自身豁免 |
Custom Policy Definition | 官方未说明 | 不替微软承诺支持，按"仅 25 项内置"规划 |
Evaluation 周期 | 官方未说明 | 不假设24h；按 event-driven 或在测试集群观察 |
Assignment 数量 | 官方未公布 | 不假设数量上限，按业务需求走 |
未 Arc 化资源 | 官方未说明 | 先 Arc 化再纳管为最稳路径 |
8. 关键 takeaway
Azure Local Disconnected Operations 的 Azure Policy：
- ✔ 是 Azure Policy 的子集
- ✔ 偏向创建时策略控制（Enforcement）
- ✔ 适合配置一致性约束（Governance）
- ❌不是 Azure 公有云中的完整 Policy 合规治理平台（无 Compliance Dashboard / Remediation / Exemptions）
因此企业级落地路径：
- 优先用 Tag 治理（最低风险、最高 ROI）
- AKS / K8s 治理（用 K8s 专用 Policy）
- Guest Configuration（OS 加固，路径最长）
- Compliance 跟踪改走"本地脚本聚合 + 周期性报告"——不依赖Azure Dashboard
- 不要假设 Remediation / Exemptions——所有"自动修复 / 豁免"路径改为"预防 + 手动"