Link Privado e integração de DNS em escala

Artigo
10/26/2023

Este artigo descreve como integrar o Link Privado do Azure para serviços de PaaS com zonas de DNS privado do Azure em arquiteturas de rede hub e spoke.

Introdução

Muitos clientes criam sua infraestrutura de rede no Azure usando a arquitetura de rede hub e spoke, em que:

Os serviços compartilhados de rede (como dispositivos virtuais de rede, gateways ExpressRoute/VPN ou servidores DNS) são implantados na rede virtual de hub (VNet).
As VNets spoke consomem os serviços compartilhados por meio do emparelhamento de VNet.

Em arquiteturas de rede hub e spoke, os proprietários de aplicativos normalmente recebem uma assinatura do Azure, que inclui uma VNet (um spoke) conectada à VNet do hub. Nessa arquitetura, eles podem implantar suas máquinas virtuais e ter conectividade privada com outras VNets ou com redes locais por meio da Rota Expressa ou VPN.

Um dispositivo virtual de rede central (NVA), como o Firewall do Azure, fornece conectividade de saída da Internet. Além disso, esse dispositivo, como com o proxy DNS do Firewall do Azure, ou outro serviço no hub ou adjacente a ele, normalmente é usado para personalizar o encaminhamento DNS.

Muitas equipes de aplicativos criam suas soluções usando uma combinação de recursos de IaaS e PaaS do Azure. Alguns serviços de PaaS do Azure (como Instância Gerenciada de SQL) podem ser implantados em VNets do cliente. Como resultado, o tráfego permanece privado na rede do Azure e é totalmente roteável no local.

Mas alguns serviços de PaaS do Azure (como o Armazenamento do Azure ou o Azure Cosmos DB) não podem ser implantados nas VNets de um cliente e podem ser acessados por meio de seu ponto de extremidade público. Em alguns casos, essa configuração causa uma contenção com as políticas de segurança de um cliente. O tráfego corporativo pode não permitir a implantação ou o acesso de recursos corporativos (como um banco de dados SQL) em pontos de extremidade públicos.

O Link Privado do Azure dá suporte ao acesso a uma lista de serviços do Azure em pontos de extremidade privados, mas requer que você registre esses registros de ponto de extremidade privados em uma zona DNS privada correspondente.

Este artigo descreve como as equipes de aplicativos podem implantar serviços de PaaS do Azure em suas assinaturas que só são acessíveis em pontos de extremidade privados.

Este artigo também descreve como as equipes de aplicativos podem garantir que os serviços se integrem automaticamente a zonas DNS privadas. Eles fazem a automação por meio do DNS Privado do Azure, que elimina a necessidade de criar ou excluir registros manualmente no DNS.

A integração do Link Privado e DNS nas arquiteturas de hub e spoke

As zonas DNS privadas normalmente são hospedadas centralmente na mesma assinatura do Azure em que a VNet do hub é implantada. Essa prática de hospedagem central é orientada pela resolução de nomes DNS entre instalações e por outras necessidades de resolução de DNS central, como o Active Directory. Na maioria dos casos, somente administradores de rede e identidade têm permissões para gerenciar registros DNS nas zonas.

As equipes de aplicativos têm permissões para criar recursos do Azure em sua própria assinatura. Eles não têm permissões na assinatura de conectividade de rede central, o que inclui o gerenciamento de registros DNS nas zonas DNS privadas. Essa limitação de acesso significa que eles não têm a capacidade de criar os registros DNS necessários ao implantar serviços de PaaS do Azure com pontos de extremidade privados.

O diagrama a seguir mostra uma típica arquitetura de alto nível para ambientes corporativos, com resolução de DNS central, e onde a resolução de nomes para recursos de Link Privado é feita por meio do Azure DNS privado:

Um diagrama de uma arquitetura de alto nível com resolução DNS central e resolução de nomes para recursos de Link Privado.

Do diagrama anterior, é importante destacar que:

Os servidores DNS locais têm encaminhadores condicionais configurados para cada zona DNS pública de ponto de extremidade privado, apontando para o Resolvedor Privado de DNS hospedado na VNet do hub.
O Resolvedor Privado de DNS hospedado na VNet do hub usa o DNS fornecido pelo Azure (168.63.129.16) como encaminhador.
A rede virtual de hub deve ser vinculada aos nomes de zona DNS Privado para serviços do Azure (como privatelink.blob.core.windows.net, conforme mostrado no diagrama).
Todas as VNets do Azure usam o Resolvedor de DNS Privado hospedado na Rede Virtual de hub
Como o Resolvedor de DNS Privado não é autoritativo para os domínios corporativos do cliente, pois é apenas um encaminhador (por exemplo, nomes de domínio do Active Directory), ele deve ter encaminhadores de ponto de extremidade de saída para os domínios corporativos do cliente, apontando para os Servidores DNS locais (172.16.1.10 e 172.16.1.11) ou servidores DNS implantados no Azure que são autoritativos para essas zonas.

Observação

Você pode implantar um Resolvedor Privado de DNS em sua Rede Virtual de Hub, juntamente com seu Gateway de Rota Expressa, etc. No entanto, você deve garantir que a resolução de FQDNs públicos seja permitida e responda com uma resposta válida por meio de uma Regra de Conjunto de Regras de Encaminhamento DNS para o servidor DNS de destino. Como alguns serviços do Azure dependem, dependem da capacidade de resolver nomes DNS públicos para funcionar. Obtenha mais informações aqui

Embora o diagrama anterior descreva uma única arquitetura de hub e spoke, os clientes talvez precisem estender sua área de cobertura do Azure em várias regiões para atender aos requisitos de resiliência, proximidade ou residência de dados, surgiram vários cenários em que a mesma instância de PaaS habilitada para Link Privado deve ser acessada por meio de vários Pontos de Extremidade Privados (PEs).

O diagrama a seguir mostra uma arquitetura típica de alto nível para ambientes corporativos com resolução DNS central implantada no hub (um por região) em que a resolução de nomes para recursos de Link Privado é feita por meio do DNS Privado do Azure.

É recomendável implantar vários pontos de extremidade privados regionais associados à instância de PaaS, um em cada região onde existem clientes, habilitar o Link Privado por região e as Zonas DNS Privadas. Ao trabalhar com serviços de PaaS com recursos internos de DR (contas de armazenamento com redundância geográfica, grupos de failover de banco de dados SQL, etc.), os pontos de extremidade privados de várias regiões são obrigatórios.

Esse cenário requer manutenção/atualizações manuais do conjunto de registros DNS de Link Privado em todas as regiões, pois atualmente não há gerenciamento automatizado do ciclo de vida para eles.

Para outros casos de uso, um único ponto de extremidade privado global pode ser implantado, tornando-se acessível a todos os clientes adicionando roteamento das regiões relevantes para o único ponto de extremidade privado em uma única região.

Para habilitar a resolução e, portanto, a conectividade, de redes locais para a privatelink zona DNS privada e pontos de extremidade privados, a configuração DNS apropriada (como encaminhadores condicionais) precisa ser provisionada na infraestrutura DNS.

Há duas condições que devem ser verdadeiras para que as equipes de aplicativos criem quaisquer recursos de PaaS do Azure necessários em sua assinatura:

A rede central e/ou a equipe da plataforma central devem garantir que as equipes de aplicativos só possam implantar e acessar os serviços de PaaS do Azure por meio de pontos de extremidade privados.
As equipes de rede central e/ou plataforma central devem garantir que, ao criar pontos de extremidade privados, configurem como lidar com os registros correspondentes. Configure os registros correspondentes para que eles sejam criados automaticamente na zona DNS privada centralizada que corresponde ao serviço que está sendo criado.
Os registros DNS devem seguir o ciclo de vida do ponto de extremidade privado, ou seja, ele é removido automaticamente quando o ponto de extremidade privado é excluído.

Observação

Se FQDNs em regras de rede baseadas na resolução DNS forem necessários para serem usados na política de Firewall e Firewall do Azure (esse recurso permite filtrar o tráfego de saída com qualquer protocolo TCP/UDP -incluindo NTP, SSH, RDP e muito mais-). Você deve habilitar o Proxy DNS do Firewall do Azure para usar FQDNs em suas regras de rede e, em seguida, essas VNets spoke são forçadas a alterar suas configurações de DNS de servidor DNS personalizado para Proxy DNS do Firewall do Azure. Alterar as configurações de DNS de uma rede virtual spoke requer a reinicialização de todas as VMs dentro dessa rede virtual.

As seções a seguir descrevem como as equipes de aplicativos habilitam essas condições usando a Política do Azure. O exemplo usa o Armazenamento do Azure como o serviço do Azure que as equipes de aplicativos precisam implantar. Mas o mesmo princípio se aplica à maioria dos serviços do Azure que oferecem suporte ao Link Privado.

Configuração exigida pela equipe da plataforma

Os requisitos de configuração da equipe da plataforma incluem a criação das zonas DNS privadas, a configuração de definições de política, a implantação de políticas e a configuração das atribuições de política.

Criar zonas DNS particular

Crie zonas DNS privadas na assinatura de conectividade central para os serviços de Link Privado com suporte. Para obter mais informações, confira Configuração de DNS do ponto de extremidade privado do Azure.

Nesse caso, a conta de armazenamento com blob é o exemplo. Isso se traduz na criação de uma privatelink.blob.core.windows.net zona DNS privada na assinatura de conectividade.

Uma captura de tela que mostra a zona DNS privada na assinatura de conectividade.

Definições de política

Além das zonas DNS privadas, você também precisa criar um conjunto de definições personalizadas da Política do Azure. Essas definições impõem o uso de pontos de extremidade privados e automatizam a criação do registro DNS na zona DNS que você cria:

Deny Ponto de extremidade público para a política de serviços de PaaS.

Essa política impede que os usuários criem serviços de PaaS do Azure com pontos de extremidade públicos e fornece uma mensagem de erro se eles não selecionarem o ponto de extremidade privado ao criar o recurso.

A regra de política exata pode ser diferente entre os serviços de PaaS. Para contas de Armazenamento do Azure, examine a propriedade networkAcls.defaultAction que define se as solicitações de redes públicas são permitidas ou não. Nesse caso, defina uma condição para negar a criação do tipo de recurso Microsoft.Storage/storageAccounts se a propriedade networkAcls.defaultAction não Denyfor . A definição de política a seguir mostra o comportamento:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny a capacidade de criar uma zona DNS privada com a política de prefixo privatelink .

Use uma arquitetura DNS centralizada com um encaminhador condicional e zonas DNS privadas hospedadas nas assinaturas gerenciadas pela equipe da plataforma. É necessário impedir que os proprietários das equipes de aplicativos criem suas próprias zonas DNS privadas de Link Privado e vinculem serviços em suas assinaturas.

Certifique-se de que, quando sua equipe de aplicativos criar um ponto de extremidade privado, a opção para Integrate with private DNS zone seja definida como No no portal do Azure.

Se você selecionar Yes, a Política do Azure impedirá que você crie o ponto de extremidade privado. Na definição de política, ele nega a capacidade de criar o tipo de recurso Microsoft.Network/privateDnsZones se a zona tiver o privatelink prefixo. A definição de política a seguir mostra o prefixo 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 política para criar automaticamente o registro DNS necessário na zona DNS privada central.

Os exemplos de política a seguir mostram duas abordagens para identificar qual privateDNSZoneGroup é criado em um ponto de extremidade privado.

A primeira política baseia-se no groupId enquanto a segunda política usa ambos privateLinkServiceId e groupID. Use a segunda política quando groupId entrar em conflito (colidir) com outro recurso.

Por exemplo, o groupId SQL é usado para o Cosmos DB e o Synapse Analytics. Se ambos os tipos de recursos forem implantados e a primeira política tiver sido atribuída para criar o privateDNSZoneGroup na entrada Ponto de Extremidade Privado, ela será criada e mapeada para a Zona DNS Privada incorreta, do Cosmos DB ou do Synapse Analytics. Em seguida, pode alternar entre cada uma das zonas devido ao conflito groupId que a primeira política procura em sua regra política.

Para obter uma lista de recursos groupIdde link privado, consulte a coluna de subrecursos em O que é um ponto de extremidade privado?.

Dica

As definições internas da Política do Azure são constantemente adicionadas, excluídas e atualizadas. É altamente recomendável usar políticas internas em vez de gerenciar suas próprias políticas (quando disponíveis). Use o AzPolicyAdvertizer para localizar políticas internas existentes que têm o seguinte nome de 'xxx ... para usar zonas DNS privadas'. Além disso, as Zonas de Aterrissagem do Azure (ALZ) têm uma iniciativa de política, Configurar os serviços de PaaS do Azure para usar zonas DNS privadas, que também contém políticas internas e atualizadas periodicamente. Se uma política interna não estiver disponível para sua situação, considere criar um problema no site de azure-policy comentários Governança do Azure · Comunidade seguindo o processo Novas Propostas de Política internas no repositório GitHub de Política do Azure.

Primeira `DeployIfNotExists` Política - Correspondência somente em `groupId`

Essa política será acionada se você criar um recurso de ponto de extremidade privado com um serviço específico groupId. O groupId é a ID do grupo obtido do recurso remoto (serviço) ao qual esse ponto de extremidade privado deve se conectar. Em seguida, ele dispara uma implantação de um privateDNSZoneGroup dentro do ponto de extremidade privado, que associa o ponto de extremidade privado à zona DNS privada. No exemplo, os blobs de Armazenamento do groupId Azure para o Azure são blob. Para obter mais informações sobre outros serviços do Azure, consulte Configuração de DNS de groupId Ponto de Extremidade Privado do Azure, na coluna Subrecurso. Quando a política encontra o groupId no ponto de extremidade privado, ela implanta um privateDNSZoneGroup dentro do ponto de extremidade privado e o vincula à ID de recurso de zona DNS privada especificada como parâmetro. No exemplo, o ID do recurso de zona DNS privada é:

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

O exemplo de código a seguir mostra a definição de política:

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

Segunda `DeployIfNotExists` Política - Correspondência em `groupId` & `privateLinkServiceId`

Essa política será acionada se você criar um recurso de ponto de extremidade privado com um serviço específico groupId e privateLinkServiceId. O groupId é a ID do grupo obtido do recurso remoto (serviço) ao qual esse ponto de extremidade privado deve se conectar. O privateLinkServiceId é a ID do recurso remoto (serviço) ao qual esse ponto de extremidade privado deve se conectar. Em seguida, dispare uma implantação de um privateDNSZoneGroup dentro do ponto de extremidade privado, que associa o ponto de extremidade privado à zona DNS privada.

No exemplo, o para o groupId Azure Cosmos DB (SQL) é SQL e o privateLinkServiceId deve conter Microsoft.DocumentDb/databaseAccounts. Para obter mais informações sobre e para outros serviços do Azure, consulte Configuração de groupId DNS de Ponto de Extremidade Privado do Azure, na coluna Subrecurso.privateLinkServiceId Quando a política localiza groupId e privateLinkServiceId no ponto de extremidade privado, ela implanta um privateDNSZoneGroup dentro do ponto de extremidade privado. E está vinculado ao ID de recurso da zona DNS privada especificado como parâmetro. A definição de política a seguir mostra a ID do recurso de zona DNS privada:

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

O exemplo de código a seguir mostra a definição de política:

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

Atribuições de política

Depois que as definições de política forem implantadas, atribua as políticas no escopo desejado na hierarquia do grupo de gerenciamento. Certifique-se de que as atribuições de política se destinam às assinaturas do Azure que as equipes de aplicativos usam para implantar serviços de PaaS com acesso de ponto de extremidade privado exclusivamente.

Importante

Além de atribuir a funçãoDefinition definida na política, lembre-se de atribuir a função de função Colaborador de Zona DNS Privada no grupo de assinatura e recursos em que as zonas DNS privadas estão hospedadas à identidade gerenciada criada pela atribuição de DeployIfNotExists política que será responsável por criar e gerenciar o registro DNS de ponto de extremidade privado na zona DNS privada. Isso porque o ponto de extremidade privado está localizado na assinatura do Azure do proprietário do aplicativo, enquanto a zona DNS privada está localizada em uma assinatura diferente (como assinatura de conectividade central).

Depois que a equipe da plataforma concluir a configuração:

As assinaturas do Azure das equipes de aplicativos estão prontas para que a equipe crie serviços de PaaS do Azure com acesso de ponto de extremidade privado exclusivamente.
A equipe deve garantir que os registros DNS para pontos de extremidade privados sejam registrados automaticamente (e removidos assim que um ponto de extremidade privado for excluído) das zonas DNS privadas correspondentes.

Experiência do proprietário do aplicativo

Depois que a equipe da plataforma implanta os componentes de infraestrutura da plataforma (zonas e políticas DNS privadas), o proprietário do aplicativo tem a seguinte experiência ao tentar implantar um serviço de PaaS do Azure na assinatura do Azure. Essa experiência é a mesma se eles fizerem suas atividades por meio do portal do Azure ou de outros clientes, como PowerShell ou CLI, já que as políticas do Azure controlam suas assinaturas.

Criar uma conta de armazenamento no portal do Microsoft Azure. Na guia Noções básicas, escolha as configurações desejadas, forneça um nome para sua conta de armazenamento e selecione Avançar.
Na guia rede, selecione Ponto de extremidade privado. Se você selecionar uma opção diferente de Ponto de extremidade privado, o portal do Azure não permitirá que você crie a conta de armazenamento na seção Revisar + criar do assistente de implantação. A política impede que você crie esse serviço se o ponto de extremidade público estiver habilitado.
É possível criar o ponto de extremidade privado agora ou depois de criar a conta de armazenamento. Este exemplo mostra a criação do ponto de extremidade privado após a criação da conta de armazenamento. Selecione Revisar + criar para concluir a etapa.
Depois de criar a conta de armazenamento, crie um ponto de extremidade privado por meio do portal do Azure.
Na seção Recurso, localize a conta de armazenamento criada na etapa anterior. Em subrecurso de destino, selecione Blob e, em seguida, selecione Avançar.
Na seção Configuração, depois de selecionar sua rede virtual e sub-rede, verifique se Integrar com zona DNS privada está definido como Não. Caso contrário, o portal do Azure impede que você crie o ponto de extremidade privado. A Política do Azure não permitirá que você crie uma zona DNS privada com o privatelink prefixo.
Selecione Revisra e criar e, em seguida, Criar para implantar o ponto de extremidade privado.
Depois de alguns minutos, a DeployIfNotExists política é acionada. A implantação subsequente dnsZoneGroup , em seguida, adiciona os registros DNS necessários para o ponto de extremidade privado na zona DNS gerenciada centralmente.
Depois de criar o ponto de extremidade privado, selecione-o e revise seu FQDN e IP privado:
Verifique o log de atividades do grupo de recursos onde o ponto de extremidade privado foi criado. Ou você pode verificar o log de atividades do próprio ponto de extremidade privado. Você notará que, após alguns minutos, uma DeployIfNotExist ação de política é executada e configura o grupo de zonas DNS no ponto de extremidade privado:
Se a equipe de rede central for para a privatelink.blob.core.windows.net zona DNS privada, ela confirmará se o registro DNS está lá para o ponto de extremidade privado que você criou, e o nome e o endereço IP correspondem aos valores dentro do ponto de extremidade privado.

Neste ponto, as equipes de aplicativos podem usar a conta de armazenamento por meio de um ponto de extremidade privado de qualquer rede virtual no ambiente de rede hub e spoke e localmente. O registro DNS foi registrado automaticamente na zona DNS privada.

Se um proprietário de aplicativo excluir o ponto de extremidade privado, os registros correspondentes na zona DNS privada serão removidos automaticamente.

Próximas etapas

Revise o DNS para recursos locais e do Azure. Revise o Plano de acesso remoto à máquina virtual.

Importante

Este artigo descreve a integração de DNS e link privado em escala usando políticas DINE (DeployIfNotExists) atribuídas ao Grupo de Gerenciamento. O que significa que não há necessidade de manipular a integração DNS no código ao criar pontos de extremidade privados com essa abordagem, pois ela é manipulada pelas políticas. Também é improvável que as equipes de aplicativos também tenham acesso RBAC às Zonas DNS Privadas centralizadas.

Abaixo estão links úteis para revisão ao criar Private Endpoint com Bicep e HashiCorp Terraform.

Para a criação de ponto de extremidade privado com infraestrutura como código:

Guia de início rápido Crie um ponto de extremidade privado usando o Bicep.

Crie um ponto de extremidade privado usando o azurerm_private_endpoint HashiCorp Terraform no Terrafrom Registry.

No entanto, você ainda pode criar pontos de extremidade privados em suas ferramentas de infraestrutura como código, no entanto, se estiver usando a abordagem de política DINE, conforme descrito neste artigo, você deverá deixar o lado da integração DNS fora do código e permitir que as políticas DINE que têm o RBAC necessário para as zonas DNS privadas manipulem isso.

Compartilhar via

Link Privado e integração de DNS em escala

Introdução

A integração do Link Privado e DNS nas arquiteturas de hub e spoke