Private Link et intégration DNS à grande échelle

Article
10/25/2023

Cet article décrit la procédure d’intégration d’Azure Private Link pour les services PaaS à des zones DNS privées Azure dans des architectures de réseau Hub and Spoke.

Introduction

De nombreux clients créent leur infrastructure réseau dans Azure à l’aide de l’architecture de réseau Hub and Spoke, où :

Les services partagés de mise en réseau (tels que les appliances virtuelles réseau, les passerelles ExpressRoute/VPN ou les serveurs DNS) se déploient dans le réseau virtuel (VNet) du hub.
Les réseaux virtuels Spoke consomment les services partagés par le biais du peering VNet.

Dans les architectures de réseau Hub and Spoke, les propriétaires d’applications reçoivent généralement un abonnement Azure, qui comprend un réseau virtuel (Spoke) connecté au réseau virtuel Hub. Dans cette architecture, ils peuvent déployer leurs machines virtuelles et disposer d’une connectivité privée sur d’autres VNets ou des réseaux locaux par le biais d’ExpressRoute ou de VPN.

Une appliance virtuelle réseau (NVA) centrale, telle qu’Azure Firewall, assure la connectivité sortante vers Internet.

De nombreuses équipes d’applications créent leurs solutions à l’aide d’une combinaison de ressources Azure IaaS et PaaS. Certains services PaaS Azure (tels que SQL Managed Instance) peuvent être déployés dans des réseaux virtuels client. Par conséquent, le trafic reste privé au sein du réseau Azure et peut être entièrement acheminé depuis l’environnement local.

Mais certains services PaaS Azure (tels qu’Azure Storage ou Azure Cosmos DB) ne peuvent pas être déployés dans les VNets d’un client et sont accessibles via leur point de terminaison public. Dans certains cas, cette configuration provoque une contention avec les stratégies de sécurité d’un client. Le trafic d’entreprise peut ne pas permettre le déploiement ou l’accès à des ressources d’entreprise (telles qu’une base de données SQL) sur des points de terminaison publics.

Azure Private Link prend en charge l’accès à une liste de services Azure par le biais de points de terminaison privés, mais il exige que vous inscriviez ces enregistrements de points de terminaison privés dans une zone DNS privée correspondante.

Cet article décrit comment les équipes responsables des applications peuvent déployer des services PaaS Azure dans leurs abonnements qui ne sont accessibles que par des points de terminaison privés.

Cet article décrit également comment les équipes responsables des applications peuvent s’assurer que les services s’intègrent automatiquement aux zones DNS privées. Elles effectuent l’automatisation via une zone DNS privée Azure, ce qui supprime la nécessité de créer ou de supprimer manuellement des enregistrements dans un DNS.

Private Link et intégration DNS dans des architectures de réseau Hub and Spoke

Les zones DNS privées sont généralement hébergées de manière centralisée dans le même abonnement Azure où le réseau virtuel hub est déployé. Cette pratique d’hébergement central est basée sur la résolution de noms DNS entre différents sites locaux et sur les autres besoins de résolution de DNS central, tels qu’Active Directory. Dans la plupart des cas, seuls les administrateurs réseau et d’identité ont le droit de gérer les enregistrements DNS dans les zones.

Les équipes responsables des applications ont le droit de créer des ressources Azure dans leur propre abonnement. Elles ne disposent d’aucune autorisation dans l’abonnement de connectivité du réseau central, notamment pour la gestion des enregistrements DNS dans les zones DNS privées. Cette limitation d’accès signifie que ces équipes n’ont pas la possibilité de créer les enregistrements DNS requis lors du déploiement de services PaaS Azure avec des points de terminaison privés.

Le diagramme suivant illustre une architecture de haut niveau classique pour les environnements d’entreprise avec une résolution de DNS central et dans laquelle la résolution de noms pour les ressources Private Link est effectuée via Azure DNS privé :

A diagram of a high-level architecture with central DNS resolution and name resolution for Private Link resources.

Dans le diagramme précédent, il est important de souligner les éléments suivants :

Les serveurs DNS locaux ont des redirecteurs conditionnels configurés pour chaque zone DNS publique de point de terminaison privé, qui pointent vers le DNS Private Resolver hébergé dans le réseau virtuel du hub.
Le DNS Private Resolver hébergé dans le réseau virtuel du hub utilisent le DNS (168.63.129.16) fourni par Azure comme redirecteur.
Le réseau virtuel hub doit être lié aux noms de zones DNS privées pour les services Azure (tels que privatelink.blob.core.windows.net, comme indiqué dans le diagramme).
Tous les réseaux virtuels Azure utilisent un DNS Private Resolver hébergé dans le réseau virtuel du hub
Comme le DNS Private Resolver ne fait pas autorité pour les domaines d’entreprise du client, car il s’agit simplement d’un forwarder (par exemple, les noms de domaine Active Directory), il devrait avoir des forwarders de point de terminaison sortant vers les domaines d’entreprise du client, pointant vers les serveurs DNS sur site (172.16.1.10 et 172.16.1.11) ou les serveurs DNS déployés dans Azure qui font autorité pour de telles zones.

Bien que le diagramme précédent illustre une architecture hub-and-spoke unique, les clients peuvent avoir besoin d’étendre leur empreinte Azure dans plusieurs régions pour répondre aux exigences de résilience, de proximité ou de résidence des données, plusieurs scénarios ont émergé où la même instance PaaS avec Private Link doit être accessible via plusieurs points de terminaison privés (PE).

Le diagramme suivant illustre une architecture de haut niveau classique pour les environnements d’entreprise avec une résolution de DNS central déployée dans le hub (un par région) et dans laquelle la résolution de noms pour les ressources Private Link est effectuée via Azure DNS privé.

Il est recommandé de déployer plusieurs points de terminaison privés régionaux associés à l’instance PaaS, un dans chaque région où des clients existent et d’activer Private Link et zones DNS privées par région. Lorsque vous utilisez des services PaaS avec des fonctionnalités de récupération d’urgence intégrées (comptes de stockage géoredondants, groupes de basculement SQL DB, etc.), des points de terminaison privés dans plusieurs régions sont obligatoires.

Ce scénario nécessite une maintenance et des mises à jour manuelles du jeu d’enregistrements DNS Private Link dans chaque région, car il n’existe actuellement aucune gestion automatisée du cycle de vie pour ces éléments.

Pour d’autres cas d’usage, un seul point de terminaison privé global peut être déployé, rendu accessible à tous les clients en ajoutant le routage des régions pertinentes au point de terminaison privé unique dans une seule région.

Pour activer la résolution, et donc la connectivité, des réseaux locaux à la zone DNS privée privatelink et aux points de terminaison privés, la configuration DNS appropriée (redirecteurs conditionnels, etc.) doit être approvisionnée dans l’infrastructure DNS.

Deux conditions doivent être remplies pour que les équipes responsables des applications puissent créer toutes les ressources Azure PaaS requises dans leur abonnement :

L’équipe chargée du réseau central et/ou de la plateforme centrale doit s’assurer que les équipes responsables des applications ne peuvent déployer les services PaaS Azure et y accéder que par le biais de points de terminaison privés.
Les équipes chargées du réseau central et/ou de la plateforme centrale doivent s’assurer que lorsqu’elles créent des points de terminaison privés, elles définissent la manière de traiter les enregistrements correspondants. Configurez les enregistrements correspondants afin qu’ils soient automatiquement créés dans la zone DNS privée centralisée qui correspond au service en cours de création.
Les enregistrements DNS doivent suivre le cycle de vie du point de terminaison privé et supprimer automatiquement l’enregistrement DNS lorsque le point de terminaison privé est supprimé.

Remarque

si des noms de domaine complets dans des règles réseau basées sur la résolution DNS doivent être utilisés dans Pare-feu Azure et la stratégie de pare-feu (cette fonctionnalité vous permet de filtrer le trafic sortant avec n’importe quel protocole TCP/UDP, y compris NTP, SSH, RDP, etc.). Vous devez activer Pare-feu Azure proxy DNS pour utiliser des noms de domaine complets dans vos règles réseau, puis ces réseaux virtuels spoke sont obligés de modifier leur paramètre DNS du serveur DNS personnalisé à Pare-feu Azure proxy DNS. La modification des paramètres DNS d’un réseau virtuel spoke nécessite le redémarrage de toutes les machines virtuelles à l’intérieur de ce réseau virtuel.

Les sections suivantes décrivent comment les équipes responsables des applications activent ces conditions en utilisant Azure Policy. L’exemple utilise Stockage Azure en tant que service Azure que les équipes responsables des applications doivent déployer. Mais le même principe s’applique à la plupart des services Azure qui prennent en charge Private Link.

Configuration requise par l’équipe en charge de la plateforme

Les exigences de configuration de l’équipe chargée de la plateforme incluent la création des zones DNS privées, la configuration des définitions de stratégie, le déploiement de stratégies et la configuration des affectations de stratégie.

Créer des zones DNS privées

Créez des zones DNS privées dans l’abonnement de connectivité centrale pour les services Private Link pris en charge. Pour plus d’informations, consultez Configuration DNS des points de terminaison privés Azure.

Dans ce cas, le compte de stockage avec objet blob est le meilleur exemple. Il se traduit par la création d’une zone DNS privée privatelink.blob.core.windows.net dans l’abonnement de connectivité.

A screenshot that shows the private DNS zone in the connectivity subscription.

Définitions de stratégies

Outre les zones DNS privées, vous devez également créer un ensemble de définitions Azure Policy personnalisées. Ces définitions appliquent l’utilisation de points de terminaison privés et automatisent la création de l’enregistrement DNS dans la zone DNS que vous créez :

Stratégie Deny pour refuser le point de terminaison public pour les services PaaS.

Cette stratégie empêche les utilisateurs de créer des services PaaS Azure avec des points de terminaison publics et affiche un message d’erreur s’ils ne sélectionnent pas le point de terminaison privé lors de la création de la ressource.

La règle exacte de la stratégie peut différer entre les services PaaS. Pour les comptes Stockage Azure, examinez la propriété networkAcls.defaultAction qui définit si les demandes provenant de réseaux publics sont autorisées ou non. Dans le cas présent, définissez une condition qui interdit la création du type de ressource Microsoft.Storage/storageAccounts si la propriété networkAcls.defaultAction n’est pas Deny. La définition de stratégie suivante présente le comportement :
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny la possibilité de créer une zone DNS privée avec la stratégie de préfixe privatelink.

Utilisez une architecture DNS centralisée avec un redirecteur conditionnel et des zones DNS privées hébergées dans les abonnements gérés par l’équipe chargée de la plateforme. Il est nécessaire d’empêcher les propriétaires des équipes responsables des applications de créer leurs propres zones DNS privées Private Link et de lier des services à leurs abonnements.

Assurez-vous que lorsque votre équipe responsable des applications crée un point de terminaison privé, l’option Integrate with private DNS zone est définie sur No dans le portail Azure.

Si vous sélectionnez Yes, Azure Policy vous empêche de créer le point de terminaison privé. Dans la définition de stratégie, le service refuse la possibilité de créer le type de ressource Microsoft.Network/privateDnsZones si la zone a le préfixe privatelink. La définition de stratégie suivante montre le préfixe 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"
    }
  }
}
```
Stratégie DeployIfNotExists pour créer automatiquement l’enregistrement DNS requis dans la zone DNS privée centrale.

Les exemples de stratégie suivants montrent deux approches pour identifier le privateDNSZoneGroup qui est créé sur un point de terminaison privé.

La première stratégie s’appuie sur le groupId tandis que la deuxième stratégie utilise à la fois le privateLinkServiceId et le groupID. Utilisez la deuxième stratégie lorsque le groupId est en conflit (collision) avec une autre ressource.

Par exemple, lorsque l’instance groupIdSQL est utilisée pour Cosmos DB et Synapse Analytics. Si les deux types de ressources sont déployés et que la première stratégie a été affectée pour créer le privateDNSZoneGroup sur l’entrée de point de terminaison privé, cet élément est créé et mappé à la zone DNS privée incorrecte, de Cosmos DB ou de Synapse Analytics. Il peut ensuite passer d’une zone à l’autre à cause du groupId conflictuel que la première stratégie recherche dans sa règle de stratégie.

Pour obtenir la liste des ressources Private Link groupId, consultez la colonne des sous-ressources dans Qu’est-ce qu’un point de terminaison privé ?.

Conseil

Des définitions Azure Policy intégrées sont ajoutées, supprimées et mises à jour en permanence. Il est vivement recommandé d’utiliser des stratégies intégrées au lieu de gérer vos propres stratégies (le cas échéant). Utilisez AzPolicyAdvertizer pour rechercher des stratégies intégrées existantes portant le nom suivant « xxx ... pour utiliser des zones DNS privées ». En outre, les zones d’atterrissage Azure (ALZ) ont une initiative de stratégie, intitulée Configurer des services PaaS Azure pour utiliser des zones DNS privées, qui contient des stratégies intégrées ainsi que des mises à jour périodiques. Si une stratégie intégrée n’est pas disponible pour votre situation, envisagez de créer un ticket sur le site de commentaires azure-policyAzure Governance · Communauté en choisissant la section Nouvelles propositions de stratégies intégrée sur le référentiel GitHub Azure Policy.

Première stratégie `DeployIfNotExists` - Correspondance avec le `groupId` uniquement

Cette stratégie se déclenche si vous créez une ressource de point de terminaison privée avec un groupId de service spécifique. groupId est l’ID du groupe obtenu de la ressource distante (service) à laquelle ce point de terminaison privé doit se connecter. Elle déclenche ensuite le déploiement d’un privateDNSZoneGroup dans le point de terminaison privé, qui associe le point de terminaison privé à la zone DNS privée. Dans l’exemple, le groupId pour les objets blob de Stockage Azure est blob. Pour plus d’informations sur le groupId des autres services Azure, consultez Configuration DNS du point de terminaison privé Azure dans la colonne Sous-ressource. Lorsque la stratégie trouve le groupId dans le point de terminaison privé, elle déploie un privateDNSZoneGroup dans le point de terminaison privé et le lie à l’ID de ressource de la zone DNS privée qui est spécifiée comme paramètre. Dans l’exemple, l’ID de ressource de la zone DNS privée est :

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

L’exemple de code suivant correspond à la définition de stratégie :

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

Deuxième stratégie `DeployIfNotExists` - Correspondance entre `groupId` et `privateLinkServiceId`

Cette stratégie se déclenche si vous créez une ressource de point de terminaison privée avec un groupId et privateLinkServiceId spécifique du service. groupId est l’ID du groupe obtenu de la ressource distante (service) à laquelle ce point de terminaison privé doit se connecter. Le privateLinkServiceId est l’ID de la ressource (service) à distance à laquelle ce point de terminaison privé doit se connecter. Ensuite, déclenchez le déploiement d’un privateDNSZoneGroup dans le point de terminaison privé, qui associe le point de terminaison privé à la zone DNS privée.

Dans l’exemple, le groupId pour Azure Cosmos DB (SQL) est SQL et le privateLinkServiceId doit contenir Microsoft.DocumentDb/databaseAccounts. Pour plus d’informations sur le groupId et privateLinkServiceId des autres services Azure, voir Configuration DNS des points de terminaison privés Azure dans la colonne Sous-ressource. Lorsque la stratégie trouve les éléments groupId et privateLinkServiceId dans le point de terminaison privé, elle déploie un privateDNSZoneGroup dans le point de terminaison privé. Ce dernier est lié à l’ID de ressource de zone DNS privée spécifiée en tant que paramètre. La définition de stratégie suivante affiche l’ID de ressource de zone DNS privée :

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

L’exemple de code suivant correspond à la définition de stratégie :

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

Attributions de stratégies

Une fois que les définitions de stratégie ont été déployées, attribuez les stratégies à l’étendue souhaitée dans votre hiérarchie de groupes d’administration. Assurez-vous que les affectations de stratégie ciblent les abonnements Azure que les équipes responsables des applications utilisent pour déployer des services PaaS avec un accès privé aux points de terminaison exclusivement.

Important

En plus de l’affectation du paramètre roleDefinition défini dans la stratégie, n’oubliez pas d’attribuer le rôle Contributeur de zone DNS privée dans l’abonnement/groupe de ressources où les zones DNS privées sont hébergées à l’identité managée créée par l’attribution de stratégie DeployIfNotExists qui sera chargée de créer et de gérer l’enregistrement DNS du point de terminaison privé dans la zone DNS privée. Cela est dû au fait que le point de terminaison privé se trouve dans l’abonnement Azure propriétaire de l’application, tandis que la zone DNS privée se trouve dans un autre abonnement (par exemple, un abonnement à la connectivité centrale).

Une fois que l’équipe chargée de la plateforme a terminé la configuration :

Les abonnements Azure des équipes responsables des applications sont prêts pour que l’équipe crée des services PaaS Azure avec un accès exclusif au point de terminaison privé.
L’équipe doit vérifier que les enregistrements DNS pour les points de terminaison privés sont automatiquement inscrits (et supprimés une fois qu’un point de terminaison privé est supprimé) sur les zones DNS privées correspondantes.

Expérience du propriétaire de l’application

Une fois que l’équipe chargée de la plateforme déploie les composants d’infrastructure de plateforme (zones et stratégies DNS privées), le propriétaire de l’application est confronté à l’expérience suivante lorsqu’il tente de déployer un service PaaS Azure dans l’abonnement Azure. Cette expérience est la même que les activités soient effectuées via le portail Azure ou d’autres clients, tels que PowerShell ou l’interface CLI, car les stratégies Azure régissent leurs abonnements.

Créez un compte de stockage via le portail Azure. Sous l’onglet Informations générales, choisissez les paramètres souhaités, indiquez un nom pour votre compte de stockage, puis sélectionnez Suivant.
Dans l’onglet Mise en réseau, sélectionnez Point de terminaison privé. Si vous sélectionnez une option autre que Point de terminaison privé, le portail Azure ne vous permet pas de créer le compte de stockage dans la section Vérifier + créer de l’Assistant Déploiement. La stratégie vous empêche de créer ce service si le point de terminaison public est activé.
Il est possible de créer le point de terminaison privé à ce moment-là ou après avoir créé le compte de stockage. Cet exemple montre comment créer le point de terminaison privé une fois le compte de stockage créé. Sélectionnez Vérifier + créer pour terminer cette étape.
Une fois le compte de stockage créé, vous pouvez créer un point de terminaison privé via le portail Azure.
Dans la section Ressource, recherchez le compte de stockage que vous avez créé à l’étape précédente. Dans Sous-ressource cible, sélectionnez Blob, puis sélectionnez Suivant.
Dans la section Configuration, après avoir sélectionné votre réseau virtuel et votre sous-réseau, vérifiez que l’option Intégrer à la zone DNS privée est définie sur Non. Sinon, le portail Azure vous empêche de créer le point de terminaison privé. Azure Policy ne vous permettra pas de créer une zone DNS privée avec le préfixe privatelink.
Sélectionnez Vérifier + créer, puis Créer pour déployer le point de terminaison privé.
Après quelques minutes, la stratégie DeployIfNotExists se déclenche. Le déploiement dnsZoneGroup ultérieur ajoute ensuite les enregistrements DNS requis pour le point de terminaison privé dans la zone DNS managée de manière centralisée.
Après avoir créé le point de terminaison privé, sélectionnez-le et vérifiez son FQDN et son IP privée :
Vérifiez le journal d’activité du groupe de ressources où le point de terminaison privé a été créé. Vous pouvez également vérifier le journal d’activité du point de terminaison privé lui-même. Vous remarquerez qu’après quelques minutes, une action de stratégie DeployIfNotExist s’exécute et configure le groupe de zones DNS sur le point de terminaison privé :
Si l’équipe chargée du réseau central accède à la zone DNS privée privatelink.blob.core.windows.net, elle confirmera que l’enregistrement DNS existe pour le point de terminaison privé que vous avez créé, et que le nom et l’adresse IP correspondent aux valeurs du point de terminaison privé.

À ce stade, les équipes responsables des applications peuvent utiliser le compte de stockage par l’intermédiaire d’un point de terminaison privé à partir de n’importe quel réseau privé dans l’environnement de réseau Hub-and-Spoke et de l’environnement local. L’enregistrement DNS a été inscrit automatiquement dans la zone DNS privée.

Si le propriétaire d’une application supprime le point de terminaison privé, les enregistrements correspondants dans la zone DNS privée sont automatiquement supprimés.

Étapes suivantes

Consultez DNS pour les ressources locales et Azure. Consultez Planifier l’accès à distance à la machine virtuelle.

Important

Cet article décrit l’intégration du DNS et de Private Link à grande échelle à l’aide de stratégies DINE (DeployIfNotExists) affectées au groupe d’administration. Cela signifie qu’il n’est pas nécessaire de gérer l’intégration DNS dans le code lors de la création de points de terminaison privés avec cette approche, car elle est gérée par les stratégies. Il est également peu probable que les équipes responsables des applications disposent également d’un accès RBAC aux zones DNS privées centralisées.

Vous trouverez ci-dessous des liens utiles à consulter lors de la création d’un point de terminaison privé avec Bicep et HashiCorp Terraform.

Pour la création d’un point de terminaison privé à l’aide d’une infrastructure en tant que code :

Démarrage rapide : Créer un point de terminaison privé à l’aide de Bicep.

Créer un point de terminaison privé à l’aide de HashiCorp Terraform azurerm_private_endpoint dans Terrafrom Registry.

Vous pouvez toujours créer des points de terminaison privés dans votre outil d’infrastructure en tant que code. Toutefois, si vous utilisez l’approche de stratégie DINE comme décrit dans cet article, vous devez laisser l’intégration DNS en dehors de votre code et laisser les stratégies DINE nécessaires au RBAC requis pour les zones DNS privées gérer cela.

Private Link et intégration DNS à grande échelle

Introduction

Private Link et intégration DNS dans des architectures de réseau Hub and Spoke