使用 Azure Front Door 确保 AKS 工作负荷的安全
本文介绍如何使用 Azure Front Door、Azure Web 应用程序防火墙和 Azure 专用链接服务以更安全的方式公开和保护在 Azure Kubernetes 服务(AKS)中运行的工作负荷。 此体系结构使用 NGINX 入口控制器来公开 Web 应用程序。 NGINX 入口控制器被配置为使用专用 IP 地址作为 AKS 内部负载均衡器的前端 IP 配置。 部署提供端到端传输层安全性 (TLS) 加密。
体系结构
Grafana 徽标是其对应公司的商标。 使用此标志并不意味着认可。
下载此体系结构的 Visio 文件。
工作流程
下图显示了部署和运行时的消息流步骤。
部署工作流
可以使用下列方法之一来部署 NGINX 入口控制器:
托管 NGINX 入口控制器: 使用 AKS 的应用程序路由加载项部署托管 NGINX 入口控制器。 部署将托管 NGINX 入口控制器配置为使用专用 IP 地址作为内部负载均衡器的
kubernetes-internal
前端 IP 地址配置。 有关详细信息,请参阅 配置 NGINX 入口控制器以支持具有应用程序路由加载项的 Azure 专用 DNS 区域。非托管 NGINX 入口控制器: 通过 Helm 安装非托管 NGINX 入口控制器。 部署脚本将非托管 NGINX 入口控制器配置为将专用 IP 地址用作内部负载均衡器的
kubernetes-internal
前端 IP 地址配置。 有关详细信息,请参阅使用内网 IP 地址创建入口控制器。
以下工作流与上图相对应:
安全工程师为工作负荷使用的自定义域生成证书,并将其保存在 Azure 密钥保管库中。 可以从已知 证书颁发机构获取有效的证书。
平台工程师在 Bicep 参数文件中指定必要的信息
main.bicepparams
,并部署 Bicep 模块来创建 Azure 资源。 必要的信息包括:Azure 资源的前缀。
保存工作负荷主机名和 Azure Front Door 自定义域的 TLS 证书的现有密钥保管库的名称和资源组。
密钥保管库中证书的名称。
用于解析 Azure Front Door 自定义域的 DNS 区域的名称和资源组。
部署脚本在 AKS 群集中创建以下对象:
如果使用非托管 NGINX 入口控制器 ,则通过 Helm 的 NGINX 入口控制器。
Kubernetes 入口 对象,用于通过 NGINX 入口控制器公开 Web 应用程序。
一种 SecretProviderClass 自定义资源,该资源使用密钥保管库提供程序的用户定义的托管标识从指定的密钥保管库中检索 TLS 证书,用于机密存储 CSI 驱动程序。 此组件创建一个 Kubernetes 机密,其中包含入口对象引用的 TLS 证书。
Azure Front Door 机密资源 用于管理和存储密钥保管库中的 TLS 证书。 此证书由与 Azure Front Door 终结点关联的自定义域使用。 Azure Front Door 配置文件使用具有 Key Vault 管理员 角色分配的用户分配托管标识从 Key Vault 检索 TLS 证书。
注意
在部署结束时,需要批准专用终结点连接,然后流量才能私下传输到源。 有关详细信息,请参阅在 Azure Front Door 高级版中使用专用链接保护源。 若要批准专用终结点连接,请使用 Azure 门户、Azure CLI 或 Azure PowerShell。 有关详细信息,请参阅管理专用终结点连接。
运行时工作流
以下步骤描述了外部客户端应用程序在运行时发起的请求的消息流。 此工作流对应于上图中的橙色数字。
客户端应用程序使用其自定义域向 Web 应用程序发送请求。 与自定义域关联的 DNS 区域会使用 CNAME 记录,将自定义域的 DNS 查询重定向到 Azure Front Door 终结点的原始主机名。
Azure Front Door 流量路由分为几个阶段。 一开始,请求会被发送到 Azure Front Door 接入点之一。 然后,Azure Front Door 会使用配置来确定流量的适当目标。 各种因素可能会影响路由过程,例如 Azure Front Door 缓存、Web 应用程序防火墙(WAF)、路由规则、规则引擎和缓存配置。 有关详细信息,请参阅路由体系结构概述。
Azure Front Door 会将传入请求转发到连接到专用链接服务的 Azure 专用终结点,而该服务会公开 AKS 托管的工作负荷。
请求被发送到专用链接服务。
请求会被转发到 kubernetes-internal AKS 内部负载均衡器。
请求将发送到托管托管或非托管 NGINX 入口控制器的 Pod 的代理节点之一。
其中一个 NGINX 入口控制器副本会处理请求。
NGINX 入口控制器会将请求转发给其中一个工作负荷 Pod。
组件
公共或专用 AKS 群集由以下节点池组成:
专用子网中的系统节点池。 默认节点池只托管关键系统 Pod 和服务。 系统节点具有节点排斥,因此无法在此节点池上计划应用程序 Pod。
在专用子网中托管用户工作负荷和项目的用户节点池。
部署需要 基于角色的访问控制(RBAC)角色分配,其中包括:
在 Azure Managed Grafana 上为 Microsoft Entra 用户分配 Grafana 管理员角色,而该用户的
objectID
在userId
参数中定义。 Grafana 管理员角色授予对实例的完全控制。 此控件包括管理角色分配和查看、编辑和配置数据源。 有关详细信息,请参阅如何共享对 Azure 托管 Grafana 的访问权限。在现有的密钥保管库资源上分配密钥保管库管理员角色,该资源包含用于机密存储 CSI 驱动程序的密钥保管库提供程序的用户定义托管身份的 TLS 证书。 此分配为 CSI 驱动程序提供访问权限,使其可以从源密钥保管库读取证书。
Azure Front Door Premium 是一个第 7 层全局负载均衡器和现代云内容分发网络。 它提供用户与应用程序全球静态和动态 Web 内容之间的快速、可靠和增强的安全访问。 可以使用 Azure Front Door 通过Microsoft全局边缘网络来传送内容。 该网络在世界各地设有数百个全球和本地接入点。 因此,可以使用靠近企业和消费者客户的接入点。
在此解决方案中,Azure Front Door 用于通过专用链接服务和 NGINX 入口控制器公开 AKS 托管的示例 Web 应用程序。 Azure Front Door 已配置为公开 Azure Front Door 终结点的自定义域。 自定义域被配置为使用 Azure Front Door 密钥,该密钥包含从密钥存储库读取的 TLS 证书。
Azure Web 应用程序防火墙可保护通过 Azure Front Door 公开的 AKS 托管应用程序免受常见的基于 Web 的攻击,如开放式 Web 应用程序安全项目 (OWASP) 漏洞、SQL 注入和跨站点脚本攻击。 这种云原生、即用即付的技术无需使用许可证。 Azure Web 应用程序防火墙可为 Web 应用程序提供保护,同时保护 Web 服务免受常见漏洞的攻击。
Azure DNS 区域用于 Azure Front Door 自定义域的名称解析。 可以使用 Azure DNS 来托管 DNS 域并管理 DNS 记录。
CNAME 记录用于创建从一个域名到另一个域名的别名或指针。 可以配置 CNAME 记录,将自定义域的 DNS 查询重定向到 Azure Front Door 终结点的原始主机名。
Text (TXT) 记录包含自定义域的验证令牌。 可以在 DNS 区域中使用 TXT 记录来存储与域名相关的任意文本信息。
配置了专用链接服务,以引用 AKS 集群的 kubernetes-internal 内部负载均衡器。 在 Azure Front Door 高级版中启用指向源的专用链接时,Azure Front Door 会从 Azure Front Door 托管的区域专用网络创建一个专用终结点。 你将在源处收到一个 Azure Front Door 专用终结点请求以供批准。 有关详细信息,请参阅在 Azure Front Door 高级版中使用专用链接保护源。
Azure 虚拟网络用于创建包含六个子网的单一虚拟网络:
SystemSubnet 用于系统节点池的代理节点。
UserSubnet 用于用户节点池的代理节点。
当 AKS 群集配置为使用具有动态 IP 地址分配的 Azure 内容网络接口时,PodSubnet 用于动态分配 Pod 的专用 IP 地址。
ApiServerSubnet 使用 API 服务器虚拟网络集成,将 API 服务器终结点直接投射到部署了 AKS 群集的此委托子网中。
AzureBastionSubnet 用于 Azure Bastion 主机。
VmSubnet 用于连接到专用 AKS 群集和专用终结点的跳转盒虚拟机(VM)。
AKS 群集使用用户分配的受管身份在 Azure 中创建更多资源,如负载均衡器和托管磁盘。
Azure 虚拟机 用于在 VM 子网中创建可选的跳转盒 VM。
Azure Bastion 主机部署在 AKS 群集虚拟网络中,以提供与 AKS 代理节点和 VM 的安全套接字外壳连接。
Azure 存储帐户用于存储服务提供商和服务消费者 VM 的启动诊断日志。 启动诊断是一项调试功能,可用于查看控制台输出和屏幕截图以诊断 VM 状态。
Azure 容器注册表用于生成、存储和管理容器映像及项目。
密钥保管库用于存储秘密、证书和密钥。 Pod 可以使用机密存储 CSI 驱动程序的密钥库提供程序来将机密、证书和密钥作为文件进行挂载。
有关详细信息,请参阅适用于机密存储 CSI 驱动程序的 Azure 密钥保管库提供程序和提供标识以访问适用于机密存储 CSI 驱动程序的密钥保管库提供程序。
在此项目中,现有的密钥保管库资源包含入口 Kubernetes 对象和 Azure Front Door 终结点的自定义域所使用的 TLS 证书。
为以下每个资源创建 Azure 专用终结点和 Azure 专用 DNS 区域:
- 容器注册表
- 密钥保管库
- 存储帐户
Azure 网络安全组(NSG) 用于筛选托管 VM 和 Azure Bastion 主机的子网的入站和出站流量。
Azure Monitor 工作区是 Monitor 收集的数据的唯一环境。 每个工作区都有其自己的数据存储库、配置和权限。 Azure Monitor 日志工作区包含来自多个 Azure 资源的日志和指标数据,而 Azure Monitor 工作区仅包含与 Prometheus 相关的指标。
可以使用基于 Prometheus 的 Prometheus 兼容监控解决方案,使用 Prometheus 的托管服务来大规模收集和分析指标。 可以使用 Prometheus 查询语言 (PromQL) 来分析受监控基础结构和工作负荷的性能并发出相关警报,而无需操作底层基础结构。
Azure 托管 Grafana 实例用于可视化部署了 Bicep 模块的 AKS 集群生成的 Prometheus 指标。 可以将 Monitor 工作区 连接到 Azure 托管 Grafana ,并使用一组内置和自定义 Grafana 仪表板来可视化 Prometheus 指标。 Grafana Enterprise 支持 Azure 托管 Grafana,后者提供可扩展的数据可视化效果。 可以快速轻松地部署具有内置高可用性的 Grafana 仪表板。 还可以使用 Azure 安全措施来控制对仪表板的访问。
Azure Monitor 日志工作区用于从 Azure 资源收集诊断日志和指标,其中包括:
- AKS 群集
- 密钥保管库
- Azure NSG
- 容器注册表
- 存储帐户
Bicep 部署脚本用于运行 Bash 脚本,该脚本在 AKS 群集中创建以下对象:
Kubernetes 入口 对象,用于通过 NGINX 入口控制器公开 Web 应用程序。
一种 SecretProviderClass 自定义资源,该资源使用密钥保管库提供程序的用户定义的托管标识从指定的密钥保管库中检索 TLS 证书,用于机密存储 CSI 驱动程序。 此组件创建一个 Kubernetes 机密,其中包含入口对象引用的 TLS 证书。
(可选)如果选择使用非托管 NGINX 入口控制器,则通过 Helm 进行 NGINX 入口控制器。
(可选) 证书管理器
(可选) Prometheus 和 Grafana
备选方法
要自动为 AKS 群集负载均衡器创建托管专用链接服务,可以使用专用链接服务功能。 要提供专用连接,必须为服务创建专用终结点连接。 可以使用批注通过专用链接服务来公开 Kubernetes 服务。 本文中的体系结构手动创建了一个专用链接服务,以引用群集 Azure 负载均衡器。
方案详细信息
此场景使用 Azure Front Door Premium、端到端 TLS 加密、Azure Web 应用程序防火墙和专用链接服务来安全地公开和保护在 AKS 中运行的工作负荷。
此体系结构使用 Azure Front Door TLS 和安全套接字层 (SSL) 卸载功能来终止 TLS 连接并解密 Front Door 上的传入流量。 流量在转发到源(即托管在 AKS 集群中的 Web 应用程序)之前会重新加密。 当 Azure Front Door 连接到配置为源的 AKS 托管工作负荷时,HTTPS 会被配置为 Azure Front Door 上的转发协议。 这种做法可对从客户端到源的整个请求过程强制进行端到端 TLS 加密。 有关详细信息,请参阅在 Azure Front Door 高级版中使用专用链接保护源。
NGINX 入口控制器会公开 AKS 托管的 Web 应用程序。 NGINX 入口控制器被配置为使用专用 IP 地址作为 kubernetes-internal
内部负载均衡器的前端 IP 配置。 NGINX 入口控制器使用 HTTPS 作为传输协议来公开 Web 应用程序。 有关详细信息,请参阅使用内网 IP 地址创建入口控制器。
AKS 群集被配置为使用以下功能:
API 服务器虚拟网络集成在 API 服务器和群集节点之间提供网络通信。 此功能不需要专用链接或隧道。 API 服务器可位于委托子网的内部负载均衡器 VIP 后面。 群集节点被配置为使用委托子网。 可以使用 API 服务器虚拟网络集成来帮助确保 API 服务器和节点池之间的网络流量仅保留在专用网络上。 集成了 API 服务器虚拟网络的 AKS 集群具有诸多优势。 例如,可以启用或禁用公用网络访问或专用群集模式,而无需重新部署群集。 有关详细信息,请参阅使用 API 服务器虚拟网络集成创建 AKS 群集。
Azure NAT 网关管理 AKS 托管工作负荷启动的出站连接。 有关详细信息,请参阅为 AKS 群集创建托管或用户分配的 NAT 网关。
可能的用例
此方案为在 AKS 中运行的 Web 应用程序或 REST API 提供了满足安全性和合规性要求的解决方案。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则,即一套可用于改进工作负荷质量的指导原则。 有关详细信息,请参阅 Well-Architected Framework。
以下一些注意事项与使用 Azure Front Door、Azure Web 应用程序防火墙和专用链接服务来提高 AKS 群集的安全性并不特别相关。 但是,对安全性、性能、可用性、可靠性、存储和监控的考虑是此解决方案的基本要求。
可靠性
可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息,请参阅可靠性设计评审核对清单。
这些建议对于单租户 AKS 解决方案至关重要,并不特定于多租户 AKS 解决方案,因为依赖于系统的用户数和工作负荷,可靠性目标更高。 请考虑以下建议,以优化 AKS 群集和工作负荷的可用性。
区域内复原
将 AKS 群集的节点池部署到区域内的所有可用性区域。
在容器注册表中启用区域冗余以实现地区内复原能力和高可用性。
使用拓扑分布约束来控制如何在地区、可用性区域和节点等故障域中将 Pod 分布到 AKS 集群。
为生产 AKS 集群使用标准层或高级层。 这些层包括运行时间服务级别协议 (SLA) 功能,该功能可保证使用可用性区域的集群的 Kubernetes API 服务器终结点达到 99.95% 的可用性,而不使用可用性区域的群集达到 99.9% 的可用性。 有关详细信息,请参阅 AKS 群集管理的免费、标准和高级定价层。
如果使用容器注册表来存储容器映像和 Oracle 云基础结构 (OCI) 项目,请启用区域冗余。 容器注册表支持可选的区域冗余和异地复制。 区域冗余为特定区域中的注册表或复制资源(如本)提供了复原能力和高可用性。 异地复制可在一个或多个 Azure 区域间复制注册表数据,以便为区域操作提供可用性并减少延迟。
灾难恢复和业务连续性
请考虑在两个区域部署解决方案。 将配对的 Azure 区域作为第二个区域。
在质量保证 (QA) 环境中编写脚本、记录并定期测试区域故障转移流程。
测试故障恢复程序,以验证其是否按预期运行。
将容器映像存储在容器注册表中。 将注册表异地复制到部署 AKS 解决方案的每个区域。
如果可能,请不要将服务状态存储在容器中。 相反,请将服务状态存储在支持多区域复制的 Azure 平台即服务 (PaaS) 存储解决方案中。 此方法提高了恢复能力,简化了灾难恢复,因为可以跨区域保存每个服务的关键数据。
如果使用存储,请准备和测试将存储从主要区域迁移到备份区域的过程。
安全性
安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息,请参阅可靠性设计审查检查表。
使用 WAF 保护 AKS 托管的 Web 应用程序和公开公共 HTTPS 终结点的服务。 你需要提供保护来防御 SQL 注入、跨站点脚本和其他 Web 攻击等常见威胁。 遵循 OWASP 规则和自己的自定义规则。 Web 应用程序防火墙为 Web 应用程序提供已改进的集中保护,使其免受常见攻击和漏洞的侵害。 可以使用 Azure 应用程序网关、 Azure Front Door 或 Azure 内容分发网络部署 Azure WAF。
使用 Azure DDoS 保护和应用程序设计最佳实践来抵御工作负荷分布式拒绝服务 (DDoS) 攻击。 Azure 可保护其基础结构和服务免受 DDoS 攻击。 此保护有助于确保区域、可用性区域和服务的可用性。 还应在第 4 层和第 7 层保护工作负荷的公共终结点免受 DDoS 攻击。 可以在外围虚拟网络上启用 Azure DDOS 防护。
使用 Azure Web 应用程序防火墙的 Azure Front Door 速率限制规则来管理和控制在定义的速率限制持续时间内允许从特定源 IP 地址向应用程序发出的请求数。 使用此功能有助于强制实施速率限制策略,并帮助确保应用程序免受过多流量或潜在滥用。 配置速率限制规则,以保持最佳的应用性能和安全性,并对请求限制进行精细控制。
将与 Azure Front Door 关联的 WAF 策略配置为防护模式。 在预防模式下,WAF 策略会分析传入的请求,并将其与配置的规则进行比较。 如果请求符合一个或多个规则,而这些规则被设置为拒绝流量,那么 WAF 策略就会阻止恶意流量到达 Web 应用程序。 此措施有助于确保对应用程序加以保护,防止潜在漏洞和未经授权的访问尝试。 有关详细信息,请参阅 Azure Front Door 上的 Web 应用程序防火墙。
为 AKS 工作负荷使用的任何 PaaS 服务创建 Azure 专用终结点,如密钥保管库、Azure 服务总线和 Azure SQL 数据库。 应用程序和这些服务之间的流量将不会暴露到公共 Internet 上。 AKS 群集虚拟网络与 PaaS 服务实例之间通过专用终结点传输的流量会经过 Microsoft 主干网络,但不会通过 Azure 防火墙。 专用终结点提供安全保护,防止数据泄露。 有关详细信息,请参阅 什么是专用链接?。
使用 Kubernetes 网络策略 来控制哪些组件可以相互通信。 此控制隔离并帮助保护服务内部通信。 默认情况下,Kubernetes 群集中的所有 Pod 都可以无限制地发送和接收流量。 要提高安全性,可以使用 Azure 网络策略或 Calico 网络策略来定义规则,控制不同微服务之间的通信流。 使用 Azure 网络策略来帮助强制实施网络级访问控制。 使用 Calico 网络策略在 AKS 集群中实施精细的网络分段和安全策略。 有关详细信息,请参阅在 AKS 中使用网络策略保护 Pod 之间的流量。
不公开到 AKS 节点的远程连接。 在管理虚拟网络中创建 Azure Bastion 主机或跳转盒。 使用 Azure Bastion 主机将流量路由到 AKS 群集。
请考虑在生产环境中使用专用 AKS 群集。 或者,至少在 AKS 中使用授权 IP 地址范围,以确保对 API 服务器的访问安全。 在公共群集上使用授权的 IP 地址范围时,允许 Azure 防火墙网络规则集合中的所有出口 IP 地址。 群集内操作使用 Kubernetes API 服务器。
成本优化
成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息,请参阅成本优化设计评审核对清单。
使用 群集自动缩放程序、 Kubernetes 事件驱动的自动缩放和 水平 Pod 自动缩放程序 根据流量条件缩放 Pod 和节点数。
为 Pod 设置适当的资源请求和限制,以优化资源分配并提高应用程序密度。 有关详细信息,请参阅 AKS 中资源管理的最佳做法。
使用 ResourceQuota 对象为命名空间中的内存和 CPU 使用量设置配额。 此配置有助于防止近邻干扰问题,提高应用程序密度。 有关详细信息,请参阅在命名空间中设置限制范围。
实现垂直 Pod 自动缩放程序以分析并设置 Pod 所需的 CPU 和内存资源。 此方法可以优化资源分配。
根据工作符合要求为节点池选择合适的 VM 大小。
为特定工作负荷创建具有不同 VM 大小的多个节点池。 使用节点标签、节点选择器和相关性规则来优化资源分配。
利用成本管理工具,例如 Azure 顾问、 Azure 预留和 Azure 节省计划 来监视和优化成本。
请考虑使用现成节点池,以利用 Azure 中未使用的容量并降低成本。
使用 Kubecost 等工具来监控和管理 AKS 成本。
使用 Azure 标记将 AKS 资源与特定工作负荷或租户相关联,以改进成本跟踪和管理。
有关详细信息,请参阅成本优化和优化 AKS 中的成本。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息,请参阅设计卓越运营的审查清单。
DevOps
使用持续集成和持续交付管道中的 Helm 图表将工作负载部署到 AKS。
在应用程序生命周期管理中使用 A/B 测试和 canary 部署,以便在应用程序可供所有用户使用之前对其进行适当测试。
使用 容器注册表 或非Microsoft注册表(例如 “港 ”或 “Docker 中心”)来存储部署到群集的专用容器映像。
在单独的预生产环境中测试工作负荷的入口和出口,该环境反映了生产环境的网络拓扑和防火墙规则。
监视
使用容器见解来监控 AKS 群集和工作负荷的运行状态。
通过使用基于 Cloud Native Compute Foundation 中的 Prometheus 项目的与 Prometheus 兼容的监控解决方案,使用适用于 Prometheus 的托管服务来大规模收集和分析指标。
将 Prometheus 的托管服务连接到 Azure 托管 Grafana 实例,将其用作 Grafana 仪表板中的数据源。 然后,可访问使用 Prometheus 指标的多个预生成的仪表板,并且能够创建自定义仪表板。
配置容器注册表和密钥存储库等所有 PaaS 服务,以便在 Azure Monitor 日志工作区中收集诊断日志和指标。
部署此方案
可在 GitHub 中获得该方案的源代码。 此开源解决方案根据 MIT 许可证来获得许可。
先决条件
一个有效的 Azure 订阅。 如果没有订阅,请在开始之前创建一个免费 Azure 帐户。
Visual Studio Code 和支持的平台之一上的 Bicep 扩展。
Azure CLI 2.58.0 或更高版本。 有关详细信息,请参阅安装 Azure CLI。
带有示例 Web 应用程序的有效 TLS 证书的现有密钥存储库资源。
现有 Azure DNS 区域,用于通过 CNAME 记录对 Azure Front Door 自定义域进行名称解析。
部署到 Azure
-
git clone https://github.com/Azure-Samples/aks-front-door-end-to-end-tls.git
按照 README 文件中的说明进行操作。 此步骤需要提供 Azure 订阅信息。
作者
Microsoft维护本文。 以下参与者撰写了本文。
主要作者:
- Paolo Salvatori | 首席服务工程师
要查看非公开的 LinkedIn 个人资料,请登录到 LinkedIn。
后续步骤
- AKS 群集最佳做法
- Azure Front Door 上的 Azure Web 应用程序防火墙
- 有关高级计划程序功能的最佳做法
- 身份验证和授权的最佳做法
- AKS 中有关基本计划程序功能的最佳做法
- AKS 中业务连续性和灾难恢复的最佳做法
- AKS 中有关群集安全性和升级的最佳做法
- AKS 中容器映像管理和安全性的最佳做法
- AKS 中网络连接和安全性的最佳做法
- AKS 中存储和备份的最佳做法
- Azure Front Door 的最佳做法
- 创建专用 AKS 群集
- Azure Front Door 中的源和源组
- 路由体系结构概述
- Azure Front Door 高级版中使用专用链接保护源
- 流量加速
- 了解 Azure Front Door 计费
- Azure Front Door 中的规则集是什么?
- 什么是 Azure Front Door?