Private Link und DNS-Integration im großen Stil
In diesem Artikel wird beschrieben, wie Sie Azure Private Link für PaaS-Dienste mit privaten Azure DNS-Zonen in Hub-and-Spoke-Netzwerkarchitekturen integrieren.
Einführung
Viele Kunden erstellen ihre Netzwerkinfrastruktur in Azure mithilfe der Hub-and-Spoke-Netzwerkarchitektur. Dabei gilt Folgendes:
- Freigegebene Netzwerkdienste (z. B. virtuelle Netzwerkgeräte, ExpressRoute-/VPN-Gateways oder DNS-Server) werden im virtuellen Hub-Netzwerk (VNet) bereitgestellt.
- Spoke-VNets nutzen die gemeinsamen Dienste mithilfe von VNet-Peering.
In Hub-and-Spoke-Netzwerkarchitekturen wird den Besitzern von Anwendungen in der Regel ein Azure-Abonnement zur Verfügung gestellt, das ein VNet (Spoke) umfasst, das mit dem virtuellen Hub-Netzwerk verbunden ist. In dieser Architektur können sie ihre virtuellen Computer bereitstellen und verfügen über eine private Konnektivität zu anderen VNets oder zu lokalen Netzwerken über ExpressRoute oder VPN.
Die ausgehende Internetkonnektivität wird über ein zentrales virtuelles Netzwerkgerät (NVA) wie Azure Firewall bereitgestellt.
Viele Anwendungsteams erstellen ihre Lösungen mithilfe einer Kombination aus Azure IaaS- und PaaS-Ressourcen. Einige Azure PaaS-Dienste (z. B. SQL Managed Instance) können in VNets von Kunden bereitgestellt werden. Dies hat zur Folge, dass der Datenverkehr innerhalb des Azure-Netzwerks privat bleibt und von lokalen Standorten aus vollständig routingfähig ist.
Einige Azure PaaS-Dienste (z. B. Azure Storage oder Azure Cosmos DB) können jedoch nicht in den VNets eines Kunden bereitgestellt werden und sind über ihren öffentlichen Endpunkt zugänglich. In einigen Fällen kann diese Konfiguration zu Konflikten mit den Sicherheitsrichtlinien eines Kunden führen. Der Datenverkehr des Unternehmens erlaubt möglicherweise keine Bereitstellung oder keinen Zugriff auf Unternehmensressourcen (z. B. eine SQL-Datenbank) über öffentliche Endpunkte.
Azure Private Link unterstützt den Zugriff auf eine Liste von Azure-Diensten über private Endpunkte, erfordert jedoch, dass Sie diese privaten Endpunkteinträge in einer entsprechenden privaten DNS-Zone registrieren.
In diesem Artikel wird beschrieben, wie Anwendungsteams Azure PaaS-Dienste in ihren Abonnements bereitstellen können, die nur über private Endpunkte zugänglich sind.
In diesem Artikel wird auch beschrieben, wie Anwendungsteams sicherstellen können, dass Dienste automatisch mit privaten DNS-Zonen integriert werden. Die Automatisierung erfolgt über ein privates DNS in Azure, wodurch die Notwendigkeit entfällt, Einträge in DNS manuell zu erstellen oder zu löschen.
Integration von Private Link und DNS in Hub-and-Spoke-Netzwerkarchitekturen
Private DNS-Zonen werden in der Regel zentral in demselben Azure-Abonnement gehostet, in dem auch das Hub-VNet bereitgestellt wird. Diese Praxis des zentralen Hostings wird durch die standortübergreifende DNS-Namensauflösung und andere Anforderungen an die zentrale DNS-Auflösung, z. B. Active Directory, gesteuert. In den meisten Fällen verfügen nur Netzwerk- und Identitätsadministratoren über die Berechtigung, DNS-Einträge in den Zonen zu verwalten.
Anwendungsteams haben die Berechtigung, Azure-Ressourcen in ihrem eigenen Abonnement zu erstellen. Sie besitzen keine Berechtigungen im Abonnement für die zentrale Netzwerkkonnektivität, was die Verwaltung von DNS-Einträgen in den privaten DNS-Zonen umfasst. Diese Zugriffsbeschränkung bedeutet, dass sie nicht die Möglichkeit haben, die bei der Bereitstellung von Azure PaaS-Diensten mit privaten Endpunkten erforderlichen DNS-Einträge zu erstellen.
Das folgende Diagramm zeigt eine typische allgemeine Architektur für Unternehmensumgebungen mit zentraler DNS-Auflösung, bei der die Namensauflösung für Private Link-Ressourcen über Azure Private DNS erfolgt:
Im vorhergehenden Diagramm muss Folgendes hervorgehoben werden:
- Lokale DNS-Server verfügen über bedingte Forwarder, die für jede öffentliche DNS-Zone des privaten Endpunkts konfiguriert sind und auf den im Hub-VNet gehosteten Private DNS Resolver verweisen.
- Der im Hub VNet gehostete Private DNS Resolver verwendet den von Azure bereitgestellten DNS (168.63.129.16) als Forwarder.
- Das Hub-VNet muss mit den Namen der privaten DNS-Zonen für Azure-Dienste verknüpft sein (z. B.
privatelink.blob.core.windows.net, wie im Diagramm dargestellt). - Alle Azure-VNets verwenden den im Hub-VNet gehosteten privaten DNS-Resolver.
- Da der private DNS-Resolver für die Unternehmensdomänen des Kunden nicht maßgebend ist, da er nur ein Forwarder ist (z. B. Active Directory-Domänennamen), sollte er ausgehende Endpunkt-Forwarder zu den Unternehmensdomänen des Kunden haben, die auf die lokalen DNS-Server (172.16.1.10 und 172.16.1.11) oder auf in Azure bereitgestellte DNS-Server verweisen, die für solche Zonen maßgebend sind.
Während das vorherige Diagramm eine einzelne Hub-Spoke-Architektur darstellt, müssen Kunden möglicherweise ihren Azure-Footprint auf mehrere Regionen ausdehnen, um Anforderungen an Resilienz, geografische Nähe oder Datenresidenz zu erfüllen. Es haben sich mehrere Szenarien ergeben, in denen über mehrere private Endpunkte (PEs) auf dieselbe Private Link-fähige PaaS-Instanz zugegriffen werden muss.
Das folgende Diagramm zeigt eine typische allgemeine Architektur für Unternehmensumgebungen mit zentraler DNS-Auflösung, die im Hub bereitgestellt wird (ein Hub pro Region). Hierbei erfolgt die Namensauflösung für Private Link-Ressourcen über privates Azure-DNS.
Es wird empfohlen, mehrere regionale private Endpunkte bereitzustellen, die der PaaS-Instanz zugeordnet sind (einen in jeder Region, die Clients enthält), und regionsbezogene Private Link-Instanzen und private DNS-Zonen zu aktivieren. Beim Arbeiten mit PaaS-Diensten mit integrierten DR-Funktionen (z. B. georedundante Speicherkonten oder SQL-DB-Failovergruppen) sind mehrere private Endpunkte in mehreren Regionen obligatorisch.
Dieses Szenario erfordert manuelle Wartung/Aktualisierungen des Private Link-DNS-Ressourceneintragssatzes in den einzelnen Regionen, weil derzeit dafür keine automatisierte Lebenszyklusverwaltung vorhanden ist.
Für andere Anwendungsfälle kann ein einzelner globaler privater Endpunkt bereitgestellt und für alle Clients zugänglich gemacht werden, indem Routing aus den relevanten Regionen zum einzelnen privaten Endpunkt in einer einzelnen Region hinzugefügt wird.
Um die Auflösung und damit Konnektivität von lokalen Netzwerken zur privaten DNS-Zone privatelink und zu privaten Endpunkten zu ermöglichen, muss die entsprechende DNS-Konfiguration (bedingte Weiterleitungen usw.) in der DNS-Infrastruktur bereitgestellt werden.
Es gibt zwei Bedingungen, die erfüllt sein müssen, damit Anwendungsteams alle erforderlichen Azure PaaS-Ressourcen in ihrem Abonnement erstellen können:
- Das zentrale Netzwerkteam und/oder das zentrale Plattformteam muss sicherstellen, dass Anwendungsteams nur über private Endpunkte Azure PaaS-Dienste bereitstellen und darauf zugreifen können.
- Die zentralen Netzwerk- und/oder Plattformteams müssen sicherstellen, dass beim Erstellen privater Endpunkte festgelegt wird, wie die entsprechenden Einträge behandelt werden sollen. Richten Sie die entsprechenden Einträge so ein, dass sie automatisch in der zentralen privaten DNS-Zone erstellt werden, die dem erstellten Dienst entspricht.
- Der DNS-Eintrag muss dem Lebenszyklus des privaten Endpunkts folgen und automatisch entfernt werden, wenn der private Endpunkt gelöscht wird.
Hinweis
wenn FQDNs in Netzwerkregeln, die auf der DNS-Auflösung basieren, in Azure Firewall- und Firewallrichtlinien verwendet werden müssen (Mit dieser Funktion können Sie ausgehenden Datenverkehr mit jedem TCP/UDP-Protokoll filtern, einschließlich NTP, SSH, RDP und mehr). Sie müssen Azure Firewall DNS-Proxy aktivieren, um FQDNs in Ihren Netzwerkregeln zu verwenden. Dann sind diese Spoke-VNETs gezwungen, ihre DNS-Einstellung von benutzerdefiniertem DNS-Server zu Azure Firewall DNS-Proxy zu ändern. Zum Ändern der DNS-Einstellungen eines Spoke-VNET ist ein Neustart aller VMs in diesem VNET erforderlich.
In den folgenden Abschnitten wird beschrieben, wie Anwendungsteams diese Bedingungen mithilfe von Azure Policy aktivieren. Im Beispiel wird Azure Storage als Azure-Dienst verwendet, den Anwendungsteams bereitstellen müssen. Das gleiche Prinzip gilt jedoch für die meisten Azure-Dienste, die Private Link unterstützen.
Für das Plattformteam erforderliche Konfiguration
Die Konfigurationsanforderungen des Plattformteams umfassen das Erstellen der privaten DNS-Zonen, das Einrichten von Richtliniendefinitionen, das Bereitstellen von Richtlinien und das Einrichten der Richtlinienzuweisungen.
Create private DNS zones (Erstellen von privaten DNS-Zonen)
Erstellen Sie private DNS-Zonen im zentralen Konnektivitätsabonnement für die unterstützten Private Link-Dienste. Weitere Informationen finden Sie unter DNS-Konfiguration für private Azure-Endpunkte.
In diesem Fall wird ein Speicherkonto mit Blob als Beispiel verwendet. Es sorgt dafür, dass die private DNS-Zone privatelink.blob.core.windows.net im Konnektivitätsabonnement erstellt wird.
Richtliniendefinitionen
Zusätzlich zu den privaten DNS-Zonen müssen Sie auch benutzerdefinierte Azure Policy-Definitionen erstellen. Diese Definitionen erzwingen die Verwendung privater Endpunkte und automatisieren die Erstellung des DNS-Eintrags in der erstellten DNS-Zone:
Deny-Richtlinie zum Verweigern öffentlicher Endpunkte für PaaS-DiensteDiese Richtlinie verhindert, dass Benutzer Azure PaaS-Dienste mit öffentlichen Endpunkten erstellen und eine Fehlermeldung angezeigt wird, wenn sie beim Erstellen der Ressource nicht den privaten Endpunkt auswählen.
Die genaue Richtlinienregel kann sich zwischen den einzelnen PaaS-Diensten unterscheiden. Für Azure Storage-Konten definiert die Eigenschaft networkAcls.defaultAction, ob Anforderungen aus öffentlichen Netzwerken zulässig sind. Legen Sie in diesen Fall eine Bedingung fest, um die Erstellung des Ressourcentyps Microsoft.Storage/storageAccounts zu verweigern, wenn die Eigenschaft networkAcls.defaultAction nicht
Denyist. Die folgende Richtliniendefinition veranschaulicht das Verhalten:{ "mode": "All", "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction", "notEquals": "Deny" } ] }, "then": { "effect": "Deny" } } }Verweigern (
Deny) der Möglichkeit zum Erstellen einer privaten DNS-Zone mit derprivatelink-Präfixrichtlinie.Verwenden Sie eine zentrale DNS-Architektur mit einer bedingten Weiterleitung und privaten DNS-Zonen, die in den vom Plattformteam verwalteten Abonnements gehostet werden. Es muss verhindert werden, dass die Anwendungsteambesitzer eigene private DNS-Zonen für Private Link erstellen und Dienste in ihren Abonnements verknüpfen.
Achten Sie darauf, dass die Option
Integrate with private DNS zoneim Azure-Portal aufNofestgelegt ist, wenn das Anwendungsteam einen privaten Endpunkt erstellt.
Wenn Sie
Yesauswählen, verhindert Azure Policy die Erstellung des privaten Endpunkts. In der Richtliniendefinition wird die Möglichkeit, den Ressourcentyp Microsoft.Network/privateDnsZones zu erstellen, wenn die Zone das Präfixprivatelinkaufweist, verweigert. Die folgende Richtliniendefinition veranschaulicht dasprivatelink-Präfix:{ "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-Richtlinie zum automatischen Erstellen des erforderlichen DNS-Eintrags in der zentralen privaten DNS-ZoneDie folgenden Richtlinienbeispiele zeigen zwei Möglichkeiten, um festzustellen, welche
privateDNSZoneGroupauf einem privaten Endpunkt erstellt wird.Die erste Richtlinie basiert auf der
groupId, während die zweite Richtlinie sowohl alsprivateLinkServiceIdauchgroupIDverwendet. Verwenden Sie die zweite Richtlinie, wenngroupIdmit einer anderen Ressource in Konflikt steht (kollidiert).Die
groupIdSQL wird beispielsweise für Cosmos DB und Synapse Analytics verwendet. Wenn beide Ressourcentypen bereitstellt wurden und die erste Richtlinie zugewiesen wurde, um dieprivateDNSZoneGroupim Eintrag für den privaten Endpunkt zu erstellen, wird sie erstellt und der falschen privaten DNS-Zone von Cosmos DB oder Synapse Analytics zugeordnet. Wegen der in Konflikt stehendengroupId, die die erste Richtlinie in der Richtlinienregel sucht, ist unklar, welche Zone verwendet werden soll.Eine Liste der
groupIdfür Privat Link-Ressourcen finden Sie in der Spalte für untergeordnete Ressourcen in Was ist ein privater Endpunkt?.
Tipp
Integrierte Azure Policy-Definitionen werden laufend hinzugefügt, gelöscht und aktualisiert. Es wird dringend empfohlen, (sofern verfügbar) integrierte Richtlinien zu verwenden anstatt eigene Richtlinien zu verwalten. Verwenden Sie AzPolicyAdvertizer, um vorhandene integrierte Richtlinien zu finden, die einen Namen wie „xxx ... für die Verwendung privater DNS-Zonen“ o. ä. aufweisen. Darüber hinaus verfügt Azure Landing Zones (ALZ) über eine Richtlinieninitiative zum Konfigurieren von Azure PaaS-Diensten für die Verwendung privater DNS-Zonen, die integrierte Richtlinien enthält und regelmäßig aktualisiert wird. Wenn keine integrierte Richtlinie für die jeweilige Situation verfügbar ist, sollten Sie ein Issue auf der azure-policy-Feedbackwebsite der Azure Governance Community erstellen (siehe Beschreibung im Abschnitt zum Prozess für neue integrierte Richtlinienvorschläge im Azure Policy GitHub-Repository).
Erste DeployIfNotExists-Richtlinie: Nur Übereinstimmung mit groupId
Diese Richtlinie löst aus, wenn Sie eine private Endpunktressource mit einer dienstspezifischen groupId erstellen. Die groupId ist die ID der Gruppe, die von der Remoteressource (Dienst) bezogen wird, mit der dieser private Endpunkt verbunden werden soll. Anschließend wird eine Bereitstellung einer privateDNSZoneGroup im privaten Endpunkt ausgelöst, die den privaten Endpunkt mit der privaten DNS-Zone verknüpft. Im Beispiel lautet die groupId für Azure Storage-Blobs blob. Weitere Informationen zur groupId für andere Azure-Dienste finden Sie im Artikel zur DNS-Konfiguration für private Azure-Endpunkte unter der Spalte für untergeordnete Ressourcen. Wenn die Richtlinie die groupId im privaten Endpunkt findet, wird eine privateDNSZoneGroup im privaten Endpunkt bereitgestellt und mit der Ressourcen-ID der privaten DNS-Zone verknüpft, die als Parameter angegeben ist. Im vorliegenden Beispiel ist die Ressourcen-ID der privaten DNS-Zone:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net
Das folgende Codebeispiel veranschaulicht die Richtliniendefinition:
{
"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"
}
}
}
}
Zweite DeployIfNotExists-Richtlinie: Übereinstimmung mit groupId und privateLinkServiceId
Diese Richtlinie löst aus, wenn Sie eine private Endpunktressource mit einer dienstspezifischen groupId und privateLinkServiceId erstellen. Die groupId ist die ID der Gruppe, die von der Remoteressource (Dienst) bezogen wird, mit der dieser private Endpunkt verbunden werden soll. Die privateLinkServiceId ist die Ressourcen-ID der Remoteressource (Dienst), mit der der private Endpunkt verbunden werden soll. Anschließend wird eine Bereitstellung einer privateDNSZoneGroup im privaten Endpunkt ausgelöst, die den privaten Endpunkt mit der privaten DNS-Zone verknüpft.
Im Beispiel ist die groupId für Azure Cosmos DB (SQL) SQL, und die privateLinkServiceId muss Microsoft.DocumentDb/databaseAccounts enthalten. Weitere Informationen zur groupId und privateLinkServiceId für andere Azure-Dienste finden Sie im Artikel zur DNS-Konfiguration für private Azure-Endpunkte unter der Spalte für untergeordnete Ressourcen. Wenn die Richtlinie groupId und privateLinkServiceId im privaten Endpunkt findet, wird eine privateDNSZoneGroup im privaten Endpunkt bereitgestellt. Sie wird außerdem mit der Ressourcen-ID der privaten DNS-Zone verknüpft, die als Parameter angegeben ist. Die folgende Richtliniendefinition veranschaulicht die Ressourcen-ID der privaten DNS-Zone:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com
Das folgende Codebeispiel veranschaulicht die Richtliniendefinition:
{
"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"
}
}
}
Richtlinienzuweisungen
Sobald die Richtliniendefinitionen bereitgestellt wurden, weisen Sie die Richtlinien im gewünschten Umfang in Ihrer Verwaltungsgruppenhierarchie zu. Stellen Sie sicher, dass die Richtlinienzuweisungen auf die Azure-Abonnements ausgerichtet sind, die die Anwendungsteams verwenden, um ausschließlich PaaS-Dienste mit privatem Endpunktzugriff bereitzustellen.
Wichtig
Zusätzlich zum Zuweisen der roleDefinition, die in der Richtlinie definiert ist, denken Sie daran, die Rolle Mitwirkender für private DNS-Zone im Abonnement und in der Ressourcengruppe, in der die privaten DNS-Zonen gehostet werden, der durch die Richtlinienzuweisung DeployIfNotExists erstellten verwalteten Identität zuzuweisen, die für das Erstellen und Verwalten des DNS-Eintrags für den privaten Endpunkt in der privaten DNS-Zone verantwortlich sein wird. Dies liegt daran, dass sich der private Endpunkt im Azure-Abonnement des Besitzers der Anwendung befindet, während sich die private DNS-Zone in einem anderen Abonnement befindet (z. B. im zentralen Konnektivitätsabonnement).
Nachdem das Plattformteam die Konfiguration durchgeführt hat:
- Die Azure-Abonnements des Anwendungsteams sind soweit vorbereitet, dass das Team dann Azure PaaS-Dienste ausschließlich mit privatem Endpunktzugriff erstellen kann.
- Das Team muss sicherstellen, dass die DNS-Einträge für private Endpunkte automatisch in den entsprechenden privaten DNS-Zonen registriert werden (und entfernt werden, sobald ein privater Endpunkt gelöscht wird).
Erfahrung des Anwendungsbesitzers
Nachdem das Plattformteam die Plattforminfrastrukturkomponenten (private DNS-Zonen und -Richtlinien) bereitgestellt hat, verfügt der Anwendungsbesitzer über die folgende Funktionalität, wenn er einen Azure PaaS-Dienst im Azure-Abonnement bereitstellen möchte. Diese Funktionalität ist unabhängig davon, ob sie ihre Aktivitäten über das Azure-Portal oder andere Clients durchführen, z. B. PowerShell oder CLI, immer gleich, da Azure-Richtlinien die Abonnements steuern.
Erstellen Sie ein Speicherkonto über das Azure-Portal. Wählen Sie auf der Registerkarte Grundlagen die gewünschten Einstellungen aus, geben Sie einen Namen für Ihr Speicherkonto an, und wählen Sie Weiter aus.
Wählen Sie auf der Registerkarte „Netzwerk“ die Option Privater Endpunkt aus. Wenn Sie eine andere Option als Privater Endpunkt auswählen, können Sie das Speicherkonto im Abschnitt Überprüfen + erstellen des Bereitstellungs-Assistenten im Azure-Portal nicht erstellen. Die Richtlinie verhindert die Erstellung dieses Diensts, wenn der öffentliche Endpunkt aktiviert ist.
Es ist möglich, den privaten Endpunkt jetzt oder nach dem Erstellen des Speicherkontos zu erstellen. In diesem Beispiel wird der private Endpunkt erstellt, nachdem das Speicherkonto erstellt wurde. Wählen Sie die Option Überprüfen + erstellen aus, um den Schritt durchzuführen.
Nachdem das Speicherkonto erstellt wurde, erstellen Sie einen privaten Endpunkt im Azure-Portal.
Suchen Sie im Abschnitt Ressource das Speicherkonto, das Sie im vorherigen Schritt erstellt haben. Wählen Sie Blob als untergeordnete Zielressource und dann Weiter aus.
Vergewissern Sie sich im Abschnitt Konfiguration, nachdem Sie Ihr VNet und Subnetz ausgewählt haben, dass In private DNS-Zone integrieren auf Nein festgelegt ist. Andernfalls verhindert das Azure-Portal, dass Sie den privaten Endpunkt erstellen. Azure Policy verhindert das Erstellen einer privaten DNS-Zone mit dem Präfix
privatelink.
Wählen Sie Überprüfen und erstellen und dann Erstellen aus, um den privaten Endpunkt bereitzustellen.
Nach ein paar Minuten wird die
DeployIfNotExists-Richtlinie ausgelöst. Bei der anschließendendnsZoneGroup-Bereitstellung werden die erforderlichen DNS-Einträge für den privaten Endpunkt in der zentral verwalteten DNS-Zone hinzugefügt.Wählen Sie den privaten Endpunkt aus, nachdem er erstellt wurde, und überprüfen Sie FQDN sowie private IP-Adresse des Endpunkts:
Überprüfen Sie das Aktivitätsprotokoll für die Ressourcengruppe, in der private Endpunkt erstellt wurde. Sie können auch das Aktivitätsprotokoll des privaten Endpunkts selbst überprüfen. Sie werden feststellen, dass nach ein paar Minuten eine
DeployIfNotExist-Richtlinienaktion ausgeführt wird, die die DNS-Zonengruppe für den privaten Endpunkt konfiguriert:
Wenn das zentrale Netzwerkteam zur privaten DNS-Zone
privatelink.blob.core.windows.netwechselt, bestätigt es, dass der DNS-Eintrag für den erstellten privaten Endpunkt erstellt wurde und sowohl der Name als auch die IP-Adresse mit den Werten im privaten Endpunkt übereinstimmen.
Zu diesem Zeitpunkt können Anwendungsteams das Speicherkonto über einen privaten Endpunkt von jedem VNet in der Hub-and-Spoke-Netzwerkumgebung und von lokalen Standorten aus verwenden. Der DNS-Eintrag wurde automatisch in der privaten DNS-Zone erfasst.
Wenn ein Besitzer der Anwendung den privaten Endpunkt löscht, werden die entsprechenden Einträge in der privaten DNS-Zone automatisch entfernt.
Nächste Schritte
Lesen Sie DNS für lokale und Azure-Ressourcen. Lesen Sie Planen des Remotezugriffs auf virtuelle Computer.
Wichtig
In diesem Artikel wird die Integration von DNS und Private Link mithilfe von DINE-Richtlinien (DeployIfNotExists) beschrieben, die der Verwaltungsgruppe zugewiesen werden. Dies bedeutet, dass die DNS-Integration bei diesem Ansatz nicht im Code vorgenommen werden muss, wenn private Endpunkte erstellt werden, da dies von den Richtlinien erledigt wird. Außerdem ist es unwahrscheinlich, dass die Anwendungsteams über RBAC-Zugriff auf die zentralen privaten DNS-Zonen verfügen.
Nachfolgend finden Sie hilfreiche Links, wenn Sie private Endpunkte mit Bicep und HashiCorp Terraform erstellen möchten.
Für die Erstellung privater Endpunkte mit Infrastructure-as-Code:
Schnellstart: Erstellen eines privaten Endpunkts mithilfe von Bicep.
Erstellen Sie einen privaten Endpunkt mit HashiCorp Terraform azurerm_private_endpoint in Terrafrom Registry.
Sie können weiterhin private Endpunkte in Ihrem Infrastructure-as-Code-Tool erstellen. Wenn Sie jedoch den in diesem Artikel beschriebenen DINE-Richtlinienansatz verwenden, sollten Sie die DNS-Integration aus Ihrem Codes auslassen und dies stattdessen von den DINE-Richtlinien mit der erforderlichen rollenbasierten Zugriffssteuerung für die privates DNS-Zonen erledigen lassen.
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für