大規模 Private Link 和 DNS 整合Private Link and DNS integration at scale

本文說明如何將 PaaS 服務的 Azure Private Link 與中樞和輪輻網路架構中的 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.

網際網路輸出連線是透過中央網路虛擬裝置提供 (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 database) 。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 Private Link 允許透過私人端點存取 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.

私人 DNS 區域通常會集中託管在部署中樞 VNet 的相同 Azure 訂用帳戶中。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 進行 Private Link 資源的名稱解析: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 區域 轉寄站設定條件轉寄站,指向 DNS 轉寄站 (10.100.2.4 ,並 10.100.2.5) 裝載于中樞 VNet 中。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.4 ,並 10.100.2.5) 設定為主要和次要 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.

有兩個條件必須為 true,才能讓應用程式小組自由地在其訂用帳戶中建立任何必要的 Azure PaaS 資源: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 服務,但相同的原則可以套用至 支援 Private Link 的大部分 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

依據 ,在中央連線訂用帳戶中為支援的 Private Link 服務建立私人 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. defaultAction 屬性,此屬性會定義是否允許來自公用網路的要求。For Azure Storage accounts, we look at the networkAcls.defaultAction property that defines whether requests from public network are allowed or not. 在我們的案例中,如果屬性 networkAcls. defaultAction 不是,我們會設定條件來拒絕建立 Microsoft. Storage/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 區域,因此我們必須防止應用程式小組擁有者建立自己的 Private Link 私人 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. 在我們的原則定義中,如果區域有前置詞,則會拒絕建立 Microsoft. Network/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是從遠端資源取得的群組識別碼, (服務) 此私人端點應連接到此群組。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 blob groupId 可以在本文的 Subresource 資料行) 下找到其他 Azure 服務的 Azure 儲存體 blob (。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 區域資源識別碼。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 區域資源識別碼會是: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. 請確定原則指派是以應用程式小組將使用的 Azure 訂用帳戶為目標,以獨佔方式部署具有私人端點存取權的 PaaS 服務。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 區域參與者角色 角色,此角色 DeployIfNotExists 指派 會負責建立及管理私人 dns 區域中的私人端點 DNS 記錄。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.