Integracja usługi Private Link i DNS na dużą skalę

Artykuł
2025-01-10

W tym artykule opisano, jak zintegrować usługę Azure Private Link dla rozwiązań typu „platforma jako usługa” (PaaS), które mają prywatne strefy DNS platformy Azure w architekturach sieci typu hub-and-spoke.

Wprowadzenie

Wielu klientów buduje infrastrukturę sieciową na platformie Azure, korzystając z architektury sieci gwiaździstej, gdzie:

Usługi sieciowe udostępniane, takie jak wirtualne urządzenia sieciowe (WUS), bramy usługi ExpressRoute/VPN lub serwery DNS, są wdrażane w sieci wirtualnej węzłowej.
Przyporządkowane sieci wirtualne korzystają z usług udostępnionych za pośrednictwem peerowania sieci wirtualnych.

W architekturach sieci piasty i szprych właściciele aplikacji zazwyczaj mają subskrypcję platformy Azure, która obejmuje sieć wirtualną (szprychę) połączoną z siecią wirtualną piasty . W tej architekturze mogą wdrażać swoje maszyny wirtualne i mieć prywatną łączność z innymi sieciami wirtualnymi lub sieciami lokalnymi za pośrednictwem usługi ExpressRoute lub sieci VPN.

Centralne urządzenie WUS, takie jak Usługa Azure Firewall, zapewnia łączność wychodzącą z Internetu. Ponadto to urządzenie, w połączeniu z inną usługą, na przykład serwer proxy DNS usługi Azure Firewall, znajduje się w centrum lub w pobliżu tego centrum, jest zwykle używane do dostosowywania przekazywania DNS.

Wiele zespołów aplikacji tworzy swoje rozwiązania przy użyciu kombinacji zasobów IaaS i PaaS platformy Azure. Niektóre usługi PaaS platformy Azure, takie jak Azure SQL Managed Instance, można wdrożyć w sieciach wirtualnych klienta. W związku z tym ruch pozostaje prywatny w sieci platformy Azure i jest w pełni trasowalny ze środowiska lokalnego.

Jednak niektóre usługi PaaS platformy Azure, takie jak Azure Storage lub Azure Cosmos DB, nie mogą być wdrażane w sieciach wirtualnych klienta i są dostępne za pośrednictwem publicznego punktu końcowego. W niektórych przypadkach ta konfiguracja powoduje rywalizację z zasadami zabezpieczeń klienta. Ruch firmowy może nie zezwalać na wdrażanie lub dostęp do zasobów firmy, takich jak baza danych SQL, za pośrednictwem publicznych punktów końcowych.

Usługa Private Link obsługuje dostęp do listy usług platformy Azure za pośrednictwem prywatnych punktów końcowych, ale wymaga zarejestrowania tych prywatnych rekordów punktu końcowego w odpowiedniej prywatnej strefie DNS.

W tym artykule opisano, jak zespoły aplikacji mogą wdrażać usługi Azure PaaS w swoich subskrypcjach, które są dostępne tylko za pośrednictwem prywatnych punktów końcowych.

W tym artykule opisano również, w jaki sposób zespoły aplikacji mogą zapewnić, że usługi automatycznie integrują się z prywatnymi strefami DNS. Wykonują one automatyzację za pośrednictwem prywatnej usługi Azure DNS, co eliminuje konieczność ręcznego tworzenia lub usuwania rekordów w systemie DNS.

Integracja usługi Private Link i DNS w architekturach sieci piasty i szprych

Prywatne strefy DNS są zazwyczaj hostowane centralnie w tej samej subskrypcji Azure, w której wdrażana jest sieć wirtualna hubu. Ta centralna praktyka hostingu jest oparta na rozpoznawaniu nazw DNS między sieciami lokalnymi oraz inne potrzeby centralnego rozpoznawania nazw DNS, na przykład Windows Server Active Directory. W większości przypadków tylko administratorzy sieci i tożsamości mają uprawnienia do zarządzania rekordami DNS w strefach.

Zespoły aplikacji mają uprawnienia do tworzenia zasobu platformy Azure we własnej subskrypcji. Nie mają żadnych uprawnień w centralnej subskrypcji łączności sieciowej, która obejmuje zarządzanie rekordami DNS w prywatnych strefach DNS. To ograniczenie dostępu oznacza, że nie mają możliwości tworzenia rekordów DNS wymaganych podczas wdrażania usług PaaS platformy Azure z prywatnymi punktami końcowymi.

Na poniższym diagramie przedstawiono typową architekturę wysokiego poziomu dla środowisk przedsiębiorstwa z centralnym rozpoznawaniem nazw DNS i rozpoznawaniem nazw dla zasobów usługi Private Link za pośrednictwem usługi Azure Private DNS:

Na poprzednim diagramie ważne jest, aby podkreślić, że:

Lokalne serwery DNS mają warunkowe przekierowania skonfigurowane dla każdej publicznej strefy DNS dla prywatnego punktu końcowego, wskazujące na prywatny resolver DNS hostowany w sieci wirtualnej koncentratora.
Prywatny resolver DNS hostowany w sieci wirtualnej koncentratora używa udostępnionego przez platformę Azure resolvera DNS (168.63.129.16) jako forwardera.
Sieć wirtualna węzła musi być połączona z nazwami prywatnych stref DNS dla usług Azure, takich jak privatelink.blob.core.windows.net, jak pokazano na diagramie.
Wszystkie sieci wirtualne usługi platformy Azure używają prywatnego resolvera DNS hostowanego w sieci wirtualnej koncentratora.
Prywatny program rozpoznawania nazw DNS nie jest autorytatywny dla domen firmowych klienta, takich jak nazwy domen usługi Active Directory, ponieważ jest to tylko usługa przesyłania dalej. Prywatny resolver DNS powinien mieć przekierowania wychodzących punktów końcowych dla domen korporacyjnych klienta, wskazujące na lokalne serwery DNS (172.16.1.10 i 172.16.1.11) lub serwery DNS wdrożone na platformie Azure, które są autorytatywnymi dla takich stref.

Uwaga

Prywatny resolver DNS można wdrożyć w sieci wirtualnej centrum obok bramy ExpressRoute. Należy jednak upewnić się, że rozpoznawanie publicznych nazw FQDN jest dozwolone i odpowiada z prawidłową odpowiedzią za pośrednictwem reguły zestawu reguł przekazywania DNS do docelowego serwera DNS. Niektóre usługi platformy Azure polegają na możliwości rozpoznawania publicznych nazw DNS do działania. Aby uzyskać więcej informacji, zobacz zestaw reguł przesyłania dalej DNS.

Chociaż poprzedni diagram przedstawia pojedynczą architekturę piasty i szprych, klienci mogą potrzebować rozszerzenia zasięgu platformy Azure w wielu regionach, aby spełnić wymagania dotyczące odporności, zbliżenia lub rezydencji danych. W kilku scenariuszach dostęp do tego samego wystąpienia PaaS obsługującego Private Link musi być uzyskiwany poprzez wiele prywatnych punktów końcowych.

Na poniższym diagramie przedstawiono typową architekturę wysokiego poziomu dla środowisk przedsiębiorstwa, które mają centralne rozpoznawanie nazw DNS wdrożone w centrum (jeden dla każdego regionu), gdzie rozpoznawanie nazw dla zasobów usługi Private Link odbywa się za pośrednictwem usługi Azure Private DNS.

Należy wdrożyć wiele regionalnych prywatnych punktów końcowych skojarzonych z wystąpieniem usługi PaaS, po jednym w każdym regionie, w którym istnieją klienci. Włącz usługi Private Link i prywatne strefy DNS dla każdego regionu. W przypadku pracy z usługami PaaS, które mają wbudowane funkcje odzyskiwania po awarii, takie jak konta magazynu z nadmiarowością geograficzną i grupy przełączania awaryjnego bazy danych SQL, musisz mieć prywatne punkty końcowe w różnych regionach.

Ten scenariusz wymaga ręcznej konserwacji i aktualizacji zestawu rekordów DNS usługi Private Link w każdym regionie, ponieważ nie ma obecnie zautomatyzowanego zarządzania cyklem życia.

W przypadku innych przypadków użycia można wdrożyć jeden globalny prywatny punkt końcowy, dzięki czemu będzie dostępny dla wszystkich klientów, dodając routing z odpowiednich regionów do pojedynczego prywatnego punktu końcowego w jednym regionie.

Aby włączyć rozpoznawanie i w związku z tym łączność, z sieci lokalnych do privatelink prywatnej strefy DNS i prywatnych punktów końcowych, należy aprowizować odpowiednią konfigurację DNS, taką jak usługi przesyłania dalej warunkowego, w infrastrukturze DNS.

Dwa warunki, które muszą być spełnione, aby zespoły aplikacji mogły utworzyć wszystkie wymagane zasoby usługi Azure PaaS w ramach subskrypcji:

Centralna sieć lub centralne zespoły ds. platformy muszą upewnić się, że zespoły aplikacji mogą wdrażać usługi PaaS platformy Azure i uzyskiwać do ich dostępu tylko za pośrednictwem prywatnych punktów końcowych.
Centralna sieć lub centralne zespoły ds. platform muszą upewnić się, że podczas tworzenia prywatnych punktów końcowych konfigurują sposób obsługi odpowiednich rekordów. Skonfiguruj odpowiednie rekordy, aby były automatycznie tworzone w scentralizowanej prywatnej strefie DNS zgodnej z tworzoną usługą.
Rekordy DNS muszą być zgodne z cyklem życia prywatnego punktu końcowego, aby rekordy zostały automatycznie usunięte po usunięciu prywatnego punktu końcowego.

Uwaga

W oparciu o rozpoznawanie nazw DNS, jeśli potrzebujesz nazw FQDN w regułach sieciowych dla zasad usługi Azure Firewall i usługi Azure Firewall, włącz serwer proxy DNS usługi Azure Firewall, aby używać nazw FQDN w regułach sieci. Następnie sieci wirtualne będące szprychami muszą zmienić ich ustawienie DNS z niestandardowego serwera DNS na serwer proxy DNS usługi Azure Firewall. Nazwy FQDN w regułach sieci umożliwiają filtrowanie ruchu wychodzącego przy użyciu dowolnego protokołu TCP lub UDP, w tym NTP, SSH i RDP. Po zmianie ustawień DNS sieci wirtualnej będącej szprychą należy ponownie uruchomić wszystkie maszyny wirtualne w tej sieci wirtualnej.

W poniższych sekcjach opisano sposób włączania tych warunków przez zespoły aplikacji przy użyciu usługi Azure Policy. W tym przykładzie usługa Azure Storage jest używana jako usługa platformy Azure, którą zespoły aplikacji muszą wdrożyć. Jednak ta sama zasada dotyczy większości usług platformy Azure, które obsługują usługę Private Link.

Wymagania dotyczące konfiguracji zespołu platformy

Wymagania dotyczące konfiguracji zespołu platformy obejmują tworzenie prywatnych stref DNS, konfigurowanie definicji zasad, wdrażanie zasad i konfigurowanie przypisań zasad.

Tworzenie prywatnych stref DNS

Utwórz prywatne strefy DNS w centralnej subskrypcji łączności dla obsługiwanych usług Private Link. Aby uzyskać więcej informacji, zobacz Konfiguracja usługi DNS prywatnego punktu końcowego platformy Azure.

W tym przypadku przykładowe jest konto magazynu z obiektem blob . Przekłada się na utworzenie privatelink.blob.core.windows.net prywatnej strefy DNS w subskrypcji łączności.

Zrzut ekranu przedstawiający prywatną strefę DNS w subskrypcji łączności.

Tworzenie definicji zasad

Oprócz prywatnych stref DNS należy również utworzyć zestaw niestandardowych definicji usługi Azure Policy. Te definicje wymuszają korzystanie z prywatnych punktów końcowych i automatyzują tworzenie rekordu DNS w utworzonej strefie DNS:

Deny Publiczny punkt końcowy dla zasad usług PaaS.

Te zasady uniemożliwiają użytkownikom tworzenie usług PaaS platformy Azure z publicznymi punktami końcowymi.

Użytkownicy otrzymują komunikat o błędzie, jeśli nie wybierają prywatnego punktu końcowego podczas tworzenia zasobu.

Dokładna reguła zasad może się różnić między usługami PaaS. W przypadku kont usługi Azure Storage właściwość networkAcls.defaultAction określa, czy żądania z sieci publicznych są dozwolone, czy nie. W takim przypadku ustaw warunek odmowy tworzenia zasobu typu Microsoft.Storage/storageAccounts, jeśli właściwość networkAcls.defaultAction nie jest równa Deny. Poniższa definicja zasad pokazuje zachowanie:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny możliwość utworzenia prywatnej strefy DNS z polityką prefiksu privatelink.

Użyj scentralizowanej architektury DNS z warunkowym przekazaniem i prywatnymi strefami DNS hostowanymi w subskrypcjach zarządzanych przez zespół platformy. Należy uniemożliwić właścicielom zespołów aplikacji tworzenie własnych prywatnych stref DNS usługi Private Link i łączenie usług z subskrypcjami.

Upewnij się, że gdy zespół aplikacji utworzy prywatny punkt końcowy, opcja Integrate with private DNS zone jest ustawiona na No w portalu Azure.

W przypadku wybrania opcji Yesusługa Azure Policy uniemożliwia utworzenie prywatnego punktu końcowego. W definicji zasad odmawia możliwości utworzenia typu zasobu Microsoft.Network/privateDnsZones , jeśli strefa ma privatelink prefiks. Poniższa definicja zasad przedstawia privatelink prefiks:
```
{
  "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",
          "contains": "privatelink."
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
DeployIfNotExists zasady do automatycznego tworzenia wymaganego rekordu DNS w centralnej prywatnej strefie DNS.

W poniższych przykładach zasad przedstawiono dwa podejścia do identyfikowania, który privateDNSZoneGroup został utworzony w prywatnym punkcie końcowym.

Pierwsza zasada opiera się na groupId, podczas gdy druga zasada używa zarówno privateLinkServiceId i groupID. Użyj drugiej polityki, gdy groupId ściera się lub koliduje z innym zasobem.

Na przykład groupId język SQL jest używany zarówno dla usługi Azure Cosmos DB, jak i usługi Azure Synapse Analytics. Jeśli oba typy zasobów są wdrażane, a pierwsze zasady zostały przypisane do utworzenia privateDNSZoneGroup wpisu prywatnego punktu końcowego, zostanie on utworzony i zamapowany na niepoprawną prywatną strefę DNS usługi Azure Cosmos DB lub Azure Synapse Analytics. Następnie może przełączać się między poszczególnymi strefami ze względu na starcie groupId , że pierwsza zasada szuka w regule zasad.

Aby uzyskać listę groupId zasobów Private Link, zobacz kolumnę podzasobów w temacie Co to jest prywatny punkt końcowy?.

Wskazówka

Wbudowane definicje usługi Azure Policy są stale dodawane, usuwane i aktualizowane. Należy używać wbudowanych zasad zamiast zarządzać własnymi zasadami, jeśli są dostępne. Użyj modułu AzPolicyAdvertizer, aby znaleźć istniejące wbudowane polityki o następującej nazwie "xxx ... do użytku z prywatnymi strefami DNS". Ponadto strefy docelowe platformy Azure (ALZ) mają inicjatywę zasad Konfigurowanie usług PaaS platformy Azure pod kątem używania prywatnych stref DNS, które zawierają wbudowane zasady, które są okresowo aktualizowane. Jeśli wbudowane zasady nie są dostępne w Twojej sytuacji, rozważ utworzenie pomysłu azure-policy w witrynie zarządzania platformy Azure w witrynie zarządzania platformy Azure , postępując zgodnie z wbudowanym procesem propozycji zasad w repozytorium GitHub usługi Azure Policy.

Zasada DeployIfNotExists tylko dla identyfikatora groupId

Te zasady są wyzwalane, jeśli tworzysz zasób prywatnego punktu końcowego, który ma specyficzny dla groupIdusługi . Jest to groupId, czyli identyfikator grupy uzyskanej z zasobu zdalnego (usługi), z którą ten prywatny punkt końcowy powinien się połączyć. Następnie wyzwala wdrożenie privateDNSZoneGroup w prywatnym punkcie końcowym, który kojarzy prywatny punkt końcowy z prywatną strefą DNS. W tym przykładzie groupId w usłudze Azure Storage dla obiektów blob jest blob. Aby uzyskać więcej informacji na temat groupId innych usług platformy Azure, zobacz kolumnę Subresource w konfiguracji dns prywatnego punktu końcowego platformy Azure. Gdy zasady znajdzie element groupId w prywatnym punkcie końcowym, wdraża element privateDNSZoneGroup w prywatnym punkcie końcowym i łączy go z identyfikatorem zasobu prywatnej strefy DNS określonym jako parametr. W tym przykładzie identyfikator zasobu prywatnej strefy DNS to:

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

Poniższy przykładowy kod przedstawia definicję zasad:

{
  "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/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "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"
      }
    }
  }
}

Zasady DeployIfNotExists dla identyfikatorów groupId i privateLinkServiceId

Ta polityka jest uruchamiana, jeśli tworzysz zasób prywatnego punktu końcowego z konkretną usługą groupId i privateLinkServiceId. groupId to identyfikator grupy uzyskanej z zasobu zdalnego (usługi), do którego ten prywatny punkt końcowy powinien nawiązać połączenie. Identyfikator zasobu zdalnego (usługi) privateLinkServiceId to identyfikator, z którym ten prywatny punkt końcowy powinien się połączyć. Następnie rozpocznij wdrażanie privateDNSZoneGroup w prywatnym punkcie dostępowym, który integruje prywatny punkt dostępowy z prywatną strefą DNS.

W tym przykładzie element groupId dla usługi Azure Cosmos DB (SQL) to SQL , a element privateLinkServiceId musi zawierać wartość Microsoft.DocumentDb/databaseAccounts. Aby uzyskać więcej informacji o groupId usługach i privateLinkServiceId dla innych usług platformy Azure, zobacz kolumnę Subresource w konfiguracji dns prywatnego punktu końcowego platformy Azure. Gdy zasada znajdzie groupId i privateLinkServiceId w prywatnym punkcie końcowym, wdroży element privateDNSZoneGroup w prywatnym punkcie końcowym. Jest ona połączona z identyfikatorem zasobu prywatnej strefy DNS określonym jako parametr. Poniższa definicja zasad przedstawia identyfikator zasobu prywatnej strefy DNS:

/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com

Poniższy przykładowy kod przedstawia definicję zasad:

{
  "mode": "Indexed",
  "policyRule": {
    "if": {
     "allOf": [
       {
         "field": "type",
         "equals": "Microsoft.Network/privateEndpoints"
       },
       {
         "count": {
           "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*]",
           "where": {
             "allOf": [
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].privateLinkServiceId",
                 "contains": "Microsoft.DocumentDb/databaseAccounts"
               },
               {
                 "field": "Microsoft.Network/privateEndpoints/privateLinkServiceConnections[*].groupIds[*]",
                 "equals": "[parameters('privateEndpointGroupId')]"
               }
             ]
           }
         },
         "greaterOrEquals": 1
       }
     ]
   },
    "then": {
      "effect": "[parameters('effect')]",
      "details": {
        "type": "Microsoft.Network/privateEndpoints/privateDnsZoneGroups",
        "roleDefinitionIds": [
          "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7"
        ],           
        "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": "cosmosDB-privateDnsZone",
                        "properties": {
                          "privateDnsZoneId": "[parameters('privateDnsZoneId')]"
                        }
                      }
                    ]
                  }
                }
              ]
            },
            "parameters": {
              "privateDnsZoneId": {
                "value": "[parameters('privateDnsZoneId')]"
              },
              "privateEndpointName": {
                "value": "[field('name')]"
              },
              "location": {
                "value": "[field('location')]"
              }
            }
          }
        }
      }
    }
  },
  "parameters": {
     "privateDnsZoneId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Dns Zone Id",
         "description": "The private DNS zone to deploy in a new private DNS zone group and link to the private endpoint",
         "strongType": "Microsoft.Network/privateDnsZones"
       }
     },
     "privateEndpointGroupId": {
       "type": "String",
       "metadata": {
         "displayName": "Private Endpoint Group Id",
         "description": "A group Id for the private endpoint"
       }
     },
     "effect": {
       "type": "String",
       "metadata": {
         "displayName": "Effect",
         "description": "Enable or disable the execution of the policy"
       },
       "allowedValues": [
         "DeployIfNotExists",
         "Disabled"
       ],
       "defaultValue": "DeployIfNotExists"
     }
  }
}

Przypisania zasad

Po wdrożeniu definicji zasad przypisz zasady w żądanym zakresie w hierarchii grup zarządzania. Upewnij się, że przypisania zasad są przeznaczone dla subskrypcji platformy Azure używanych przez zespoły aplikacji do wdrażania usług PaaS z dostępem do prywatnego punktu końcowego wyłącznie.

Ważne

Oprócz przypisania definicji roli zdefiniowanej w zasadach, przypisz rolę współautora prywatnej strefy DNS do tożsamości zarządzanej utworzonej DeployIfNotExists przez przypisanie zasad. Tę rolę należy przypisać w subskrypcji i grupie zasobów, w której są hostowane prywatne strefy DNS. Tożsamość zarządzana tworzy rekord DNS prywatnego punktu końcowego i zarządza nim w prywatnej strefie DNS. Ta konfiguracja jest niezbędna, ponieważ prywatny punkt końcowy znajduje się w subskrypcji platformy Azure właściciela aplikacji, podczas gdy prywatna strefa DNS znajduje się w innej subskrypcji, takiej jak centralna subskrypcja łączności.

Po zakończeniu konfiguracji przez zespół platformy:

Subskrypcje platformy Azure zespołów odpowiedzialnych za aplikacje są przygotowane do tworzenia usług PaaS w platformie Azure, które mają dostęp wyłącznie do prywatnych punktów końcowych.
Zespół musi upewnić się, że rekordy DNS dla prywatnych punktów końcowych są automatycznie rejestrowane w odpowiednich prywatnych strefach DNS i że rekordy DNS są usuwane po usunięciu prywatnego punktu końcowego.

Właściciel aplikacji wdraża usługę PaaS platformy Azure

Po wdrożeniu składników infrastruktury platformy (prywatnych stref i zasad DNS) właściciel aplikacji wykonuje następujące kroki podczas próby wdrożenia usługi Azure PaaS w ramach subskrypcji platformy Azure. Te kroki są takie same, czy wykonują swoje działania za pośrednictwem witryny Azure Portal, czy innych klientów, takich jak program PowerShell lub interfejs wiersza polecenia, ponieważ zasady platformy Azure zarządzają subskrypcjami.

Utwórz konto magazynowe za pośrednictwem Azure Portal. Na karcie Podstawowe wybierz żądane ustawienia, podaj nazwę konta magazynu, a następnie wybierz pozycję Dalej.
Na karcie Sieć wybierz pozycję Prywatny punkt końcowy. Jeśli wybierzesz opcję inną niż prywatny punkt końcowy, portal Azure nie zezwala na tworzenie konta magazynu w sekcji Przejrzyj + utwórz kreatora wdrażania. Zasady uniemożliwiają utworzenie tej usługi, jeśli publiczny punkt końcowy jest włączony.
Można utworzyć prywatny punkt końcowy teraz lub po utworzeniu konta magazynowego. W tym przykładzie pokazano tworzenie prywatnego punktu końcowego po utworzeniu konta przechowywania. Wybierz pozycję Przejrzyj i utwórz , aby ukończyć krok.
Po utworzeniu konta magazynu utwórz prywatny punkt końcowy za pośrednictwem witryny Azure Portal.
W sekcji Zasób znajdź konto przechowywania utworzone w poprzednim kroku. W zasoby docelowe wybierz Blob, a następnie wybierz Dalej.
W sekcji Konfiguracja po wybraniu sieci wirtualnej i podsieci upewnij się, że opcja Integracja z prywatną strefą DNS ma wartość Nie. W przeciwnym razie witryna Azure Portal uniemożliwia utworzenie prywatnego punktu końcowego. Usługa Azure Policy nie umożliwia utworzenia prywatnej strefy DNS z prefiksem privatelink .
Wybierz pozycję Przejrzyj i utwórz, a następnie wybierz pozycję Utwórz , aby wdrożyć prywatny punkt końcowy.
Po kilku minutach DeployIfNotExists zasady są wyzwalane. Kolejne dnsZoneGroup wdrożenie dodaje następnie wymagane rekordy DNS dla prywatnego punktu końcowego w centralnej zarządzanej strefie DNS.
Po utworzeniu prywatnego punktu końcowego wybierz go i przejrzyj jego nazwę FQDN i prywatny adres IP:
Sprawdź dziennik aktywności dla grupy zasobów, w której został utworzony prywatny punkt końcowy. Możesz też sprawdzić dziennik aktywności prywatnego punktu końcowego. Po kilku minutach DeployIfNotExist zostanie uruchomiona akcja zasad, która konfiguruje grupę stref DNS w prywatnym punkcie końcowym:
Jeśli centralny zespół ds. sieci przejdzie do privatelink.blob.core.windows.net prywatnej strefy DNS, potwierdzi, że rekord DNS jest dostępny dla utworzonego prywatnego punktu końcowego, a zarówno nazwa, jak i adres IP są zgodne z wartościami w prywatnym punkcie końcowym.

W tym momencie zespoły aplikacji mogą używać konta magazynu za pośrednictwem prywatnego punktu końcowego z dowolnej sieci wirtualnej w środowisku sieci piasty i szprych oraz ze środowiska lokalnego. Rekord DNS został automatycznie zarejestrowany w prywatnej strefie DNS.

Jeśli właściciel aplikacji usunie prywatny punkt końcowy, odpowiednie rekordy w prywatnej strefie DNS zostaną automatycznie usunięte.