Collegamento privato e integrazione DNS su larga scala
Questo articolo descrive come integrare il collegamento privato di Azure per servizi PaaS con le zone di DNS privato di Azure in architetture di rete hub e spoke.
Introduzione
Molti clienti compilano l'infrastruttura di rete in Azure usando l'architettura di rete hub e spoke, in cui:
- I servizi condivisi di rete (ad esempio appliance virtuali di rete, gateway ExpressRoute/VPN o server DNS) vengono distribuiti nella rete virtuale dell'hub.
- Le reti virtuali spoke usano i servizi condivisi tramite il peering reti virtuali.
Nelle architetture di rete hub e spoke, ai proprietari delle applicazioni viene in genere fornita una sottoscrizione di Azure, che include una rete virtuale (spoke) connessa alla rete virtuale dell'hub. In questa architettura possono distribuire le macchine virtuali e avere connettività privata ad altre reti virtuali o alle reti locali tramite ExpressRoute o VPN.
Un'appliance virtuale di rete centrale, ad esempio Firewall di Azure, fornisce connettività internet in uscita. Inoltre, tale dispositivo, ad esempio con Firewall di Azure proxy DNS, o un altro servizio in o adiacente all'hub viene in genere usato per personalizzare l'inoltro DNS.
Molti team di applicazioni compilano le proprie soluzioni usando una combinazione di risorse IaaS e PaaS di Azure. Alcuni servizi PaaS di Azure (ad esempio Istanza gestita di SQL) possono essere distribuiti nelle reti virtuali dei clienti. Di conseguenza, il traffico rimane privato all'interno della rete di Azure ed è completamente instradabile dall'ambiente locale.
Alcuni servizi PaaS di Azure, ad esempio Archiviazione di Azure o Azure Cosmos DB, non possono tuttavia essere distribuiti nelle reti virtuali di un cliente e sono accessibili tramite l'endpoint pubblico. In alcuni casi, questa configurazione causa una contesa con i criteri di sicurezza di un cliente. Il traffico aziendale potrebbe non consentire la distribuzione o l'accesso alle risorse aziendali (ad esempio un database SQL) su endpoint pubblici.
collegamento privato di Azure supporta l'accesso a un elenco di servizi di Azure su endpoint privati, ma richiede la registrazione di tali record di endpoint privati in una zona DNS privata corrispondente.
Questo articolo descrive come i team delle applicazioni possono distribuire i servizi PaaS di Azure nelle sottoscrizioni accessibili solo tramite endpoint privati.
Questo articolo descrive anche in che modo i team delle applicazioni possono garantire l'integrazione automatica dei servizi con zone DNS private. Eseguono l'automazione tramite Azure DNS privato, che elimina la necessità di creare o eliminare manualmente i record in DNS.
Integrazione di Collegamento privato e DNS nelle architetture di rete hub e spoke
DNS privato zone sono in genere ospitate centralmente nella stessa sottoscrizione di Azure in cui viene distribuita la rete virtuale dell'hub. Questa procedura di hosting centralizzato è basata sulla risoluzione dei nomi DNS cross-premise e su altre esigenze per la risoluzione DNS centralizzata, ad esempio Active Directory. Nella maggior parte dei casi, solo gli amministratori di rete e di identità dispongono delle autorizzazioni per gestire i record DNS nelle zone.
I team delle applicazioni hanno le autorizzazioni per creare una risorsa di Azure nella propria sottoscrizione. Non dispongono di autorizzazioni nella sottoscrizione di connettività di rete centrale, che include la gestione dei record DNS nelle zone DNS private. Questa limitazione di accesso significa che non hanno la possibilità di creare i record DNS necessari quando si distribuiscono i servizi PaaS di Azure con endpoint privati.
Il diagramma seguente illustra una tipica architettura generale per gli ambienti aziendali con risoluzione DNS centralizzata e in cui la risoluzione dei nomi per le risorse collegamento privato viene eseguita tramite DNS privato di Azure:
Dal diagramma precedente è importante evidenziare quanto riportato di seguito:
- I server DNS locali hanno server d'inoltro condizionale configurati per ogni zona DNS pubblica dell'endpoint privato, che punta al resolver DNS privato ospitato nella rete virtuale dell'hub.
- Il resolver DNS privato ospitato nella rete virtuale dell'hub usa il DNS fornito da Azure (168.63.129.16) come server d'inoltro.
- La rete virtuale dell'hub deve essere collegata ai nomi di zona DNS privato per i servizi di Azure, ad esempio
privatelink.blob.core.windows.net, come illustrato nel diagramma. - Tutte le reti virtuali di Azure usano DNS privato resolver ospitato nella rete virtuale dell'hub
- Poiché il resolver DNS privato non è autorevole per i domini aziendali del cliente, poiché è solo un server d'inoltro( ad esempio, nomi di dominio di Active Directory), deve avere server d'inoltro endpoint in uscita ai domini aziendali del cliente, che puntano ai server DNS locali (172.16.1.10 e 172.16.1.11) o server DNS distribuiti in Azure autorevoli per tali zone.
Nota
È possibile distribuire un sistema di risoluzione privato DNS nell'hub Rete virtuale insieme al gateway ExpressRoute e così via. Tuttavia, è necessario assicurarsi che la risoluzione dei nomi di dominio completi pubblici sia consentita e risponda con una risposta valida tramite una regola del set di regole di inoltro DNS al server DNS di destinazione. Poiché alcuni servizi di Azure si basano sulla possibilità di risolvere i nomi DNS pubblici per funzionare. Altre informazioni sono disponibili qui
Mentre il diagramma precedente illustra un'architettura hub-spoke singolo, i clienti potrebbero dover estendere il footprint di Azure in più aree per soddisfare i requisiti di resilienza, prossimità o residenza dei dati, diversi scenari sono stati illustrati dove è necessario accedere alla stessa istanza PaaS abilitata per il collegamento privato tramite più endpoint privati (PE).
Il diagramma seguente illustra un'architettura generale tipica per gli ambienti aziendali con risoluzione DNS centrale distribuita nell'hub (una per area) in cui la risoluzione dei nomi per le risorse collegamento privato viene eseguita tramite Azure DNS privato.
È consigliabile distribuire più endpoint privati a livello di area associati all'istanza PaaS, uno in ogni area in cui sono presenti i client, abilitare collegamento privato per area e DNS privato zone. Quando si usano servizi PaaS con funzionalità di ripristino di emergenza predefinite (account di archiviazione con ridondanza geografica, gruppi di failover del database SQL e così via), sono obbligatori più endpoint privati dell'area.
Questo scenario richiede la manutenzione o gli aggiornamenti manuali del set di record DNS collegamento privato in ogni area, perché attualmente non esiste alcuna gestione automatica del ciclo di vita per questi elementi.
Per altri casi d'uso, è possibile distribuire un singolo endpoint privato globale, rendendo accessibile a tutti i client aggiungendo il routing dalle aree pertinenti al singolo endpoint privato in una singola area.
Per abilitare la risoluzione e quindi la connettività, dalle reti locali alla zona DNS privata e agli privatelink endpoint privati, è necessario effettuare il provisioning della configurazione DNS appropriata (ad esempio i server d'inoltro condizionale) nell'infrastruttura DNS.
Esistono due condizioni che devono essere vere per i team dell'applicazione per creare le risorse PaaS di Azure necessarie nella sottoscrizione:
- Il team centrale della rete e/o della piattaforma centrale deve garantire che i team delle applicazioni possano distribuire e accedere solo ai servizi PaaS di Azure tramite endpoint privati.
- I team centrali della rete e/o della piattaforma centrale devono assicurarsi che quando creano endpoint privati, configurano come gestire i record corrispondenti. Configurare i record corrispondenti in modo che vengano creati automaticamente nella zona DNS privata centralizzata corrispondente al servizio creato.
- I record DNS devono seguire il ciclo di vita dell'endpoint privato, in quanto vengono rimossi automaticamente quando l'endpoint privato viene eliminato.
Nota
Se è necessario usare FQDN nelle regole di rete basate sulla risoluzione DNS nei criteri di Firewall di Azure e firewall (questa funzionalità consente di filtrare il traffico in uscita con qualsiasi protocollo TCP/UDP, tra cui NTP, SSH, RDP e altro ancora). È necessario abilitare Firewall di Azure proxy DNS per usare FQDN nelle regole di rete, quindi tali reti virtuali spoke sono costrette a modificare l'impostazione DNS dal server DNS personalizzato a Firewall di Azure proxy DNS. La modifica delle impostazioni DNS di una rete virtuale spoke richiede il riavvio di tutte le macchine virtuali all'interno della rete virtuale.
Le sezioni seguenti descrivono come i team dell'applicazione abilitano queste condizioni usando Criteri di Azure. L'esempio usa Archiviazione di Azure come servizio di Azure che i team dell'applicazione devono distribuire. Lo stesso principio si applica tuttavia alla maggior parte dei servizi di Azure che supportano collegamento privato.
Configurazione richiesta dal team della piattaforma
I requisiti di configurazione del team della piattaforma includono la creazione delle zone DNS private, la configurazione delle definizioni dei criteri, la distribuzione dei criteri e la configurazione delle assegnazioni dei criteri.
Creare zone DNS private
Creare zone DNS private nella sottoscrizione di connettività centrale per i servizi di collegamento privato supportati. Per altre informazioni, vedere Configurazione DNS dell'endpoint privato di Azure.
In questo caso, l'account di archiviazione con BLOB è l'esempio. Si traduce nella creazione di una privatelink.blob.core.windows.net zona DNS privata nella sottoscrizione di connettività.
Definizioni dei criteri
Oltre alle zone DNS private, è anche necessario creare un set di definizioni di Criteri di Azure personalizzate. Queste definizioni applicano l'uso di endpoint privati e automatizzano la creazione del record DNS nella zona DNS creata:
Denyendpoint pubblico per i criteri dei servizi PaaS.Questo criterio impedisce agli utenti di creare servizi PaaS di Azure con endpoint pubblici e restituisce un messaggio di errore se non selezionano l'endpoint privato durante la creazione della risorsa.
La regola esatta dei criteri potrebbe variare tra i servizi PaaS. Per gli account Archiviazione di Azure, esaminare la proprietà networkAcls.defaultAction che definisce se le richieste da reti pubbliche sono consentite o meno. In questo caso, impostare una condizione per negare la creazione del tipo di risorsa Microsoft.Storage/storageAccounts se la proprietà networkAcls.defaultAction non
Denyè . La definizione di criteri seguente illustra il comportamento:{ "mode": "All", "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction", "notEquals": "Deny" } ] }, "then": { "effect": "Deny" } } }Denypossibilità di creare una zona DNS privata con i criteri diprivatelinkprefisso.Usare un'architettura DNS centralizzata con un server d'inoltro condizionale e zone DNS private ospitate nelle sottoscrizioni gestite dal team della piattaforma. È necessario impedire ai proprietari dei team dell'applicazione di creare i propri collegamento privato zone DNS private e collegare i servizi alle sottoscrizioni.
Assicurarsi che quando il team dell'applicazione crea un endpoint privato, l'opzione su
Integrate with private DNS zoneè impostata suNonel portale di Azure.
Se si seleziona
Yes, Criteri di Azure impedisce di creare l'endpoint privato. Nella definizione dei criteri viene negata la possibilità di creare il tipo di risorsa Microsoft.Network/privateDnsZones se la zona ha ilprivatelinkprefisso. La definizione di criteri seguente mostra ilprivatelinkprefisso:{ "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" } } }DeployIfNotExistscriteri per creare automaticamente il record DNS necessario nella zona DNS privato centrale.Gli esempi di criteri seguenti illustrano due approcci per l'identificazione che
privateDNSZoneGroupviene creata in un endpoint privato.Il primo criterio si basa sul
groupIdmentre il secondo criterio usa siaprivateLinkServiceIdchegroupID. Usare il secondo criterio quandogroupIdsi scontra (collide) con un'altra risorsa.Ad esempio, SQL
groupIdviene usato sia per Cosmos DB che per Synapse Analytics. Se entrambi i tipi di risorse distribuiscono e il primo criterio è stato assegnato per creare nellaprivateDNSZoneGroupvoce Endpoint privato, viene creato e mappato alla zona di DNS privato non corretta, di Cosmos DB o Synapse Analytics. Potrebbe quindi passare da una zona all'altra a causa dello scontrogroupIdche il primo criterio cerca nella regola dei criteri.Per un elenco delle risorse
groupIddi collegamento privato, vedere la colonna delle sottorisorse in Che cos'è un endpoint privato?.
Suggerimento
Criteri di Azure definizioni predefinite vengono costantemente aggiunte, eliminate e aggiornate. È consigliabile usare criteri predefiniti rispetto alla gestione dei propri criteri (se disponibili). Usare AzPolicyAdvertizer per trovare i criteri predefiniti esistenti con il nome seguente di 'xxx ... per usare zone DNS private'. Inoltre, le zone di destinazione di Azure (ALZ) hanno un'iniziativa di criteri, Configurare i servizi PaaS di Azure per l'uso di zone DNS private, che contengono criteri predefiniti e aggiornati periodicamente. Se un criterio predefinito non è disponibile per la situazione, prendere in considerazione la creazione di un problema nel azure-policy sito di feedback Governance di Azure · Community che segue il processo Nuove proposte di criteri predefinite sul repository GitHub Criteri di Azure.
Primo DeployIfNotExists criterio - Corrispondenza solo su groupId
Questo criterio viene attivato se si crea una risorsa endpoint privato con un oggetto specifico groupIddel servizio. groupId è l'ID del gruppo ottenuto dalla risorsa remota (servizio) a cui deve connettersi l'endpoint privato. Attiva quindi una distribuzione di all'interno privateDNSZoneGroup dell'endpoint privato, che associa l'endpoint privato alla zona DNS privata. Nell'esempio, per groupId i BLOB di Archiviazione di Azure è blob. Per altre informazioni su per altri servizi di Azure, vedere Configurazione DNS dell'endpoint groupId privato di Azure nella colonna Sottorisorsa. Quando il criterio trova groupId nell'endpoint privato, distribuisce un privateDNSZoneGroup oggetto all'interno dell'endpoint privato e lo collega all'ID risorsa della zona DNS privato specificato come parametro. Nell'esempio l'ID risorsa della zona DNS privata è:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net
L'esempio di codice seguente illustra la definizione dei criteri:
{
"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"
}
}
}
}
Secondo DeployIfNotExists criterio - Corrispondenza su groupId & privateLinkServiceId
Questo criterio viene attivato se si crea una risorsa endpoint privato con un oggetto specifico groupId del servizio e privateLinkServiceId. groupId è l'ID del gruppo ottenuto dalla risorsa remota (servizio) a cui deve connettersi l'endpoint privato. privateLinkServiceId è l'ID risorsa della risorsa remota (servizio) a cui deve connettersi questo endpoint privato. Attivare quindi una distribuzione di all'interno privateDNSZoneGroup dell'endpoint privato, che associa l'endpoint privato alla zona DNS privata.
Nell'esempio, per groupId Azure Cosmos DB (SQL) è SQL e deve privateLinkServiceId contenere Microsoft.DocumentDb/databaseAccounts. Per altre informazioni su e privateLinkServiceId per altri servizi di Azure, vedere Configurazione DNS dell'endpoint groupId privato di Azure nella colonna Sottorisorsa. Quando il criterio trova groupId e privateLinkServiceId nell'endpoint privato, distribuisce un privateDNSZoneGroup all'interno dell'endpoint privato. Ed è collegato all'ID risorsa della zona DNS privato specificato come parametro. La definizione di criteri seguente mostra l'ID risorsa della zona DNS privato:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com
L'esempio di codice seguente illustra la definizione dei criteri:
{
"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"
}
}
}
Assegnazioni di criteri
Dopo la distribuzione delle definizioni dei criteri, assegnare i criteri nell'ambito desiderato nella gerarchia dei gruppi di gestione. Assicurarsi che le assegnazioni dei criteri siano destinate alle sottoscrizioni di Azure usate dai team dell'applicazione per distribuire i servizi PaaS con accesso esclusivo agli endpoint privati.
Importante
Oltre ad assegnare il ruolo RoleDefinition definito nei criteri, ricordarsi di assegnare il ruolo collaboratore DNS privato zona nella sottoscrizione e nel gruppo di risorse in cui le zone DNS private sono ospitate nell'identità gestita creata dall'assegnazione DeployIfNotExists di criteri che sarà responsabile di creare e gestire il record DNS dell'endpoint privato nella zona DNS privata. Ciò è dovuto al fatto che l'endpoint privato si trova nella sottoscrizione di Azure del proprietario dell'applicazione, mentre la zona DNS privato si trova in una sottoscrizione diversa, ad esempio una sottoscrizione di connettività centrale.
Al termine della configurazione, il team della piattaforma:
- Le sottoscrizioni di Azure dei team delle applicazioni sono pronte per consentire al team di creare servizi PaaS di Azure con accesso esclusivo agli endpoint privati.
- Il team deve assicurarsi che i record DNS per gli endpoint privati vengano registrati automaticamente (e rimossi dopo l'eliminazione di un endpoint privato) dalle zone DNS private corrispondenti.
Esperienza del proprietario dell'applicazione
Dopo che il team della piattaforma distribuisce i componenti dell'infrastruttura della piattaforma (zone e criteri DNS privati), il proprietario dell'applicazione ha l'esperienza seguente quando tenta di distribuire un servizio PaaS di Azure nella sottoscrizione di Azure. Questa esperienza è la stessa se eseguono le attività tramite l'portale di Azure o altri client, ad esempio PowerShell o l'interfaccia della riga di comando, perché i criteri di Azure regolano le sottoscrizioni.
Creare un account di archiviazione tramite il portale di Azure. Nella scheda Informazioni di base scegliere le impostazioni desiderate, specificare un nome per l'account di archiviazione e selezionare Avanti.
Nella scheda Rete selezionare Endpoint privato. Se si seleziona un'opzione diversa dall'endpoint privato, il portale di Azure non consente di creare l'account di archiviazione nella sezione Rivedi e crea della distribuzione guidata. Il criterio impedisce la creazione di questo servizio se l'endpoint pubblico è abilitato.
È possibile creare l'endpoint privato ora o dopo aver creato l'account di archiviazione. Questo esempio mostra la creazione dell'endpoint privato dopo la creazione dell'account di archiviazione. Selezionare Rivedi e crea per completare il passaggio.
Dopo aver creato l'account di archiviazione, creare un endpoint privato tramite il portale di Azure.
Nella sezione Risorsa individuare l'account di archiviazione creato nel passaggio precedente. In Sottorisorsa di destinazione selezionare BLOB e quindi selezionare Avanti.
Nella sezione Configurazione, dopo aver selezionato la rete virtuale e la subnet, assicurarsi che l'integrazione con la zona DNS privata sia impostata su No. In caso contrario, il portale di Azure impedisce di creare l'endpoint privato. Criteri di Azure non consente di creare una zona DNS privata con il
privatelinkprefisso .
Selezionare Rivedi e crea e quindi Crea per distribuire l'endpoint privato.
Dopo alcuni minuti, i
DeployIfNotExistscriteri vengono attivati. La distribuzione successivadnsZoneGroupaggiunge quindi i record DNS necessari per l'endpoint privato nella zona DNS gestita centralmente.Dopo aver creato l'endpoint privato, selezionarlo ed esaminarne il nome di dominio completo e l'INDIRIZZO IP privato:
Controllare il log attività per il gruppo di risorse in cui è stato creato l'endpoint privato. In alternativa, è possibile controllare il log attività dell'endpoint privato stesso. Si noterà che dopo alcuni minuti viene eseguita un'azione
DeployIfNotExistdei criteri e che configura il gruppo di zone DNS nell'endpoint privato:
Se il team di rete centrale passa alla
privatelink.blob.core.windows.netzona DNS privata, verifica che il record DNS sia presente per l'endpoint privato creato e che il nome e l'indirizzo IP corrispondano ai valori all'interno dell'endpoint privato.
A questo punto, i team dell'applicazione possono usare l'account di archiviazione tramite un endpoint privato da qualsiasi rete virtuale nell'ambiente di rete hub-spoke e da locale. Il record DNS è stato registrato automaticamente nella zona DNS privata.
Se un proprietario dell'applicazione elimina l'endpoint privato, i record corrispondenti nella zona DNS privata vengono rimossi automaticamente.
Passaggi successivi
Vedere DNS per le risorse locali e di Azure. Vedere Pianificare l'accesso remoto alle macchine virtuali.
Importante
Questo articolo descrive l'integrazione di DNS e collegamento privato su larga scala usando i criteri DINE (DeployIfNotExists) assegnati al gruppo di gestione. Ciò significa che non è necessario gestire l'integrazione DNS nel codice durante la creazione di endpoint privati con questo approccio, perché viene gestito dai criteri. È anche improbabile che i team dell'applicazione abbiano accesso in base al ruolo alle zone di DNS privato centralizzate.
Di seguito sono riportati collegamenti utili da esaminare quando si crea un endpoint privato con Bicep e HashiCorp Terraform.
Per la creazione di endpoint privati con infrastruttura come codice:
Creare un endpoint privato usando HashiCorp Terraform azurerm_private_endpoint in Terrafrom Registry.
È comunque possibile creare endpoint privati negli strumenti di infrastruttura come codice, tuttavia, se si usa l'approccio ai criteri DINE come descritto in questo articolo, è consigliabile lasciare il lato integrazione DNS dal codice e lasciare che i criteri DINE che abbiano il controllo degli accessi in base al ruolo richiesto per le zone di DNS privato gestiscono questa operazione.