您现在访问的是微软AZURE全球版技术文档网站,若需要访问由世纪互联运营的MICROSOFT AZURE中国区技术文档网站,请访问 https://docs.azure.cn.

大规模专用链接和 DNS 集成Private Link and DNS integration at scale

本文介绍如何将适用于 PaaS 服务的 Azure 私有链接与中心和辐射网络体系结构中的 Azure 专用 DNS 区域集成。This article describes how to integrate Azure Private Link for PaaS services with Azure Private DNS zones in hub and spoke network architectures.

简介Introduction

许多客户使用中心和辐射网络体系结构在 Azure 中构建其网络基础结构,其中:Many customers build their network infrastructure in Azure using the hub and spoke network architecture, where:

  • 网络共享服务 (例如网络虚拟设备、ExpressRoute/VPN 网关或 DNS 服务器) 部署在 中心 虚拟网络 (VNet) Networking shared services (such as network virtual appliances, ExpressRoute/VPN gateways, or DNS servers) are deployed in the hub virtual network (VNet)
  • 轮辐 Vnet 通过 VNet 对等互连使用这些共享服务。Spoke VNets consume those shared services via VNet peering.

在中心和辐射网络体系结构中,应用程序所有者通常随 Azure 订阅一起提供,该订阅包含一个 VNet (辐射) 连接到 集线器 VNet。In hub and spoke network architectures, application owners are typically provided with an Azure subscription, which includes a VNet (a spoke) connected to the hub VNet. 在此体系结构中,他们可以通过 ExpressRoute 或 VPN 部署其虚拟机,并与其他 Vnet 或本地网络建立专用连接。In this architecture, they can deploy their virtual machines and have private connectivity to other VNets or to on-premises networks via ExpressRoute or VPN.

Internet-出站连接通过中央网络虚拟设备提供 (NVA) 例如 Azure 防火墙。Internet-outbound connectivity is provided via a central network virtual appliance (NVA) such as Azure Firewall.

许多应用程序团队使用 Azure IaaS 和 PaaS 资源的组合来构建其解决方案。Many application teams build their solutions using a combination of Azure IaaS and PaaS resources. 某些 Azure PaaS 服务 (例如 SQL 托管实例) 可以部署在客户 Vnet 中。Some Azure PaaS services (such as SQL Managed Instance) can be deployed in customer VNets. 因此,流量将在 Azure 网络中保持私密,并可从本地完全路由。As a result, traffic will stay private within the Azure network and would be fully routable from on-premises.

但是,某些 Azure PaaS 服务 ((例如 Azure 存储或 Azure Cosmos DB) )无法部署在客户的 Vnet 中,并且可通过其公共终结点进行访问。However, some Azure PaaS services (such as Azure Storage or Azure Cosmos DB) cannot be deployed in a customer's VNets and are accessible over their public endpoint. 在某些情况下,这可能会导致与客户的安全策略发生争用,因为公司流量可能不允许部署或访问企业资源 (如 SQL 数据库) 通过公共终结点。In some instances, this can cause a contention with a customer's security policies, as corporate traffic might not allow the deployment or accessing of corporate resources (such as a SQL database) over public endpoints.

Azure 专用链接 允许通过专用终结点访问 azure 服务列表 ,但要求在相应的 专用 DNS 区域中注册这些专用终结点记录。Azure Private Link allows access to a list of Azure services over private endpoints, but it requires that those private endpoint records are registered in a corresponding private DNS zone.

本文介绍应用程序团队如何可以在其订阅中部署 Azure PaaS 服务,这些服务只能通过专用终结点进行访问。This article describes how application teams can deploy Azure PaaS services in their subscriptions which are only accessible over private endpoints.

本文还将介绍应用程序团队如何通过 Azure 专用 DNS 确保服务与专用 DNS 区域自动集成。This article will also describe how application teams can ensure that services are automatically integrated with private DNS zones via Azure Private DNS. 无需在 DNS 中手动创建或删除记录。Removing the need for manual creation or deletion of records in DNS.

通常会在部署了中心 VNet 的同一 Azure 订阅中集中托管专用 DNS 区域。Private DNS zones are typically hosted centrally in the same Azure subscription where the hub VNet is deployed. 这种中心托管实践由 跨界 dns 名称解析 和对集中 dns 解析的其他需求(如 Active Directory)驱动。This central hosting practice is driven by cross-premises DNS name resolution and other needs for central DNS resolution such as Active Directory. 在大多数情况下,只有网络/标识管理员有权管理这些区域中的 DNS 记录。In most cases, only networking/identity admins have permissions to manage DNS records in these zones.

应用程序团队有权在自己的订阅中创建 Azure 资源。Application teams do have permissions to create Azure resource in their own subscription. 它们不具有中心网络连接订阅中的任何权限,包括管理专用 DNS 区域中的 DNS 记录。They do not have any permissions in the central networking connectivity subscription, which includes managing DNS records in the private DNS zones. 这种访问限制意味着它们不能在使用专用终结点部署 Azure PaaS 服务时 创建所需的 DNS 记录This access limitation means they do not have the possibility to create the DNS records required when deploying Azure PaaS services with private endpoints.

下图显示了一个典型的高级体系结构,适用于具有中心 DNS 解析的企业环境,以及可通过 Azure 专用 DNS 完成专用链接资源的名称解析:The following diagram shows a typical high-level architecture for enterprise environments with central DNS resolution and where name resolution for Private Link resources is done via Azure Private DNS:

映像-1

在前面的关系图中,重点强调:From the previous diagram, it is important to highlight that:

  • 本地 DNS 服务器的条件转发器配置为指向 DNS 转发器 (10.100.2.410.100.2.5 中心 VNet 中托管) 的每个专用终结点公用 dns 区域转发器。On-premises DNS servers have conditional forwarders configured for each private endpoint public DNS zone forwarder pointing to the DNS forwarders (10.100.2.4 and 10.100.2.5) hosted in the hub VNet.
  • 所有 Azure Vnet 都具有 DNS 转发器 (10.100.2.410.100.2.5) 配置为主 DNS 服务器和辅助 DNS 服务器。All Azure VNets have the DNS forwarders (10.100.2.4 and 10.100.2.5) configured as the primary and secondary DNS servers.

要使应用程序团队可以自由地在其订阅中创建任何所需的 Azure PaaS 资源,有两个条件必须为 true:There are two conditions that must be true to allow application teams the freedom to create any required Azure PaaS resources in their subscription:

  • 中心网络和/或中心平台团队必须确保应用程序团队只能通过专用终结点部署和访问 Azure PaaS 服务。Central networking and/or central platform team must ensure that application teams can only deploy and access Azure PaaS services via private endpoints.
  • 中央联网和/或中心平台团队必须确保在创建专用终结点时,会在与创建的服务匹配的集中式专用 DNS 区域中自动创建相应的记录。Central networking and/or central platform teams must ensure that whenever private endpoints are created, the corresponding records are automatically created in the centralized private DNS zone that matches the service created.
    • DNS 记录需要遵循专用终结点的生命周期,并在删除专用终结点时自动删除 DNS 记录。DNS record needs to follow the lifecycle of the private endpoint and automatically remove the DNS record when the private endpoint is deleted.

以下部分介绍应用程序团队如何使用 Azure 策略来启用这些条件。The following sections describe how application teams can enable these conditions by using Azure Policy. 在下面的示例中,我们将使用 Azure 存储作为应用程序团队需要部署的 Azure 服务,但同一原则适用于 支持 专用链接的大多数 Azure 服务。We will use Azure Storage as the Azure service that application teams need to deploy in our example below, but the same principle can be applied to most Azure services that support Private Link.

平台团队所需的配置Configuration required by platform team

创建专用 DNS 区域Create private DNS zones

按照 文档中的支持的私有链接服务的中心连接订阅创建专用 DNS 区域。Create private DNS zones in the central connectivity subscription for the supported Private Link services as per documentation.

在我们的示例中,由于我们将在示例中使用 存储帐户和 blob ,因此,我们将 privatelink.blob.core.windows.net 在连接订阅中创建专用 DNS 区域。In our case, as we will use Storage account with blob as our example, it translates to us creating a privatelink.blob.core.windows.net private DNS zone in the connectivity subscription.

图像-2

策略定义Policy definitions

除了专用 DNS 区域外,我们还需要 创建一组自定义的 Azure 策略定义 ,以强制使用专用终结点,并在创建的 dns 区域中自动创建 dns 记录:In addition to the private DNS zones, we also need to create a set of custom Azure Policy definitions to enforce the use of private endpoints and automate the DNS record creation in the DNS zone we created:

  1. 为 PaaS 服务策略 拒绝 公共终结点Deny public endpoint for PaaS services policy

    此策略将阻止用户使用公共终结点创建 Azure PaaS 服务,并在资源创建时为其提供错误消息。This policy will prevent users from creating Azure PaaS services with public endpoints and give them an error message if private endpoint is not selected at resource creation.

    图像-3

    映像-4

    图像-5

    PaaS 服务的确切策略规则可能不同。The exact policy rule may differ between PaaS services. 对于 Azure 存储帐户,请查看 networkAcls 属性,该属性定义是否允许来自公用网络的请求。For Azure Storage accounts, we look at the networkAcls.defaultAction property that defines whether requests from public network are allowed or not. 在我们的示例中,如果 networkAcls 属性 defaultAction 不是,我们会将条件设置为拒绝创建 storageAccounts/ 资源类型 DenyIn our case, we will set a condition to deny the creation of the Microsoft.Storage/storageAccounts resource type if the property networkAcls.defaultAction is not Deny. 此策略定义如下所示:This policy definition is listed below:

    {
      "mode": "All",
      "policyRule": {
        "if": {
          "allOf": [
            {
              "field": "type",
              "equals": "Microsoft.Storage/storageAccounts"
            },
            {
              "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
              "notequals": "Deny"
            }
          ]
        },
        "then": {
          "effect": "Deny"
        }
      }
    }
    
  2. 拒绝 使用前缀策略创建专用 DNS 区域 privatelinkDeny creation of a private DNS zone with the privatelink prefix policy

    由于我们使用的是包含条件转发器的集中式 DNS 体系结构和平台团队管理的订阅中托管的专用 DNS 区域,因此我们需要阻止应用程序团队所有者创建自己的专用链接专用 DNS 区域,并将服务链接到其订阅。Since we use a centralized DNS architecture with a conditional forwarder and private DNS zones hosted in the subscriptions managed by the platform team, we need to prevent the application teams owners from creating their own Private Link private DNS zones and linking services into their subscriptions.

    若要实现此目的,我们需要确保当应用程序团队创建专用终结点时,在 Integrate with private DNS zone 使用 Azure 门户时,必须将选项设置为 NoTo accomplish this, we need to ensure that when application teams create a private endpoint, the option to Integrate with private DNS zone must be set to No when using the Azure portal.

    图像-6

    如果 Yes 选择了,Azure 策略将阻止创建专用终结点。If Yes is selected, Azure Policy will prevent the creation of the private endpoint. 在策略定义中,如果区域具有前缀,则将拒绝创建 privateDnsZones/ 资源类型 privatelinkIn our policy definition, we will deny the creation of the Microsoft.Network/privateDnsZones resource type if the zone has the privatelink prefix. 此策略定义如下所述:This policy definition is described below:

    {
      "description": "This policy restricts creation of private DNS zones with the `privatelink` prefix",
      "displayName": "Deny-PrivateDNSZone-PrivateLink",
      "mode": "All",
      "parameters": null,
      "policyRule": {
        "if": {
          "allOf": [
            {
              "field": "type",
              "equals": "Microsoft.Network/privateDnsZones"
            },
            {
              "field": "name",
              "like": "privatelink*"
            }
          ]
        },
        "then": {
          "effect": "Deny"
        }
      }
    }
    
  3. DeployIfNotExists 策略,用于在中央专用 dns 区域中自动创建所需的 dns 记录DeployIfNotExists policy to automatically create the required DNS record in the central private DNS zone

    如果使用服务特定创建专用终结点资源,则会触发此策略 groupIdThis policy will be triggered if a private endpoint resource is created with a service-specific groupId. groupId是从此专用终结点应连接到的远程资源 (服务) 获取的组的 ID。The groupId is the ID of the group obtained from the remote resource (service) that this private endpoint should connect to. 然后 privateDNSZoneGroup ,在专用终结点内触发的部署,该终结点用于将专用终结点与专用 DNS 区域关联。We then trigger a deployment of a privateDNSZoneGroup within the private endpoint, which is used to associate the private endpoint with our private DNS zone. 在本示例中, groupId Azure 存储 blob 的 blob (groupId 可在本文中的 Subresource 列) 下 找到。For our example, the groupId for Azure Storage blobs is blob (groupId for other Azure services can be found on this article, under the Subresource column). 当策略发现 groupId 在专用终结点中创建时,它将在 privateDNSZoneGroup 专用终结点内部署,并将其链接到指定为参数的专用 DNS 区域资源 ID。When policy finds that groupId in the private endpoint created, it will deploy a privateDNSZoneGroup within the private endpoint, and it will be linked to the private DNS zone resource ID that is specified as parameter. 对于我们的示例,专用 DNS 区域资源 ID 将为:For our example, the private DNS zone resource ID would be:

    /subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net

    此策略定义如下所示:This policy definition is listed below:

    {
      "mode": "Indexed",
      "policyRule": {
        "if": {
          "allOf": [
            {
              "field": "type",
              "equals": "Microsoft.Network/privateEndpoints"
            },
            {
              "count": {
                "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
                "where": {
                  "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
                  "equals": "blob"
                }
              },
              "greaterOrEquals": 1
            }
          ]
        },
        "then": {
          "effect": "deployIfNotExists",
          "details": {
            "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
            "roleDefinitionIds": [
              "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
            ],
            "existenceCondition": {
              "allOf": [
                {
                  "field": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups/privateDnsZoneConfigs[*].privateDnsZoneId",
                  "equals": "[parameters('privateDnsZoneId')]"
                }
              ]
            },
            "deployment": {
              "properties": {
                "mode": "incremental",
                "template": {
                  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
                  "contentVersion": "1.0.0.0",
                  "parameters": {
                    "privateDnsZoneId": {
                      "type": "string"
                    },
                    "privateEndpointName": {
                      "type": "string"
                    },
                    "location": {
                      "type": "string"
                    }
                  },
                  "resources": [
                    {
                      "name": "[concat(parameters('privateEndpointName'), '/deployedByPolicy')]",
                      "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
                      "apiVersion": "2020-03-01",
                      "location": "[parameters('location')]",
                      "properties": {
                        "privateDnsZoneConfigs": [
                          {
                            "name": "storageBlob-privateDnsZone",
                            "properties": {
                              "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                            }
                          }
                        ]
                      }
                    }
                  ]
                },
                "parameters": {
                  "privateDnsZoneId": {
                    "value": "[parameters('privateDnsZoneId')]"
                  },
                  "privateEndpointName": {
                    "value": "[field('name')]"
                  },
                  "location": {
                    "value": "[field('location')]"
                  }
                }
              }
            }
          }
        }
      },
      "parameters": {
        "privateDnsZoneId": {
          "type": "String",
          "metadata": {
            "displayName": "privateDnsZoneId",
            "strongType": "Microsoft.Network/privateDnsZones"
          }
        }
      }
    }
    

策略分配Policy assignments

部署策略定义后, 将策略分配 到管理组层次结构中所需的作用域。Once policy definitions have been deployed, assign the policies at the desired scope in your management group hierarchy. 确保策略分配面向将由应用程序团队用来部署 PaaS 服务的 Azure 订阅,以独占方式访问专用终结点。Ensure that the policy assignments target the Azure subscriptions that will be used by the application teams to deploy PaaS services with private endpoint access exclusively.

重要

请记住,将专用 DNS 区域的订阅/资源组中的 专用 DNS 区域参与者角色 角色分配给将负责创建和管理专用 dns 区域中的专用终结点 DNS 记录的 DeployIfNotExists 策略分配所创建的托管标识Remember to assign the Private DNS Zone Contributor role role in the subscription/resource group where the private DNS zones are hosted to the managed identity created by the DeployIfNotExists policy assignment that will be responsible to create and manage the private endpoint DNS record in the private DNS zone. 这是因为专用终结点位于应用程序所有者 Azure 订阅中,而专用 DNS 区域位于不同的订阅中 (如中心连接订阅) 。This is because the private endpoint is located in the application owner Azure subscription, while the private DNS zone is located in a different subscription (such as central connectivity subscription).

一旦平台团队完成此配置,来自应用程序团队的 Azure 订阅便可供他们使用专用终结点访问权限来创建 Azure PaaS 服务,并确保在从相应的专用 DNS 区域) 删除专用终结点后,将自动注册 (和删除的专用终结点的 DNS 记录。Once the platform team finishes this configuration, Azure subscriptions from applications teams are ready for them to create Azure PaaS services with private endpoint access exclusively, and ensuring the DNS records for private endpoints are automatically registered (and removed once private endpoint is deleted) from corresponding private DNS zones.

应用程序所有者体验Application owner experience

平台团队部署了平台基础结构组件后 (上一部分中所述的专用 DNS 区域和策略) 当应用程序所有者尝试将 Azure PaaS 服务部署到 Azure 订阅时,应用程序所有者将具有以下体验,如果它们通过 Azure 门户或其他客户端(如 PowerShell 或 CLI)执行活动,则该应用程序所有者将是相同的,因为它们的订阅受 Azure 策略的控制。Once the platform team has deployed the platform infrastructure components (private DNS zones and policies) described in the previous section, when an application owner tries to deploy an Azure PaaS service into the Azure subscription, the application owner will have the following experience, which will be the same if they do activities via the Azure portal or via other clients such as PowerShell or CLI, as their subscriptions are being governed by Azure policies.

  1. 通过 Azure 门户创建存储帐户。Create a storage account through the Azure portal. 在 "基本" 选项卡中,提供名称和所需的设置,然后单击 " 下一步"。In the basic tab, provide a name and your desired settings and click on Next.

    图像-7

  2. 在 "网络" 部分中,确保选择 " 专用终结点 "。In the networking section, ensure Private endpoint is selected. 如果选择了 " 专用终结点 以外的选项",则在部署向导的 " 查看 + 创建 " 部分中,Azure 门户将不允许创建存储帐户,因为如果启用了公共终结点,则策略阻止创建此服务。If an option other than Private endpoint is selected, the Azure portal will not allow the creation of the storage account in the Review + create section of the deployment wizard, as policy is preventing the creation of this service if the public endpoint is enabled.

    图像-8

  3. 可以在此屏幕上创建专用终结点,也可以在创建存储帐户之后完成此操作。It is possible to create the private endpoint on this screen or it can be done after the storage account has been created. 对于本练习,我们将在创建存储帐户后创建专用终结点。For this exercise, we will create the private endpoint after the storage account has been created. 单击 " 查看" + 创建 并完成存储帐户的创建。Click on Review + create and complete the creation of the storage account.

  4. 创建存储帐户后,通过 Azure 门户创建专用终结点Once the storage account is created, create a private endpoint through the Azure portal

    映像-9

  5. 在 " 资源 " 部分中,找到在上一步中创建的存储帐户,对于 "目标 subresource",选择 " Blob",然后选择 " 下一步"。In the Resource section, locate the storage account created in the previous step, and for target subresource select Blob, and then select Next.

    映像-10

  6. 在 " 配置 " 部分中,选择 VNet 和子网后,确保 " 与专用 DNS 区域集成 " 设置为 " "。In the Configuration section, after selecting your VNet and subnet, ensure that Integrate with private DNS zone is set to No. 否则,Azure 门户会阻止创建专用终结点,因为 Azure 策略将不允许创建带有前缀的专用 DNS 区域 privatelinkOtherwise, the Azure portal will prevent the creation of the private endpoint, as Azure Policy will not allow the creation of a private DNS zone with the privatelink prefix.

    图像-11

  7. 依次选择 " 查看" 和 "创建",然后选择 " 创建 " 以部署专用终结点。Select Review + create, and then select Create to deploy the private endpoint.

  8. 几分钟后, DeployIfNotExists 将触发策略,后续 dnsZoneGroup 部署将为集中管理的 dns 区域中的专用终结点添加所需的 DNS 记录。After a few minutes, the DeployIfNotExists policy will be triggered and the subsequent dnsZoneGroup deployment will add the required DNS records for the private endpoint in the centrally managed DNS zone.

  9. 创建专用终结点后,将其选中,并查看其 FQDN 和专用 IP:Once the private endpoint has been created, select it, and review its FQDN and private IP:

    图像-12

  10. 检查在其中创建了专用终结点的资源组的活动日志,或者可以检查专用终结点自身的活动日志。Check the activity log for the resource group where the private endpoint was created, or you can check the activity log of the private endpoint itself. 你会注意到,在几分钟后,将 DeployIfNotExist 执行一个策略操作,该操作将在专用终结点上配置 DNS 区域组:You will notice that after a few minutes, a DeployIfNotExist policy action is executed, which configures the DNS zone group on the private endpoint:

    图像-13

  11. 如果中央网络团队转到 privatelink.blob.core.windows.net 专用 DNS 区域,它们将确认已为我们创建的专用终结点创建了 DNS 记录,并且名称和 IP 地址与专用终结点中的值匹配。If the central networking team goes to the privatelink.blob.core.windows.net private DNS zone, they will confirm that the DNS record has been created for the private endpoint we created, and both the name and IP address match to the values within the private endpoint.

    映像-14

此时,应用程序团队可以通过中心和辐射网络环境中的任何 VNet 中的专用终结点使用存储帐户,也可以从本地使用存储帐户,因为 DNS 记录已自动记录到专用 DNS 区域中。At this point, application teams can use the storage account via a private endpoint from any VNet in the hub and spoke network environment and from on-premises, as the DNS record has been automatically recorded in the private DNS zone.

如果应用程序所有者删除了专用终结点,则会自动删除专用 DNS 区域中的相应记录。If an application owner deletes the private endpoint, the corresponding records in the private DNS zone will automatically be removed.