Интеграция Private Link и DNS в крупномасштабном формате

Статья
2025-01-10

В этой статье описывается, как интегрировать Azure Private Link для решений платформы как услуги (PaaS), которые имеют приватные DNS зоны Azure в архитектуре сети с топологией концентратор-спица.

Введение

Многие клиенты создают сетевую инфраструктуру в Azure с помощью сетевой архитектуры концентратора и периферийной сети, где:

Сетевые общие службы, такие как виртуальные сетевые устройства (NVAs), expressRoute/VPN-шлюзы или DNS-серверы, развертываются в центральной виртуальной сети.
Периферийные виртуальные сети используют общие службы через пиринг между виртуальными сетями.

В центральной и периферийной сетевой архитектуре владельцы приложений обычно имеют подписку Azure, которая включает виртуальную сеть (периферийную сеть), подключенную к центральной виртуальной сети. В этой архитектуре они могут развертывать свои виртуальные машины и иметь частное подключение к другим виртуальным сетям или локальным сетям через ExpressRoute или VPN.

Центральная NVA, например Брандмауэр Azure, предоставляет исходящие подключения к Интернету. Кроме того, это устройство, в сочетании с другой службой, например прокси-сервер DNS брандмауэра Azure, который находится в центре или рядом с ним, обычно используется для настройки перенаправления DNS.

Многие команды приложений создают свои решения с помощью сочетания ресурсов Azure IaaS и PaaS. Некоторые службы Azure PaaS, такие как Управляемый экземпляр SQL Azure, можно развернуть в виртуальных сетях клиентов. В результате трафик остается закрытым в сети Azure и полностью маршрутизируется из локальной среды.

Но некоторые службы Azure PaaS, такие как служба хранилища Azure или Azure Cosmos DB, не могут быть развернуты в виртуальных сетях клиента и доступны через свою общедоступную конечную точку. В некоторых случаях эта конфигурация вызывает спор с политиками безопасности клиента. Корпоративный трафик может не разрешать развертывание или доступ к корпоративным ресурсам, таким как база данных SQL, через общедоступные конечные точки.

Приватный канал поддерживает доступ к списку служб Azure через частные конечные точки, но требуется зарегистрировать эти записи частной конечной точки в соответствующей частной зоне DNS.

В этой статье описывается, как команды приложений могут развертывать службы Azure PaaS в своих подписках, которые доступны только через частные конечные точки.

В этой статье также описывается, как команды приложений могут обеспечить автоматическую интеграцию служб с частными зонами DNS. Они выполняют автоматизацию через Частный DNS Azure, что удаляет необходимость вручную создавать или удалять записи в DNS.

Интеграция приватного канала и DNS в архитектуре сети концентратора и периферийной сети

Частные зоны DNS обычно размещаются централизованно в той же подписке Azure, где развертывается виртуальная сеть концентратора. Эта центральная практика размещения обусловлена разрешением DNS-имен между различными местоположениями и другими потребностями в централизованном разрешении DNS, такими как Windows Server Active Directory. В большинстве случаев только администраторы по сетям и управлению идентификацией обладают полномочиями на управление записями DNS в зонах.

Команды приложений имеют разрешения на создание ресурса Azure в собственной подписке. У них нет разрешений в подписке на централизованное сетевое подключение, включающее управление записями DNS в частных зонах DNS. Это ограничение доступа означает, что у них нет возможности создавать записи DNS, необходимые при развертывании служб Azure PaaS с частными конечными точками.

На следующей схеме показана типичная высокоуровневая архитектура для корпоративных сред с центральным разрешением DNS и разрешением имен для ресурсов Приватного канала с помощью Azure Private DNS:

На предыдущей схеме важно выделить следующее:

Локальные DNS-серверы имеют условные пересылатели, настроенные для публичной DNS-зоны каждого частного конечного узла, которые указывают на частный сопоставитель DNS, который размещён в центральной виртуальной сети.
Частный сопоставитель DNS, размещенный в центральной виртуальной сети, использует DNS, предоставленный Azure (168.63.129.16) в качестве сервера пересылки.
Виртуальная сеть концентратора должна быть связана с именами частной зоны DNS для служб Azure, например privatelink.blob.core.windows.net, как показано на схеме.
Все виртуальные сети Azure используют частный сопоставитель DNS, размещенный в центральной виртуальной сети.
Приватный резолвер DNS не является авторитетным для корпоративных доменов клиента, таких как доменные имена Active Directory, потому что это просто форвардер. У частного сопоставителя DNS должны быть исходящие серверы пересылки конечных точек в корпоративные домены клиента, указывающие на локальные DNS-серверы (172.16.10 и 172.16.1.11) или DNS-серверы, развернутые в Azure, которые являются доверенными для таких зон.

Примечание.

Вы можете развернуть частный резолвер DNS в виртуальной сети концентратора вместе со шлюзом ExpressRoute. Однако необходимо убедиться, что определение общедоступных полных доменных имен разрешено, и что ответы имеют допустимые значения в соответствии с правилом набора правил перенаправления DNS на целевой DNS-сервер. Некоторые службы Azure используют возможность разрешения общедоступных DNS-имен для работы. Дополнительные сведения см. в правилах набора правил пересылки DNS.

Хотя на предыдущей схеме показана единая архитектура концентратора и периферийной архитектуры, клиентам может потребоваться расширить свое пространство Azure в нескольких регионах, чтобы устранить требования к устойчивости, близости или месту размещения данных. В нескольких сценариях один и тот же экземпляр PaaS с поддержкой приватного канала должен быть доступен через несколько частных конечных точек.

На следующей диаграмме показана типичная высокоуровневая архитектура для корпоративных сред, где центральное разрешение DNS развернуто в узле (один для каждого региона), и разрешение имен для ресурсов Azure Private Link осуществляется через Azure Private DNS.

Необходимо развернуть несколько региональных частных конечных точек, связанных с экземпляром PaaS, по одному в каждом регионе, где существуют клиенты. Включите приватный канал и частные зоны DNS для каждого региона. При работе со службами PaaS, которые имеют встроенные возможности аварийного восстановления, такие как геоизбыточные учетные записи хранения и группы отработки отказа базы данных SQL, необходимо иметь частные конечные точки в нескольких регионах.

В этом сценарии требуется ручное обслуживание и обновление набора записей DNS приватного канала в каждом регионе, так как в настоящее время для них нет автоматического управления жизненным циклом.

Для других вариантов использования можно развернуть одну глобальную частную конечную точку, что делает ее доступной для всех клиентов путем добавления маршрутизации из соответствующих регионов в одну частную конечную точку в одном регионе.

Чтобы включить разрешение и, следовательно, подключение из локальных сетей в privatelink частную зону DNS и частные конечные точки, подготовьте соответствующую конфигурацию DNS, например условные пересылки, в инфраструктуре DNS.

Два условия, которые должны быть верными для команд приложений, чтобы создать все необходимые ресурсы Azure PaaS в своей подписке:

Группы центральных сетей или центральных платформ должны гарантировать, что команды приложений могут развертывать и получать доступ только к службам Azure PaaS через частные конечные точки.
Группы центральных сетей или центральных платформ должны гарантировать, что при создании частных конечных точек они настраивают обработку соответствующих записей. Настройте соответствующие записи таким образом, чтобы они автоматически создавались в централизованной частной зоне DNS, которая соответствует созданной службе.
Записи DNS должны соответствовать жизненному циклу частной конечной точки, чтобы записи автоматически удаляются при удалении частной конечной точки.

Примечание.

В зависимости от разрешения DNS, если вам нужны полные доменные имена в правилах сети для брандмауэра Azure и политики брандмауэра Azure, включите DNS-прокси брандмауэра Azure для использования полных доменных имен в правилах сети. Затем периферийные виртуальные сети должны изменить параметры DNS с настраиваемого DNS-сервера на прокси-сервер брандмауэра Azure. Полные доменные имена в правилах сети позволяют фильтровать исходящий трафик с помощью любого протокола TCP или UDP, включая NTP, SSH и RDP. При изменении параметров DNS периферийной виртуальной сети необходимо перезагрузить все виртуальные машины внутри этой виртуальной сети.

В следующих разделах описывается, как команды приложений обеспечивают эти условия с помощью политики Azure. В этом примере служба хранилища Azure используется в качестве службы Azure, которую необходимо развернуть командам приложений. Но тот же принцип применяется к большинству служб Azure, которые поддерживают приватный канал.

Требования к конфигурации команды платформы

Требования к конфигурации группы платформы включают создание частных зон DNS, настройку определений политик, развертывание политик и настройку назначений политик.

Создание частных зон DNS

Создайте частные зоны DNS в центральной подписке на подключение для поддерживаемых служб Private Link. Дополнительные сведения см. в статье Конфигурация DNS частной конечной точки Azure.

В этом случае учетная запись хранения с Blob-хранилищем является примером. Это переводится как создание частной privatelink.blob.core.windows.net зоны DNS в подписке на подключение.

Снимок экрана, на котором показана частная зона DNS в подписке на подключение.

Создание определений политик

Помимо частных зон DNS необходимо также создать набор пользовательских определений политики Azure. Эти определения применяют использование частных конечных точек и автоматизируют создание записи DNS в создаваемой зоне DNS:

Общедоступная конечная Deny точка для политики служб PaaS.

Эта политика запрещает пользователям создавать службы Azure PaaS с общедоступными конечными точками.

Пользователи получают сообщение об ошибке, если они не выбирают частную конечную точку при создании ресурса.

Точное правило политики может отличаться от служб PaaS. Для учетных записей хранения Azure свойство networkAcls.defaultAction определяет, разрешены ли запросы из общедоступных сетей. В этом случае задайте условие, чтобы запретить создание типа ресурса Microsoft.Storage/storageAccounts, если свойство networkAcls.defaultAction не равно Deny. В следующем определении политики показано поведение:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny возможность создания частной зоны DNS с политикой префикса privatelink.

Используйте централизованную архитектуру DNS с условным сервером пересылки и частными зонами DNS, размещенными в подписках, управляемых командой платформы. Необходимо запретить владельцам команд приложений создавать собственные частные зоны DNS и связывать службы с подписками.

Убедитесь, что команда вашей приложения при создании частной конечной точки устанавливает параметр Integrate with private DNS zone на No в портале Azure.

При выборе Yesполитика Azure не позволяет создавать частную конечную точку. В определении политики запрещается создать тип ресурса Microsoft.Network/privateDnsZones , если у зоны есть privatelink префикс. В следующем определении privatelink политики показан префикс:
```
{
  "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 политика автоматического создания требуемой записи DNS в центральной частной зоне DNS.

В следующих примерах политики показаны два подхода для определения, какой privateDNSZoneGroup создается на частной конечной точке.

Первая политика зависит от groupId, в то время как вторая политика использует как privateLinkServiceId, так и groupID. Используйте вторую политику при groupId конфликте или столкновении с другим ресурсом.

Например, groupIdSQL используется для Azure Cosmos DB и Azure Synapse Analytics. Если развернуты оба типа ресурсов и первая политика была назначена для создания privateDNSZoneGroup на записи частной конечной точки, она создается и сопоставляется с неправильной частной зоной DNS Azure Cosmos DB или Azure Synapse Analytics. Затем он может переключаться между каждой из зон из-за столкновения groupId, которое ищет первая политика в своем правиле.

groupId Для списка ресурсов PrivatLink см. колонку 'Подресурсы' в разделе "Что такое приватная конечная точка?".

Подсказка

Встроенные определения политики Azure постоянно добавляются, удаляются и обновляются. Вместо управления собственными политиками следует использовать встроенные политики, где они доступны. Используйте AzPolicyAdvertizer , чтобы найти существующие встроенные политики, имеющие следующее имя xxx ... для использования частных зон DNS. Кроме того, целевая зона Azure (ALZ) имеет инициативу политики, настройте службы Azure PaaS для использования частных зон DNS, которые содержат встроенные политики, которые периодически обновляются. Если встроенная политика недоступна для вашей ситуации, рассмотрите возможность создания идеи на azure-policy сайте сообщество Azure Governance, следуя процессу предложения стандартной политики в репозитории Azure Policy GitHub.

Политика DeployIfNotExists только для groupId

Эта политика активируется при создании ресурса частной конечной точки, относящегося к конкретной службе groupId. Идентификатор groupId — это идентификатор группы, полученный из удаленного ресурса (службы), к которому должна подключаться эта частная конечная точка. Затем запускается развертывание privateDNSZoneGroup в приватной конечной точке, которая связывает приватную конечную точку с приватной зоной DNS. groupId для блобов в Azure Storage в примере равен blob. Дополнительные сведения о groupId других службах Azure см. в столбце Subresource в конфигурации DNS частной конечной точки Azure. Когда политика обнаруживает groupId в частной конечной точке, она развертывает privateDNSZoneGroup в этой же точке и связывает его с идентификатором ресурса частной зоны DNS, который указан в качестве параметра. В примере идентификатор ресурса частной зоны DNS:

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

В следующем примере кода показано определение политики:

{
  "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"
      }
    }
  }
}

Политика "DeployIfNotExists" для groupId и privateLinkServiceId

Эта политика активируется при создании ресурса частной конечной точки с определёнными параметрами groupId и privateLinkServiceId, специфичными для службы. Идентификатор groupId группы, полученной из удаленного ресурса (службы), к которому должна подключиться эта частная конечная точка. Идентификатор privateLinkServiceId — это идентификатор ресурса удаленного ресурса (службы), к которому должна подключаться эта частная конечная точка. Затем инициируйте развертывание privateDNSZoneGroup в пределах частной конечной точки, которая связывает частную конечную точку с частной зоной DNS.

В этом примере, для Azure Cosmos DB (SQL) используется SQL, и privateLinkServiceId должен содержать Microsoft.DocumentDb/databaseAccounts. Дополнительные сведения о groupIdprivateLinkServiceId других службах Azure см. в столбце subresource в конфигурации DNS частной конечной точки Azure. Когда политика находит groupId и privateLinkServiceId в частной конечной точке, она развертывает privateDNSZoneGroup в этой частной конечной точке. Он связан с идентификатором ресурса частной зоны DNS, который указан в качестве параметра. В следующем определении политики показан идентификатор ресурса частной зоны DNS:

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

В следующем примере кода показано определение политики:

{
  "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"
     }
  }
}

Назначения политики

После развертывания определений политик назначьте политики в нужной области в иерархии групп управления. Убедитесь, что назначения политик предназначены для подписок Azure, которые команды приложений используют для развертывания служб PaaS исключительно с доступом к частной конечной точке.

Это важно

Помимо назначения ролиDefinition , определенной в политике, назначьте роль участника частной зоны DNS управляемому удостоверению, созданному назначением DeployIfNotExists политики. Эта роль должна быть назначена в подписке и группе ресурсов, где хранятся частные зоны DNS. Управляемое удостоверение создает и управляет записью DNS для частной конечной точки в частной зоне DNS. Эта конфигурация необходима, так как частная конечная точка находится в подписке владельца приложения Azure, а частная зона DNS находится в другой подписке, например централизованной подписке на подключение.

После того, как команда платформы завершит настройку:

Подписки Azure для команд приложений готовы для создания служб Azure PaaS, которые имеют исключительный доступ к частной конечной точке.
Команда должна убедиться, что записи DNS для частных конечных точек автоматически регистрируются в соответствующих частных зонах DNS, а записи DNS удаляются после удаления частной конечной точки.

Владелец приложения развертывает службу Azure PaaS

После развертывания компонентов инфраструктуры платформы (частных зон DNS и политик) владелец приложения выполняет следующие действия при попытке развернуть службу Azure PaaS в подписке Azure. Эти шаги одинаковы, независимо от того, выполняют ли они свои действия через портал Azure или других клиентов, таких как PowerShell или CLI, поскольку политики Azure управляют их подписками.

Создайте учетную запись хранения на портале Azure. На вкладке "Основные сведения" выберите нужные параметры, укажите имя учетной записи хранения и нажмите кнопку "Далее".
На вкладке "Сеть" выберите частную конечную точку. Если выбрать вариант, отличный от частной конечной точки, портал Azure не позволяет создать учетную запись хранения в разделе Обзор + создание мастера развертывания. Политика не позволяет создавать эту службу, если общедоступная конечная точка включена.
Теперь или после создания учетной записи хранения можно создать частную конечную точку. В этом примере показано создание частной конечной точки после создания учетной записи хранения. Нажмите кнопку "Рецензирование" и "Создать ", чтобы завершить шаг.
Создав учетную запись хранения, сделайте частную конечную точку на портале Azure.
В разделе "Ресурс" найдите учетную запись хранения, созданную на предыдущем шаге. В разделе целевого подресурса выберите объект Blob, а затем нажмите Далее.
В разделе "Конфигурация" после выбора виртуальной сети и подсети убедитесь, что для интеграции с частной зоной DNS задано значение "Нет". В противном случае портал Azure запрещает создавать частную конечную точку. Политика Azure не позволяет создавать частную зону DNS с privatelink префиксом.
Выберите "Просмотр и создание", а затем нажмите кнопку "Создать ", чтобы развернуть частную конечную точку.
Через несколько минут политика DeployIfNotExists активируется. Затем последующее dnsZoneGroup развертывание добавляет необходимые записи DNS для частной конечной точки в централизованно управляемой зоне DNS.
После создания частной конечной точки выберите ее и просмотрите полное доменное имя и частный IP-адрес:
Проверьте журнал действий для группы ресурсов, в которой была создана частная конечная точка. Также можно проверить журнал действий частной конечной точки. Через несколько минут запускается действие политики DeployIfNotExist, которое настраивает группу зон DNS на частной конечной точке.
Если центральная группа сетей переходит в privatelink.blob.core.windows.net частную зону DNS, они подтверждают наличие записи DNS для созданной частной конечной точки, а имя и IP-адрес соответствуют значениям в частной конечной точке.

На этом этапе команды приложений могут использовать учетную запись хранения через частную конечную точку из любой виртуальной сети в сетевой среде концентратора и периферийной сети и из локальной среды. Запись DNS автоматически записывается в частной зоне DNS.

Если владелец приложения удаляет частную конечную точку, соответствующие записи в частной зоне DNS автоматически удаляются.

Это важно

Вы по-прежнему можете создавать частные конечные точки в вашей инфраструктуре как элементы управления кодом. Но если вы используете подход с использованием политики DeployIfNotExists в этой статье, вы не должны встраивать DNS в код. Политики DeployIfNotExists, содержащие необходимый RBAC для частных зон DNS, управляют интеграцией DNS.

Дальнейшие действия

DNS для локальных ресурсов и ресурсов Azure
Использование Бастиона Azure для удаленного доступа к виртуальной машине
Быстрый старт: создание частной конечной точки с помощью Bicep.
Создайте частную конечную точку с помощью ресурса azurerm_private_endpoint в реестре Terraform.