Интеграция приватного канала и DNS в большом масштабе

Статья
10/25/2023

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

Введение

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

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

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

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

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

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

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

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

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

Приватный канал и интеграция DNS в звездообразной топологии сети

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

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

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

Схема высокоуровневой архитектуры с центральным разрешением DNS и разрешением имен для Приватный канал ресурсов.

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

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

Примечание.

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

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

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

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

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

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

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

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

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

Примечание.

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

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

Настройка, требуемая командой платформы

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

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

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

В этом случае учетная запись хранения с большим двоичным объектом является примером. Он преобразуется в создание частной 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 столкнутся (столкнутся) с другим ресурсом.

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

Список ресурсов groupIdприватного канала см. в столбце подресурсов в разделе "Что такое частная конечная точка?".

Совет

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

Первая `DeployIfNotExists` политика — сопоставление `groupId` только

Эта политика активируется при создании ресурса частной конечной точки с использованием конкретной groupIdслужбы. groupId — это идентификатор группы, полученный от удаленного ресурса (службы), к которому должна подключаться эта частная конечная точка. Затем он активирует развертывание privateDNSZoneGroup в частной конечной точке, которая связывает частную конечную точку с частной зоной DNS. В этом примере groupId для больших двоичных объектов служба хранилища Azure является blob. Дополнительные сведения о других службах Azure см. в groupId разделе конфигурации DNS частной конечной точки Azure в столбце Subresource. Когда политика находит 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.

В примере groupId для Azure Cosmos DB (SQL) используется SQL и privateLinkServiceId должен содержаться Microsoft.DocumentDb/databaseAccounts. Дополнительные сведения о других службах Azure см. в privateLinkServiceId groupId разделе конфигурации DNS частной конечной точки Azure в столбце Subresource. Когда политика находит 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 в подписке и группе ресурсов, где частные зоны DNS размещаются в управляемом удостоверении, созданном DeployIfNotExists назначением политики, который будет отвечать за создание записи DNS частной конечной точки и управление ими в частной зоне DNS. Это связано с тем, что частная конечная точка находится в подписке Azure владельца приложения, а частная зона DNS находится в другой подписке (например, в центральной подписке на подключение).

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

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

Действия владельца приложения

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

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

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

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

Следующие шаги

Просмотрите DNS для локальных ресурсов и ресурсов Azure. Просмотрите план удаленного доступа к виртуальной машине.

Внимание

В этой статье описывается интеграция DNS и приватного канала в масштабе с помощью политик DINE (DeployIfNotExists), назначенных группе управления. Это означает, что при создании частных конечных точек с этим подходом не требуется обрабатывать интеграцию DNS, так как она обрабатывается политиками. Кроме того, вряд ли команды приложений имеют доступ RBAC к централизованным зонам Частная зона DNS.

Ниже приведены полезные ссылки для просмотра при создании частной конечной точки с помощью Bicep и HashiCorp Terraform.

Для создания частной конечной точки с помощью инфраструктуры как кода:

Краткое руководство. Создание частной конечной точки с помощью Bicep.

Создайте частную конечную точку с помощью HashiCorp Terraform azurerm_private_endpoint в Реестре Terrafrom.

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

Поделиться через

Интеграция приватного канала и DNS в большом масштабе

Введение

Приватный канал и интеграция DNS в звездообразной топологии сети