Integração de Link Privado e DNS em escala
Este artigo descreve como integrar o Azure Private Link para serviços 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, onde:
- Os serviços compartilhados de rede (como dispositivos virtuais de rede, gateways ExpressRoute/VPN ou servidores DNS) são implantados na rede virtual do hub (VNet).
- As VNets spoke consomem os serviços compartilhados por meio do emparelhamento de VNet.
Nas arquiteturas de rede hub e spoke, os proprietários de aplicativos geralmente 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 redes virtuais ou com redes locais por meio de 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 ao hub, normalmente é usado para personalizar o encaminhamento de DNS.
Muitas equipes de aplicativos criam suas soluções usando uma combinação de recursos IaaS e PaaS do Azure. Alguns serviços PaaS do Azure (como a Instância Gerenciada SQL) podem ser implantados em redes virtuais do cliente. Como resultado, o tráfego permanece privado dentro da rede do Azure e é totalmente roteável a partir do local.
Mas alguns serviços PaaS do Azure (como o Armazenamento do Azure ou o Azure Cosmos DB) não podem ser implantados nas redes virtuais de um cliente e são acessíveis em 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 Azure Private Link 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 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 às zonas DNS privadas. Eles fazem a automação por meio do DNS Privado do Azure, o que elimina a necessidade de criar ou excluir registros manualmente no DNS.
Integração de Link Privado e DNS em arquiteturas de rede hub e spoke
As zonas DNS privadas normalmente são hospedadas centralmente na mesma assinatura do Azure em que a VNet de hub é implantada. Essa prática de hospedagem central é impulsionada pela resolução de nomes DNS entre locais e outras necessidades de resolução DNS central, como o Ative Directory. Na maioria dos casos, apenas os 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, 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 PaaS do Azure com pontos de extremidade privados.
O diagrama a seguir mostra uma arquitetura típica de alto nível para ambientes corporativos com resolução DNS central e onde a resolução de nomes para recursos de Link Privado é feita por meio do DNS Privado do Azure:
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 privada, apontando para o Resolvedor de DNS Privado hospedado na VNet do hub.
- O Resolvedor de DNS Privado hospedado na VNet do hub usa o DNS fornecido pelo Azure (168.63.129.16) como um encaminhador.
- A VNet do hub deve estar 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 Private DNS Resolver hospedado na VNet do hub
- Como o Resolvedor de DNS Privado não é autoritativo para domínios corporativos do cliente, pois é apenas um encaminhador (por exemplo, nomes de domínio do Ative 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 autorizados para essas zonas.
Nota
Você pode implantar um Resolvedor Privado de DNS em sua Rede Virtual de Hub, juntamente com seu ExpressRoute Gateway, 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. Veja mais aqui
Embora o diagrama anterior mostre uma única arquitetura de hub e spoke, os clientes podem precisar estender sua pegada do Azure em várias regiões para atender aos requisitos de resiliência, proximidade ou residência de dados, vários cenários surgiram em que a mesma instância de PaaS habilitada para Link Privado deve ser acessada por meio de vários PEs (Private Endpoints).
O diagrama a seguir mostra uma arquitetura típica de alto nível para ambientes corporativos com resolução DNS central implantada no hub (uma por região), onde a resolução de nomes para recursos de Link Privado é feita por meio do DNS Privado do Azure.
Recomenda-se implantar vários pontos de extremidade privados regionais associados à instância 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 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 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 equipe de rede central e/ou plataforma central deve garantir que as equipes de aplicativos só possam implantar e acessar 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, quando criam pontos de extremidade privados, configuram como lidar com os registros correspondentes. Configure os registos correspondentes para que sejam criados automaticamente na zona DNS privada centralizada que corresponde ao serviço que está a ser 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.
Nota
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, então essas VNets spoke são forçadas a alterar suas configurações de DNS do servidor DNS personalizado para o Proxy DNS do Firewall do Azure. Alterar as configurações de DNS de uma VNet spoke requer a reinicialização de todas as VMs dentro dessa VNet.
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 Private Link.
Configuração exigida pela equipe da plataforma
Os requisitos de configuração da equipe de plataforma incluem a criação de 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 privadas
Crie zonas DNS privadas na subscrição de conectividade central para os serviços de ligação privada suportados. Para obter mais informações, veja Configuração do DNS do Ponto Final Privado do Azure.
Neste caso, a conta de armazenamento com blob é o exemplo. Ele se traduz na criação de uma privatelink.blob.core.windows.net 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:
Denyponto de extremidade público para a política de serviços PaaS.Esta política impede que os utilizadores criem serviços PaaS do Azure com pontos de extremidade públicos e dá-lhes uma mensagem de erro se não selecionarem o ponto de extremidade privado ao criar o recurso.
A regra de política exata pode diferir 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 seguinte definição de política 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" } } }Denya capacidade de criar uma zona DNS privada com a política de prefixoprivatelink.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 às suas assinaturas.
Certifique-se de que, quando sua equipe de aplicativo criar um ponto de extremidade privado, a opção para
Integrate with private DNS zoneseja definida comoNono 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 prefixoprivatelink. A seguinte definição de política mostra o prefixoprivatelink:{ "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" } } }DeployIfNotExistspara criar automaticamente o registo 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 na
groupIdpolítica enquanto a segunda política utiliza ambos eprivateLinkServiceIdgroupID. Use a segunda política quandogroupIdentrar em conflito (colidir) com outro recurso.Por exemplo, o
groupIdSQL é 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 aprivateDNSZoneGroupentrada no Ponto Final 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 conflitogroupIdque 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?.
Gorjeta
As definições internas da Política do Azure são constantemente adicionadas, excluídas e atualizadas. É altamente recomendável usar políticas internas versus gerenciar suas próprias políticas (quando disponíveis). Use o AzPolicyAdvertizer para encontrar políticas internas existentes que têm o seguinte nome de 'xxx ... para utilizar zonas DNS privadas». Além disso, as Zonas de Desembarque do Azure (ALZ) têm uma iniciativa de política, Configurar os serviços 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 Azure Governance · Comunidade seguindo o processo de Novas Propostas de Política internas no repositório GitHub de Política do Azure.
Primeira DeployIfNotExists Política - Correspondência apenas em groupId
Esta política é 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, o para blobs de Armazenamento do groupId Azure é blob. Para obter mais informações sobre outros serviços do groupId Azure, consulte Configuração de DNS do Ponto de Extremidade Privado do Azure, na coluna Subrecurso . Quando a política localiza o groupId no ponto de extremidade privado, ela implanta um privateDNSZoneGroup dentro do ponto de extremidade privado e o vincula ao ID de recurso da zona DNS privada especificado como parâmetro. No exemplo, o ID de recurso da 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
Esta política é 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 é o ID do recurso remoto (serviço) ao qual esse ponto de extremidade privado deve se conectar. Em seguida, acione 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 Azure groupId Cosmos DB (SQL) é SQL e o privateLinkServiceId deve conter Microsoft.DocumentDb/databaseAccounts. Para obter mais informações sobre o e para outros serviços do groupId Azure, consulte Configuração de DNS do Ponto de Extremidade Privado do Azure, na coluna Subrecurso.privateLinkServiceId Quando a política encontra 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 seguinte definição de política mostra o ID do recurso da 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íticas
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 PaaS com acesso de ponto de extremidade privado exclusivamente.
Importante
Além de atribuir a funçãoDefinição definida na política, lembre-se de atribuir a função de Colaborador da Zona DNS Privada no grupo de recursos e assinatura 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 do ponto de extremidade privado na zona DNS privada. Isso ocorre 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 a 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 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 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 regem suas assinaturas.
Crie uma conta de armazenamento através do portal do 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 do 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 Rever + criar para concluir o passo.
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 VNet e sub-rede, certifique-se de que Integrar com zona DNS privada esteja definido como Não. Caso contrário, o portal do Azure impede que você crie o ponto de extremidade privado. O Azure Policy não permitirá que você crie uma zona DNS privada com o prefixo
privatelink.
Selecione Rever + criar e, em seguida, selecione Criar para implementar o ponto de extremidade privado.
Após alguns minutos, a
DeployIfNotExistspolítica é acionada. A implantação subsequentednsZoneGroupadiciona 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 registro de atividades do próprio ponto de extremidade privado. Você notará que, após alguns minutos, uma
DeployIfNotExistaçã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.netzona DNS privada, ela confirmará que o registro DNS está lá para o ponto de extremidade privado que você criou, e tanto o nome quanto 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 VNet no ambiente de rede hub e spoke e localmente. O registo DNS foi automaticamente registado 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óximos passos
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 lidar com a integração de DNS no código ao criar pontos de extremidade privados com essa abordagem, pois ela é tratada pelas políticas. Também é improvável que as equipes de aplicativos tenham acesso RBAC às Zonas DNS Privadas centralizadas também.
Abaixo estão links úteis para revisar ao criar Private Endpoint com Bicep e HashiCorp Terraform.
Para a criação de pontos finais privados 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 HashiCorp Terraform azurerm_private_endpoint no Terrafrom Registry.
Você ainda pode criar pontos de extremidade privados em suas ferramentas de infraestrutura como código, no entanto, se usar a abordagem de política de DINE, conforme descrito neste artigo, você deve deixar o lado de integração DNS de fora do seu código e permitir que as políticas de DINE que têm o RBAC necessário para as zonas DNS privadas lidem com isso.
Comentários
Brevemente: Ao longo de 2024, vamos descontinuar progressivamente o GitHub Issues como mecanismo de feedback para conteúdos e substituí-lo por um novo sistema de feedback. Para obter mais informações, veja: https://aka.ms/ContentUserFeedback.
Submeter e ver comentários