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

Artykuł
06/12/2024

W tym artykule opisano sposób integrowania usługi Azure Private Link dla usług PaaS z strefami azure Prywatna strefa DNS w architekturach sieci piasty i szprych.

Wprowadzenie

Wielu klientów tworzy infrastrukturę sieci na platformie Azure przy użyciu architektury sieci piasty i szprych, gdzie:

Usługi udostępnione sieci (takie jak wirtualne urządzenia sieciowe, bramy usługi ExpressRoute/bramy sieci VPN lub serwery DNS) są wdrażane w sieci wirtualnej piasty .
Sieci wirtualne będące szprychami korzystają z usług udostępnionych za pomocą komunikacji równorzędnej sieci wirtualnych.

W architekturach sieci piasty i szprych właściciele aplikacji są zwykle dostarczani z 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 pomocą usługi ExpressRoute lub sieci VPN.

Centralne wirtualne urządzenie sieciowe (WUS), takie jak Usługa Azure Firewall, zapewnia łączność wychodzącą z Internetu. Ponadto to urządzenie, na przykład z serwerem proxy DNS usługi Azure Firewall, lub inną usługą w lub sąsiednim 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 SQL Managed Instance) można wdrożyć w sieciach wirtualnych klientów. W związku z tym ruch pozostaje prywatny w sieci platformy Azure i jest w pełni routingiem 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 uzyskiwanie dostępu do zasobów firmy (takich jak baza danych SQL) za pośrednictwem publicznych punktów końcowych.

Usługa Azure 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 usługi Azure Prywatna strefa 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

Prywatna strefa DNS strefy są zwykle hostowane centralnie w tej samej subskrypcji platformy Azure, w której wdrażana jest sieć wirtualna koncentratora. Ta centralna praktyka hostingu jest oparta na rozpoznawaniu nazw DNS między środowiskami i innych potrzebach centralnego rozpoznawania nazw DNS, takich jak usługa 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 miejscem, w którym rozpoznawanie nazw dla zasobów usługi Private Link odbywa się za pośrednictwem usługi Azure Prywatna strefa DNS:

Diagram architektury wysokiego poziomu z centralnym rozpoznawaniem nazw DNS i rozpoznawaniem nazw dla zasobów usługi Private Link.

Z poprzedniego diagramu ważne jest, aby podkreślić, że:

Lokalne serwery DNS mają warunkowe usługi przesyłania dalej skonfigurowane dla każdej publicznej strefy DNS prywatnego punktu końcowego wskazującego Prywatna strefa DNS Resolver hostowanego w sieci wirtualnej koncentratora.
Narzędzie rozpoznawania Prywatna strefa DNS hostowane w sieci wirtualnej piasty korzysta z usługi DNS dostarczonej przez platformę Azure (168.63.129.16) jako usługi przesyłania dalej.
Sieć wirtualna piasty musi być połączona z nazwami stref Prywatna strefa DNS dla usług platformy Azure (takich jak privatelink.blob.core.windows.net, jak pokazano na diagramie).
Wszystkie sieci wirtualne platformy Azure używają narzędzia Prywatna strefa DNS Resolver hostowanego w sieci wirtualnej piasty
Ponieważ Prywatna strefa DNS Resolver nie jest autorytatywny dla domen firmowych klienta, ponieważ jest to tylko usługa przesyłania dalej (na przykład nazwy domen usługi Active Directory), powinna mieć wychodzące usługi przesyłania dalej punktów końcowych do domen firmowych klienta, wskazując na lokalne serwery DNS (172.16.16.10 i 172.16.1.11) lub serwery DNS wdrożone na platformie Azure, które są autorytatywne dla takich stref.

Uwaga

Prywatny program rozpoznawania nazw DNS można wdrożyć w sieci wirtualnej koncentratora wraz z bramą usługi ExpressRoute itp. 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. Ponieważ niektóre usługi platformy Azure polegają na możliwości rozpoznawania publicznych nazw DNS do działania. Zobacz więcej informacji tutaj

Chociaż na poprzednim diagramie przedstawiono jedną 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, pojawiły się kilka scenariuszy, w których to samo wystąpienie PaaS z obsługą usługi Private Link musi być dostępne za pośrednictwem wielu prywatnych punktów końcowych (PE).

Na poniższym diagramie przedstawiono typową architekturę wysokiego poziomu dla środowisk przedsiębiorstwa z centralnym rozpoznawaniem nazw DNS wdrożonym w centrum (jeden na region), w którym rozpoznawanie nazw dla zasobów usługi Private Link odbywa się za pośrednictwem usługi Azure Prywatna strefa DNS.

Zaleca się wdrożenie wielu 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łączanie usługi Private Link w poszczególnych regionach i strefy Prywatna strefa DNS. Podczas pracy z usługami PaaS z wbudowanymi funkcjami odzyskiwania po awarii (konta magazynu geograficznie nadmiarowego, grupy trybu failover usługi SQL DB itp.), wiele prywatnych punktów końcowych regionu jest obowiązkowych.

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

W przypadku innych przypadków użycia można wdrożyć pojedynczy globalny prywatny punkt końcowy, udostępniając dostęp do 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.

Istnieją 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:

Centralny zespół ds. sieci i/lub centralnej platformy musi zapewnić, że zespoły aplikacji mogą wdrażać usługi PaaS platformy Azure i uzyskiwać do ich dostępu tylko za pomocą prywatnych punktów końcowych.
Zespoły centralnej sieci i/lub centralnej platformy muszą zapewnić, że podczas tworzenia prywatnych punktów końcowych konfigurują sposób obsługi odpowiednich rekordów. Skonfiguruj odpowiednie rekordy tak, 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, w tym automatycznie usuwane po usunięciu prywatnego punktu końcowego.

Uwaga

Jeśli nazwy FQDN w regułach sieci opartych na rozpoznawaniu nazw DNS są potrzebne do użycia w zasadach usługi Azure Firewall i zapory (ta funkcja umożliwia filtrowanie ruchu wychodzącego przy użyciu dowolnego protokołu TCP/UDP , w tym NTP, SSH, RDP i nie tylko). Aby używać nazw FQDN w regułach sieciowych, należy włączyć serwer proxy DNS usługi Azure Firewall, a następnie te sieci wirtualne będące szprychami muszą zmienić ich ustawienie DNS z niestandardowego serwera DNS na serwer proxy DNS usługi Azure Firewall. Zmiana ustawień DNS sieci wirtualnej będącej szprychą wymaga ponownego uruchomienia wszystkich maszyn wirtualnych 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.

Konfiguracja wymagana przez zespół 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.

Definicje 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 i wyświetlenie komunikatu o błędzie, jeśli nie wybierze 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 zapoznaj się z właściwością networkAcls.defaultAction , która określa, czy żądania z sieci publicznych są dozwolone, czy nie. W takim przypadku ustaw warunek odmowy tworzenia zasobu Microsoft.Storage/storageAccounts , jeśli właściwość networkAcls.defaultAction nie Denyjest . 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 zasadami prefiksu privatelink .

Użyj scentralizowanej architektury DNS z warunkowym usługą przesyłania dalej 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 zostanie ustawiona na No wartość w witrynie Azure Portal.

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 dwie metody identyfikowania, które privateDNSZoneGroup zostały utworzone w prywatnym punkcie końcowym.

Pierwsza zasada opiera się na tym, groupId podczas gdy druga zasada używa zarówno , jak privateLinkServiceId i groupID. Użyj drugiej zasady, gdy groupId będą zderzać się (zderzać) z innym zasobem.

Na przykład groupId język SQL jest używany zarówno dla usługi Cosmos DB, jak i usługi 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ą strefę Prywatna strefa DNS usługi Cosmos DB lub 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ę zasobów groupIdłącza prywatnego, zobacz kolumnę podźródła w temacie Co to jest prywatny punkt końcowy?.

Napiwek

Wbudowane definicje usługi Azure Policy są stale dodawane, usuwane i aktualizowane. Zdecydowanie zaleca się używanie wbudowanych zasad w porównaniu z zarządzaniem własnymi zasadami (jeśli są dostępne). Użyj modułu AzPolicyAdvertizer , aby znaleźć istniejące wbudowane zasady o następującej nazwie "xxx ... do korzystania z prywatnych stref 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, a także okresowo aktualizowane. Jeśli wbudowane zasady nie są dostępne w Twojej sytuacji, rozważ utworzenie problemu w witrynie azure-policy opinii — ład platformy Azure · Społeczność po procesie Nowych wbudowanych propozycji zasad w repozytorium GitHub usługi Azure Policy.

Pierwsze `DeployIfNotExists` zasady — dopasowywanie tylko dla `groupId`

Te zasady są wyzwalane, jeśli tworzysz zasób prywatnego punktu końcowego z usługą specyficzną dla groupIdusługi. Jest groupId to identyfikator grupy uzyskanej z zasobu zdalnego (usługi), z którą ten prywatny punkt końcowy powinien nawiązać połączenie. 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 obiekt groupId blob usługi Azure Storage to blob. Aby uzyskać więcej informacji na groupId temat innych usług platformy Azure, zobacz Konfiguracja dns prywatnego punktu końcowego platformy Azure w kolumnie Subresource . Gdy zasady znajdują element groupId w prywatnym punkcie końcowym, wdraża element w prywatnym punkcie privateDNSZoneGroup 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"
      }
    }
  }
}

Druga `DeployIfNotExists` zasada — dopasowywanie w systemie `groupId` i `privateLinkServiceId`

Te zasady są wyzwalane, jeśli tworzysz zasób prywatnego punktu końcowego z usługą specyficzną dla groupId usługi i privateLinkServiceId. Jest groupId to identyfikator grupy uzyskanej z zasobu zdalnego (usługi), z którą ten prywatny punkt końcowy powinien nawiązać połączenie. Jest privateLinkServiceId to identyfikator zasobu zdalnego (usługi), z którymi powinien się połączyć ten prywatny punkt końcowy. Następnie wyzwól wdrożenie privateDNSZoneGroup w prywatnym punkcie końcowym, który kojarzy prywatny punkt końcowy 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 na temat usług groupId i privateLinkServiceId dla innych usług platformy Azure, zobacz Konfiguracja dns prywatnego punktu końcowego platformy Azure w kolumnie Podźródło . Gdy zasady znajdą groupId i privateLinkServiceId w prywatnym punkcie końcowym, wdrażają 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 roli roleDefinition zdefiniowanej w zasadach należy pamiętać o przypisaniu roli współautora strefy Prywatna strefa DNS w subskrypcji i grupie zasobów, w której prywatne strefy DNS są hostowane do tożsamości zarządzanej utworzonej przez DeployIfNotExists przypisanie zasad, które będą odpowiedzialne za tworzenie i zarządzanie rekordem DNS prywatnego punktu końcowego w prywatnej strefie DNS. Jest to spowodowane tym, że 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 aplikacji są gotowe do utworzenia usług PaaS platformy Azure z dostępem do prywatnego punktu końcowego wyłącznie dla zespołu.
Zespół musi upewnić się, że rekordy DNS dla prywatnych punktów końcowych są automatycznie rejestrowane (i usuwane po usunięciu prywatnego punktu końcowego) z odpowiednich prywatnych stref DNS.

Środowisko właściciela aplikacji

Po wdrożeniu przez zespół platformy składników infrastruktury platformy (prywatnych stref i zasad DNS) właściciel aplikacji ma następujące doświadczenie podczas próby wdrożenia usługi Azure PaaS w subskrypcji platformy Azure. To środowisko jest takie samo, 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 magazynu za pośrednictwem witryny 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, witryna Azure Portal nie umożliwi utworzenia konta magazynu w sekcji Przeglądanie i tworzenie kreatora wdrażania. Zasady uniemożliwiają utworzenie tej usługi, jeśli publiczny punkt końcowy jest włączony.
Istnieje możliwość utworzenia prywatnego punktu końcowego teraz lub po utworzeniu konta magazynu. W tym przykładzie pokazano tworzenie prywatnego punktu końcowego po utworzeniu konta magazynu. 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 magazynu utworzone w poprzednim kroku. W obszarze docelowy podźródło wybierz pozycję Blob, a następnie wybierz pozycję 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. Zauważysz, DeployIfNotExist że po kilku minutach 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 istnieje 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.

Następne kroki

Przejrzyj usługę DNS pod kątem zasobów lokalnych i zasobów platformy Azure. Zapoznaj się z artykułem Planowanie dostępu zdalnego maszyny wirtualnej.

Ważne

W tym artykule opisano integrację dns i łącza prywatnego na dużą skalę przy użyciu zasad DINE (DeployIfNotExists) przypisanych do grupy zarządzania. Oznacza to, że nie ma potrzeby obsługi integracji DNS w kodzie podczas tworzenia prywatnych punktów końcowych przy użyciu tego podejścia, ponieważ są obsługiwane przez zasady. Jest również mało prawdopodobne, że zespoły aplikacji mają również dostęp RBAC do scentralizowanych stref Prywatna strefa DNS.

Poniżej znajdują się przydatne linki do przeglądu podczas tworzenia prywatnego punktu końcowego za pomocą narzędzia Bicep i Narzędzia Terraform hashiCorp.

W przypadku tworzenia prywatnego punktu końcowego z użyciem infrastruktury jako kodu:

Szybki start Tworzenie prywatnego punktu końcowego przy użyciu Bicep.

Utwórz prywatny punkt końcowy przy użyciu narzędzia HashiCorp Terraform azurerm_private_endpoint w programie Terrafrom Registry.

Nadal możesz tworzyć prywatne punkty końcowe w narzędziu Infrastructure-as-Code, jednak w przypadku korzystania z podejścia zasad DINE zgodnie z opisem w tym artykule należy pozostawić stronę integracji DNS z kodu i pozwolić zasadom DINE, które mają wymaganą kontrolę dostępu opartej na rolach do strefy Prywatna strefa DNS zamiast tego.

Udostępnij za pośrednictwem

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

Wprowadzenie

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