Private Link en DNS-integratie op schaal

Artikel
10/26/2023

In dit artikel wordt beschreven hoe u Azure Private Link voor PaaS-services integreert met Azure Privé-DNS-zones in hub- en spoke-netwerkarchitecturen.

Inleiding

Veel klanten bouwen hun netwerkinfrastructuur in Azure met behulp van de hub- en spoke-netwerkarchitectuur, waarbij:

Gedeelde netwerkservices (zoals virtuele netwerkapparaten, ExpressRoute/VPN-gateways of DNS-servers) worden geïmplementeerd in het virtuele hubnetwerk (VNet).
Spoke-VNets gebruiken de gedeelde services via VNet-peering.

In hub- en spoke-netwerkarchitecturen worden toepassingseigenaren meestal voorzien van een Azure-abonnement, dat een VNet (a spoke) bevat dat is verbonden met het hub-VNet . In deze architectuur kunnen ze hun virtuele machines implementeren en privéconnectiviteit hebben met andere VNets of on-premises netwerken via ExpressRoute of VPN.

Een virtueel netwerkapparaat (NVA), zoals Azure Firewall, biedt uitgaande internetconnectiviteit. Daarnaast wordt dat apparaat, zoals met Azure Firewall DNS-proxy, of een andere service in of naast de hub gebruikt om DNS-doorsturen aan te passen.

Veel toepassingsteams bouwen hun oplossingen met behulp van een combinatie van Azure IaaS- en PaaS-resources. Sommige Azure PaaS-services (zoals SQL Managed Instance) kunnen worden geïmplementeerd in VNets van klanten. Hierdoor blijft verkeer privé binnen het Azure-netwerk en is het volledig routeerbaar vanaf on-premises.

Sommige Azure PaaS-services (zoals Azure Storage of Azure Cosmos DB) kunnen echter niet worden geïmplementeerd in de VNets van een klant en zijn toegankelijk via hun openbare eindpunt. In sommige gevallen veroorzaakt deze configuratie een conflict met het beveiligingsbeleid van een klant. Bedrijfsverkeer staat de implementatie of toegang tot bedrijfsbronnen (zoals een SQL-database) mogelijk niet toe via openbare eindpunten.

Azure Private Link biedt ondersteuning voor toegang tot een lijst met Azure-services via privé-eindpunten, maar hiervoor moet u deze privé-eindpuntrecords registreren in een bijbehorende privé-DNS-zone.

In dit artikel wordt beschreven hoe toepassingsteams Azure PaaS-services kunnen implementeren in hun abonnementen die alleen toegankelijk zijn via privé-eindpunten.

In dit artikel wordt ook beschreven hoe toepassingsteams ervoor kunnen zorgen dat services automatisch worden geïntegreerd met privé-DNS-zones. Ze doen de automatisering via Azure Privé-DNS, waardoor records handmatig moeten worden gemaakt of verwijderd in DNS.

Private Link- en DNS-integratie in hub- en spoke-netwerkarchitecturen

Privé-DNS zones worden doorgaans centraal gehost in hetzelfde Azure-abonnement waarin het hub-VNet wordt geïmplementeerd. Deze centrale hostingpraktijk wordt aangestuurd door cross-premises DNS-naamomzetting en andere behoeften voor centrale DNS-omzetting, zoals Active Directory. In de meeste gevallen hebben alleen netwerk- en identiteitsbeheerders machtigingen voor het beheren van DNS-records in de zones.

Toepassingsteams hebben machtigingen om Een Azure-resource te maken in hun eigen abonnement. Ze hebben geen machtigingen in het abonnement voor centrale netwerkconnectiviteit, waaronder het beheren van DNS-records in de privé-DNS-zones. Deze toegangsbeperking betekent dat ze niet de mogelijkheid hebben om de DNS-records te maken die zijn vereist bij het implementeren van Azure PaaS-services met privé-eindpunten.

In het volgende diagram ziet u een typische architectuur op hoog niveau voor bedrijfsomgevingen met centrale DNS-resolutie en waar naamomzetting voor Private Link-resources wordt uitgevoerd via Azure Privé-DNS:

Een diagram van een architectuur op hoog niveau met centrale DNS-resolutie en naamomzetting voor Private Link-resources.

Uit het vorige diagram is het belangrijk om te benadrukken dat:

On-premises DNS-servers hebben voorwaardelijke doorstuurservers geconfigureerd voor elke openbare DNS-zone van het privé-eindpunt, die verwijst naar de Privé-DNS Resolver die wordt gehost in het hub-VNet.
De Privé-DNS Resolver die in het hub-VNet wordt gehost, gebruikt de door Azure geleverde DNS (168.63.129.16) als doorstuurserver.
Het hub-VNet moet worden gekoppeld aan de Privé-DNS zonenamen voor Azure-services (zoals , zoals privatelink.blob.core.windows.netweergegeven in het diagram).
Alle Azure-VNets gebruiken Privé-DNS Resolver die wordt gehost in het hub-VNet
Aangezien de Privé-DNS Resolver niet gezaghebbend is voor de bedrijfsdomeinen van de klant, omdat het alleen een doorstuurserver (bijvoorbeeld Active Directory-domeinnamen) is, moet het uitgaande eindpunt doorstuurservers hebben naar de bedrijfsdomeinen van de klant, die verwijst naar de on-premises DNS-servers (172.16.1.10 en 172.16.1.11) of DNS-servers die zijn geïmplementeerd in Azure die gezaghebbend zijn voor dergelijke zones.

Notitie

U kunt een privé-DNS-resolver implementeren in uw virtuele hubnetwerk naast uw ExpressRoute-gateway, enzovoort. U moet er echter voor zorgen dat de omzetting van openbare FQDN's is toegestaan en antwoorden met een geldig antwoord via een regel voor dns-doorstuurregelset naar de doel-DNS-server. Omdat sommige Azure-services afhankelijk zijn van de mogelijkheid om openbare DNS-namen om te schakelen om te werken. Hier vindt u meer informatie

Hoewel in het vorige diagram één hub- en spoke-architectuur wordt weergegeven, moeten klanten mogelijk hun Azure-footprint uitbreiden naar meerdere regio's om te voldoen aan vereisten voor tolerantie, nabijheid of gegevenslocatie. Er zijn verschillende scenario's ontstaan waarin hetzelfde PaaS-exemplaar met Private Link-functionaliteit moet worden geopend via meerdere privé-eindpunten (PE's).

In het volgende diagram ziet u een typische architectuur op hoog niveau voor bedrijfsomgevingen met centrale DNS-resolutie die is geïmplementeerd in de hub (één per regio) waar naamomzetting voor Private Link-resources wordt uitgevoerd via Azure Privé-DNS.

Het is raadzaam om meerdere regionale privé-eindpunten te implementeren die zijn gekoppeld aan het PaaS-exemplaar, één in elke regio waar clients bestaan, Private Link per regio en Privé-DNS Zones inschakelen. Wanneer u met PaaS-services werkt met ingebouwde DR-mogelijkheden (geografisch redundante opslagaccounts, SQL DB-failovergroepen, enzovoort), zijn privé-eindpunten voor meerdere regio's verplicht.

Dit scenario vereist handmatig onderhoud/updates van de Private Link DNS-recordset in elke regio, omdat er momenteel geen geautomatiseerd levenscyclusbeheer voor deze is.

Voor andere gebruiksscenario's kan één globaal privé-eindpunt worden geïmplementeerd, waardoor het toegankelijk is voor alle clients door routering vanuit de relevante regio's toe te voegen aan het individuele privé-eindpunt in één regio.

Om omzetting mogelijk te maken, en daarom connectiviteit, van on-premises netwerken met de privatelink privé-DNS-zone en privé-eindpunten, moet de juiste DNS-configuratie (zoals voorwaardelijke doorstuurservers) worden ingericht in de DNS-infrastructuur.

Er zijn twee voorwaarden waar voor toepassingsteams om vereiste Azure PaaS-resources in hun abonnement te maken:

Het centrale netwerk- en/of centrale platformteam moet ervoor zorgen dat toepassingsteams alleen Azure PaaS-services kunnen implementeren en openen via privé-eindpunten.
Centrale netwerk- en/of centrale platformteams moeten ervoor zorgen dat ze bij het maken van privé-eindpunten de bijbehorende records instellen. Stel de bijbehorende records zo in dat ze automatisch worden gemaakt in de gecentraliseerde privé-DNS-zone die overeenkomt met de service die wordt gemaakt.
DNS-records moeten de levenscyclus van het privé-eindpunt volgen. Het wordt automatisch verwijderd wanneer het privé-eindpunt wordt verwijderd.

Notitie

Als FQDN's in netwerkregels op basis van DNS-omzetting nodig zijn om te worden gebruikt in azure Firewall- en firewallbeleid (met deze mogelijkheid kunt u uitgaand verkeer filteren met elk TCP/UDP-protocol, waaronder NTP, SSH, RDP en meer). U moet Azure Firewall DNS-proxy inschakelen voor het gebruik van FQDN's in uw netwerkregels. Deze spoke-VNets worden gedwongen hun DNS-instelling te wijzigen van aangepaste DNS-server in Azure Firewall DNS Proxy. Als u de DNS-instellingen van een spoke-VNet wijzigt, moet u alle VM's binnen dat VNet opnieuw opstarten.

In de volgende secties wordt beschreven hoe toepassingsteams deze voorwaarden inschakelen met behulp van Azure Policy. In het voorbeeld wordt Azure Storage gebruikt als de Azure-service die toepassingsteams moeten implementeren. Maar hetzelfde principe is van toepassing op de meeste Azure-services die Private Link ondersteunen.

Configuratie vereist door het platformteam

De configuratievereisten voor het platformteam omvatten het maken van de privé-DNS-zones, het instellen van beleidsdefinities, het implementeren van beleid en het instellen van de beleidstoewijzingen.

Privé-DNS-zones maken

Maak privé-DNS-zones in het centrale connectiviteitsabonnement voor de ondersteunde Private Link-services. Raadpleeg DNS-configuratie voor Azure-privé-eindpunt voor meer informatie.

In dit geval is opslagaccount met blob het voorbeeld. Het vertaalt zich in het maken van een privatelink.blob.core.windows.net privé-DNS-zone in het connectiviteitsabonnement.

Een schermopname van de privé-DNS-zone in het connectiviteitsabonnement.

Beleidsdefinities

Naast de privé-DNS-zones moet u ook een set aangepaste Azure Policy-definities maken. Deze definities dwingen het gebruik van privé-eindpunten af en automatiseren het maken van de DNS-record in de DNS-zone die u maakt:

Deny openbaar eindpunt voor PaaS-servicesbeleid.

Met dit beleid voorkomt u dat gebruikers Azure PaaS-services maken met openbare eindpunten en dat ze een foutbericht krijgen als ze het privé-eindpunt niet selecteren bij het maken van de resource.

De exacte beleidsregel kan verschillen tussen PaaS-services. Voor Azure Storage-accounts bekijkt u de eigenschap networkAcls.defaultAction waarmee wordt gedefinieerd of aanvragen van openbare netwerken zijn toegestaan of niet. In dit geval stelt u een voorwaarde in om het maken van het resourcetype Microsoft.Storage/storageAccounts te weigeren als de eigenschap networkAcls.defaultAction niet Denyis. De volgende beleidsdefinitie toont het gedrag:
```
{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction",
          "notEquals": "Deny"
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}
```
Deny de mogelijkheid om een privé-DNS-zone te maken met het privatelink voorvoegselbeleid.

Gebruik een gecentraliseerde DNS-architectuur met een voorwaardelijke doorstuurserver en privé-DNS-zones die worden gehost in de abonnementen die worden beheerd door het platformteam. Het is noodzakelijk om te voorkomen dat de eigenaren van toepassingsteams hun eigen privé-DNS-zones van Private Link maken en services koppelen aan hun abonnementen.

Zorg ervoor dat wanneer uw toepassingsteam een privé-eindpunt maakt, de optie Integrate with private DNS zone is ingesteld No op in Azure Portal.

Als u selecteert Yes, voorkomt Azure Policy dat u het privé-eindpunt maakt. In de beleidsdefinitie wordt de mogelijkheid geweigerd om het resourcetype Microsoft.Network/privateDnsZones te maken als de zone het privatelink voorvoegsel heeft. De volgende beleidsdefinitie toont het privatelink voorvoegsel:
```
{
  "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 beleid voor het automatisch maken van de vereiste DNS-record in de centrale privé-DNS-zone.

In de volgende beleidsvoorbeelden ziet u twee benaderingen voor het identificeren van de methoden die privateDNSZoneGroup zijn gemaakt op een privé-eindpunt.

Het eerste beleid is afhankelijk van de groupId tijd dat het tweede beleid zowel privateLinkServiceId als groupID. Gebruik het tweede beleid wanneer groupId er conflicten optreden (botsen) met een andere resource.

De SQL wordt bijvoorbeeld groupId gebruikt voor zowel Cosmos DB als Synapse Analytics. Als zowel resourcetypen worden geïmplementeerd als het eerste beleid is toegewezen om de privateDNSZoneGroup vermelding voor het privé-eindpunt te maken, wordt het gemaakt en toegewezen aan de onjuiste Privé-DNS zone, van Cosmos DB of Synapse Analytics. Vervolgens kan het schakelen tussen elk van de zones als gevolg van het conflict groupId dat het eerste beleid zoekt in de beleidsregel.

Zie de kolom Subresources in Wat is een privé-eindpunt? voor een lijst met Private Link-resourcesgroupId.

Tip

Ingebouwde Azure Policy-definities worden voortdurend toegevoegd, verwijderd en bijgewerkt. Het wordt ten zeerste aanbevolen om ingebouwde beleidsregels te gebruiken in plaats van uw eigen beleid te beheren (indien beschikbaar). Gebruik azPolicyAdvertizer om bestaande ingebouwde beleidsregels te vinden met de volgende naam 'xxx ... om privé-DNS-zones te gebruiken'. Daarnaast heeft Azure Landing Zones (ALZ) een beleidsinitiatief, Azure PaaS-services configureren voor het gebruik van privé-DNS-zones, die ingebouwde beleidsregels bevatten en periodiek worden bijgewerkt. Als er geen ingebouwd beleid beschikbaar is voor uw situatie, kunt u overwegen om een probleem te maken op de azure-policy feedbacksite van Azure Governance · Community die het proces Nieuwe ingebouwde beleidsvoorstellen volgt op de GitHub-opslagplaats van Azure Policy.

First `DeployIfNotExists` Policy - Alleen overeenkomend op `groupId`

Dit beleid wordt geactiveerd als u een privé-eindpuntresource maakt met een servicespecifiek groupId. Dit groupId is de id van de groep die is verkregen van de externe resource (service) waarmee dit privé-eindpunt verbinding moet maken. Vervolgens wordt een implementatie van een privateDNSZoneGroup binnen het privé-eindpunt geactiveerd, waarmee het privé-eindpunt wordt gekoppeld aan de privé-DNS-zone. In het voorbeeld is blobhet groupId voor Azure Storage-blobs. Zie de DNS-configuratie van azure-privé-eindpunten onder de kolom Subresource voor meer informatie over de groupId dns-configuratie van azure-privé-eindpunten. Wanneer het beleid het groupId in het privé-eindpunt vindt, wordt er een privateDNSZoneGroup binnen het privé-eindpunt geïmplementeerd en wordt het gekoppeld aan de resource-id van de privé-DNS-zone die is opgegeven als de parameter. In het voorbeeld is de resource-id van de privé-DNS-zone:

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

In het volgende codevoorbeeld ziet u de beleidsdefinitie:

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

Second `DeployIfNotExists` Policy - Matching on `groupId` & `privateLinkServiceId`

Dit beleid wordt geactiveerd als u een privé-eindpuntresource maakt met een servicespecifiek groupId en privateLinkServiceId. Dit groupId is de id van de groep die is verkregen van de externe resource (service) waarmee dit privé-eindpunt verbinding moet maken. Dit privateLinkServiceId privé-eindpunt moet verbinding maken met de resource-id van de externe resource (service). Activeer vervolgens een implementatie van een privateDNSZoneGroup binnen het privé-eindpunt, dat het privé-eindpunt koppelt aan de privé-DNS-zone.

In het voorbeeld is het groupId voor Azure Cosmos DB (SQL) en de privateLinkServiceId must bevattenMicrosoft.DocumentDb/databaseAccounts.SQL Zie de DNS-configuratie van azure-privé-eindpunten onder de kolom Subresource voor meer informatie over en groupId privateLinkServiceId voor andere Azure-services. Wanneer het beleid wordt gevonden groupId en privateLinkServiceId in het privé-eindpunt, wordt een privateDNSZoneGroup binnen het privé-eindpunt geïmplementeerd. En deze is gekoppeld aan de resource-id van de privé-DNS-zone die is opgegeven als de parameter. De volgende beleidsdefinitie toont de resource-id van de privé-DNS-zone:

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

In het volgende codevoorbeeld ziet u de beleidsdefinitie:

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

Beleidstoewijzingen

Nadat beleidsdefinities zijn geïmplementeerd, wijst u het beleid toe aan het gewenste bereik in uw beheergroephiërarchie. Zorg ervoor dat de beleidstoewijzingen zijn gericht op de Azure-abonnementen die de toepassingsteams gebruiken om PaaS-services te implementeren met uitsluitend toegang tot privé-eindpunten.

Belangrijk

Vergeet niet om de rol roleDefinition toe te wijzen die in het beleid is gedefinieerd, maar vergeet niet om de rol Privé-DNS zonebijdrager toe te wijzen in het abonnement en de resourcegroep waar de privé-DNS-zones worden gehost op de beheerde identiteit die is gemaakt door de DeployIfNotExists beleidstoewijzing die verantwoordelijk is voor het maken en beheren van de DNS-record voor het privé-eindpunt in de privé-DNS-zone. Dit komt doordat het privé-eindpunt zich in het Azure-abonnement van de eigenaar van de toepassing bevindt, terwijl de privé-DNS-zone zich in een ander abonnement bevindt (zoals een centraal connectiviteitsabonnement).

Nadat het platformteam de configuratie heeft voltooid:

De Azure-abonnementen van de toepassingenteams zijn klaar voor het team om vervolgens Azure PaaS-services te maken met uitsluitend toegang tot privé-eindpunten.
Het team moet ervoor zorgen dat de DNS-records voor privé-eindpunten automatisch worden geregistreerd (en verwijderd zodra een privé-eindpunt is verwijderd) uit de bijbehorende privé-DNS-zones.

Ervaring van toepassingseigenaar

Nadat het platformteam de onderdelen van de platforminfrastructuur (privé-DNS-zones en -beleid) heeft geïmplementeerd, heeft de eigenaar van de toepassing de volgende ervaring wanneer ze proberen een Azure PaaS-service te implementeren in het Azure-abonnement. Deze ervaring is hetzelfde, ongeacht of ze hun activiteiten uitvoeren via Azure Portal of andere clients, zoals PowerShell of CLI, omdat Het Azure-beleid hun abonnementen bepaalt.

Maak een opslagaccount via Azure Portal. Kies op het tabblad Basisbeginselen de gewenste instellingen, geef een naam op voor uw opslagaccount en selecteer Volgende.
Selecteer Privé-eindpunt op het tabblad Netwerken. Als u een andere optie dan een privé-eindpunt selecteert, kunt u in Azure Portal het opslagaccount niet maken in de sectie Beoordelen en maken van de implementatiewizard. Het beleid voorkomt dat u deze service maakt als het openbare eindpunt is ingeschakeld.
Het is nu mogelijk om het privé-eindpunt te maken of nadat u het opslagaccount hebt gemaakt. In dit voorbeeld ziet u hoe u het privé-eindpunt maakt nadat het opslagaccount is gemaakt. Selecteer Beoordelen en maken om de stap te voltooien.
Nadat u het opslagaccount hebt gemaakt, maakt u een privé-eindpunt via Azure Portal.
Zoek in de sectie Resource het opslagaccount dat u in de vorige stap hebt gemaakt. Selecteer onder doelsubresource blob en selecteer vervolgens Volgende.
Controleer in de sectie Configuratie , nadat u uw VNet en subnet hebt geselecteerd, of Integreren met privé-DNS-zone is ingesteld op Nee. Anders voorkomt Azure Portal dat u het privé-eindpunt maakt. Met Azure Policy kunt u geen privé-DNS-zone maken met het privatelink voorvoegsel.
Selecteer Beoordelen en maken en selecteer vervolgens Maken om het privé-eindpunt te implementeren.
Na enkele minuten wordt het DeployIfNotExists beleid geactiveerd. De volgende dnsZoneGroup implementatie voegt vervolgens de vereiste DNS-records voor het privé-eindpunt toe in de centraal beheerde DNS-zone.
Nadat u het privé-eindpunt hebt gemaakt, selecteert u het en controleert u de FQDN en het privé-IP-adres:
Controleer het activiteitenlogboek voor de resourcegroep waar het privé-eindpunt is gemaakt. U kunt ook het activiteitenlogboek van het privé-eindpunt zelf controleren. U ziet dat na een paar minuten een DeployIfNotExist beleidsactie wordt uitgevoerd en dat de DNS-zonegroep op het privé-eindpunt wordt geconfigureerd:
Als het centrale netwerkteam naar de privatelink.blob.core.windows.net privé-DNS-zone gaat, bevestigen ze dat de DNS-record er is voor het privé-eindpunt dat u hebt gemaakt, en dat zowel de naam als het IP-adres overeenkomen met de waarden binnen het privé-eindpunt.

Op dit moment kunnen toepassingsteams het opslagaccount gebruiken via een privé-eindpunt vanuit elk VNet in de hub- en spoke-netwerkomgeving en vanuit on-premises. De DNS-record is automatisch vastgelegd in de privé-DNS-zone.

Als een eigenaar van een toepassing het privé-eindpunt verwijdert, worden de bijbehorende records in de privé-DNS-zone automatisch verwijderd.

Volgende stappen

Controleer DNS voor on-premises en Azure-resources. Bekijk het plan voor externe toegang tot virtuele machines.

Belangrijk

In dit artikel worden DNS- en Private Link-integratie op schaal beschreven met behulp van DINE-beleidsregels (DeployIfNotExists) die zijn toegewezen aan de beheergroep. Dit betekent dat het niet nodig is om de DNS-integratie in code af te handelen bij het maken van privé-eindpunten met deze benadering, omdat deze wordt verwerkt door het beleid. Het is ook onwaarschijnlijk dat de toepassingsteams RBAC-toegang hebben tot de gecentraliseerde Privé-DNS Zones.

Hieronder ziet u nuttige koppelingen om te controleren bij het maken van een privé-eindpunt met Bicep en HashiCorp Terraform.

Voor het maken van een privé-eindpunt met Infrastructuur als code:

Quickstart: Een privé-eindpunt maken met Bicep.

Maak een privé-eindpunt met behulp van HashiCorp Terraform azurerm_private_endpoint in Terrafrom Registry.

U kunt nog steeds privé-eindpunten maken in uw hulpprogramma's voor infrastructuur als code, maar als u de DINE-beleidsbenadering gebruikt, zoals beschreven in dit artikel, moet u de DNS-integratie uit uw code laten staan en de DINE-beleidsregels met de vereiste RBAC laten afhandelen aan de Privé-DNS Zones in plaats daarvan.

Delen via

Private Link en DNS-integratie op schaal

Inleiding

Private Link- en DNS-integratie in hub- en spoke-netwerkarchitecturen