Private Link och DNS-integrering i stor skala
Den här artikeln beskriver hur du integrerar Azure Private Link för PaaS-tjänster med Azure Private DNS-zoner i nav- och ekernätverksarkitekturer.
Introduktion
Många kunder skapar sin nätverksinfrastruktur i Azure med hjälp av nav- och ekernätverksarkitekturen, där:
- Nätverksdelade tjänster (till exempel virtuella nätverksinstallationer, ExpressRoute/VPN-gatewayer eller DNS-servrar) distribueras i det virtuella hubbnätverket (VNet).
- Virtuella ekernätverk använder delade tjänster via VNet-peering.
I nav- och ekernätverksarkitekturer tillhandahålls programägare vanligtvis en Azure-prenumeration, som innehåller ett virtuellt nätverk (en eker) som är anslutet till det virtuella hubbnätverket . I den här arkitekturen kan de distribuera sina virtuella datorer och ha privat anslutning till andra virtuella nätverk eller till lokala nätverk via ExpressRoute eller VPN.
En virtuell nätverksinstallation (NVA), till exempel Azure Firewall, tillhandahåller internetutgående anslutning. Dessutom används den enheten, till exempel med Azure Firewall DNS-proxy eller en annan tjänst i eller intill hubben, vanligtvis för att anpassa DNS-vidarebefordran.
Många programteam skapar sina lösningar med hjälp av en kombination av Azure IaaS- och PaaS-resurser. Vissa Azure PaaS-tjänster (till exempel SQL Managed Instance) kan distribueras i kundens virtuella nätverk. Därför förblir trafiken privat i Azure-nätverket och kan dirigeras helt lokalt.
Men vissa Azure PaaS-tjänster (till exempel Azure Storage eller Azure Cosmos DB) kan inte distribueras i en kunds virtuella nätverk och är tillgängliga via deras offentliga slutpunkt. I vissa fall orsakar den här konfigurationen en konkurrens med en kunds säkerhetsprinciper. Företagstrafik kanske inte tillåter distribution eller åtkomst av företagsresurser (till exempel en SQL-databas) via offentliga slutpunkter.
Azure Private Link stöder åtkomst till en lista över Azure-tjänster via privata slutpunkter, men du måste registrera dessa privata slutpunktsposter i en motsvarande privat DNS-zon.
Den här artikeln beskriver hur programteam kan distribuera Azure PaaS-tjänster i sina prenumerationer som endast är tillgängliga via privata slutpunkter.
Den här artikeln beskriver också hur programteam kan se till att tjänsterna integreras automatiskt med privata DNS-zoner. De utför automatiseringen via Azure Private DNS, vilket tar bort behovet av att manuellt skapa eller ta bort poster i DNS.
Private Link- och DNS-integrering i nav- och ekernätverksarkitekturer
Privata DNS-zoner finns vanligtvis centralt i samma Azure-prenumeration där det virtuella hubbnätverket distribueras. Den här centrala värdpraxis drivs av dns-namnmatchning mellan platser och andra behov av central DNS-matchning, till exempel Active Directory. I de flesta fall har endast nätverks- och identitetsadministratörer behörighet att hantera DNS-poster i zonerna.
Programteam har behörighet att skapa Azure-resurser i sin egen prenumeration. De har inga behörigheter i den centrala nätverksanslutningsprenumerationen, vilket inkluderar hantering av DNS-poster i de privata DNS-zonerna. Den här åtkomstbegränsningen innebär att de inte har möjlighet att skapa de DNS-poster som krävs när de distribuerar Azure PaaS-tjänster med privata slutpunkter.
Följande diagram visar en typisk arkitektur på hög nivå för företagsmiljöer med central DNS-matchning och där namnmatchning för Private Link-resurser görs via Azure Private DNS:
Från föregående diagram är det viktigt att markera följande:
- Lokala DNS-servrar har villkorliga vidarebefordrare konfigurerade för varje offentlig DNS-zon för privata slutpunkter, som pekar på den privata DNS Resolver som finns i det virtuella hubbnätverket.
- Den privata DNS-matcharen som finns i det virtuella hubbnätverket använder Den Azure-tillhandahållna DNS(168.63.129.16) som vidarebefordrare.
- Det virtuella hubbnätverket måste vara länkat till de privata DNS-zonnamnen för Azure-tjänster (till exempel
privatelink.blob.core.windows.net, som visas i diagrammet). - Alla virtuella Azure-nätverk använder privat DNS Resolver som finns i det virtuella hubbnätverket
- Eftersom den privata DNS-matcharen inte är auktoritativ för kundens företagsdomäner, eftersom det bara är en vidarebefordrare (till exempel Active Directory-domännamn) bör den ha utgående slutpunktsvidare till kundens företagsdomäner och peka på de lokala DNS-servrarna (172.16.1.10 och 172.16.1.11) eller DNS-servrar som distribueras i Azure som är auktoritativa för sådana zoner.
Kommentar
Du kan distribuera en privat DNS-matchare i ditt virtuella hubbnätverk tillsammans med din ExpressRoute-gateway osv. Du måste dock se till att lösning av offentliga FQDN tillåts och svarar med ett giltigt svar via en REGEL för DNS-vidarebefordran regeluppsättning till mål-DNS-servern. Eftersom vissa Azure-tjänster förlitar sig på förlitar sig på möjligheten att matcha offentliga DNS-namn för att fungera. Mer information finns här
Medan det föregående diagrammet visar en enda hubb- och ekerarkitektur kan kunderna behöva utöka sitt Azure-fotavtryck i flera regioner för att hantera kraven på återhämtning, närhet eller datahemvist, men flera scenarier har uppstått där samma Private-Link-aktiverade PaaS-instans måste nås via flera privata slutpunkter (PE).
Följande diagram visar en typisk arkitektur på hög nivå för företagsmiljöer med central DNS-matchning distribuerad i hubben (en per region) där namnmatchning för Private Link-resurser görs via Azure Private DNS.
Vi rekommenderar att du distribuerar flera regionala privata slutpunkter som är associerade med PaaS-instansen, en i varje region där klienter finns, aktivera private link per region och privata DNS-zoner. När du arbetar med PaaS-tjänster med inbyggda DR-funktioner (geo-redundanta lagringskonton, SQL DB-redundansgrupper osv.) är privata slutpunkter i flera regioner obligatoriska.
Det här scenariot kräver manuellt underhåll/uppdateringar av DNS-posten Private Link som angetts i varje region eftersom det för närvarande inte finns någon automatiserad livscykelhantering för dessa.
För andra användningsfall kan en enda global privat slutpunkt distribueras, vilket gör den tillgänglig för alla klienter genom att lägga till routning från relevanta regioner till den enskilda privata slutpunkten i en enda region.
För att aktivera matchning, och därmed anslutning, från lokala nätverk till den privatelink privata DNS-zonen och privata slutpunkter, måste lämplig DNS-konfiguration (till exempel villkorliga vidarebefordrare) etableras i DNS-infrastrukturen.
Det finns två villkor som måste vara uppfyllda för att programteamen ska kunna skapa nödvändiga Azure PaaS-resurser i sin prenumeration:
- Centrala nätverk och/eller centrala plattformsteam måste se till att programteam endast kan distribuera och komma åt Azure PaaS-tjänster via privata slutpunkter.
- Centrala nätverks- och/eller centrala plattformsteam måste se till att när de skapar privata slutpunkter konfigurerar de hur motsvarande poster ska hanteras. Konfigurera motsvarande poster så att de skapas automatiskt i den centraliserade privata DNS-zonen som matchar den tjänst som skapas.
- DNS-poster måste följa livscykeln för den privata slutpunkten, eftersom den tas bort automatiskt när den privata slutpunkten tas bort.
Kommentar
Om FQDN:er i nätverksregler baserade på DNS-matchning behövs för att användas i Azure Firewall and Firewall-principen (Med den här funktionen kan du filtrera utgående trafik med TCP/UDP-protokoll – inklusive NTP, SSH, RDP med mera). Du måste aktivera Azure Firewall DNS-proxy för att använda FQDN i dina nätverksregler. Sedan tvingas de virtuella ekernätverken att ändra sin DNS-inställning från en anpassad DNS-server till Azure Firewall DNS-proxy. För att ändra DNS-inställningarna för ett virtuellt ekernätverk krävs omstart av alla virtuella datorer i det virtuella nätverket.
I följande avsnitt beskrivs hur programteam aktiverar dessa villkor med hjälp av Azure Policy. I exemplet används Azure Storage som den Azure-tjänst som programteamen behöver distribuera. Men samma princip gäller för de flesta Azure-tjänster som stöder Private Link.
Konfiguration som krävs av plattformsteamet
Konfigurationskraven för plattformsteamet omfattar att skapa privata DNS-zoner, konfigurera principdefinitioner, distribuera principer och konfigurera principtilldelningarna.
Skapa privata DNS-zoner
Skapa privata DNS-zoner i den centrala anslutningsprenumerationen för private link-tjänster som stöds. Mer information finns i DNS-konfiguration för privat slutpunkt i Azure.
I det här fallet är Lagringskonto med blob exemplet. Det innebär att skapa en privatelink.blob.core.windows.net privat DNS-zon i anslutningsprenumerationen.
Principdefinitioner
Förutom de privata DNS-zonerna måste du också skapa en uppsättning anpassade Azure Policy-definitioner. Dessa definitioner framtvingar användningen av privata slutpunkter och automatiserar skapandet av DNS-posten i DEN DNS-zon som du skapar:
Denyoffentlig slutpunkt för PaaS-tjänstprincip.Den här principen hindrar användare från att skapa Azure PaaS-tjänster med offentliga slutpunkter och ger dem ett felmeddelande om de inte väljer den privata slutpunkten när de skapar resursen.
Den exakta principregeln kan skilja sig mellan PaaS-tjänster. För Azure Storage-konton tittar du på egenskapen networkAcls.defaultAction som definierar om begäranden från offentliga nätverk tillåts eller inte. I det här fallet anger du ett villkor för att neka att skapa resurstypen Microsoft.Storage/storageAccounts om egenskapsnätverketAcls.defaultAction inte
Denyär . Följande principdefinition visar beteendet:{ "mode": "All", "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction", "notEquals": "Deny" } ] }, "then": { "effect": "Deny" } } }Denymöjligheten att skapa en privat DNS-zon med prefixprincipenprivatelink.Använd en centraliserad DNS-arkitektur med en villkorlig vidarebefordrare och privata DNS-zoner i prenumerationerna som hanteras av plattformsteamet. Det är nödvändigt att förhindra att programteamens ägare skapar egna privata DNS-zoner för Private Link och länkar tjänster till sina prenumerationer.
Se till att när programteamet skapar en privat slutpunkt är alternativet
Integrate with private DNS zoneinställtNopå i Azure-portalen.
Om du väljer
Yeshindrar Azure Policy dig från att skapa den privata slutpunkten. I principdefinitionen nekas möjligheten att skapa resurstypen Microsoft.Network/privateDnsZones om zonen har prefixetprivatelink. Följande principdefinition visar prefixetprivatelink:{ "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" } } }DeployIfNotExistsprincip för att automatiskt skapa den dns-post som krävs i den centrala privata DNS-zonen.Följande principexempel visar två metoder för att identifiera vilka som
privateDNSZoneGroupskapas på en privat slutpunkt.Den första principen förlitar sig på medan
groupIdden andra principen använder bådeprivateLinkServiceIdochgroupID. Använd den andra principen närgroupIdkommer att kollidera (kollidera) med en annan resurs.Sql används till exempel
groupIdför både Cosmos DB och Synapse Analytics. Om båda resurstyperna distribueras och den första principen har tilldelats för att skapaprivateDNSZoneGroupposten för den privata slutpunkten skapas och mappas den till den felaktiga privata DNS-zonen, antingen för Cosmos DB eller Synapse Analytics. Den kan sedan växla mellan var och en av zonerna på grund av den konfliktgroupIdsom den första principen söker efter i sin principregel.En lista över private-link-resurser
groupIdfinns i kolumnen underresurser i Vad är en privat slutpunkt?.
Dricks
Inbyggda Azure Policy-definitioner läggs ständigt till, tas bort och uppdateras. Vi rekommenderar starkt att du använder inbyggda principer jämfört med att hantera dina egna principer (där det är tillgängligt). Använd AzPolicyAdvertizer för att hitta befintliga inbyggda principer som har följande namn: "xxx ... för att använda privata DNS-zoner". Dessutom har Azure Landing Zones (ALZ) ett principinitiativ, Konfigurera Azure PaaS-tjänster för att använda privata DNS-zoner, som innehåller inbyggda principer och uppdateras regelbundet. Om en inbyggd princip inte är tillgänglig för din situation kan du överväga att skapa ett problem på feedbackwebbplatsen azure-policy Azure Governance · Communityn följer processen Nya inbyggda policyförslag på GitHub-lagringsplatsen för Azure Policy.
Första DeployIfNotExists principen – endast matchning på groupId
Den här principen utlöses om du skapar en privat slutpunktsresurs med en tjänstspecifik groupId. groupId är ID:t för gruppen som hämtats från fjärrresursen (tjänsten) som den här privata slutpunkten ska ansluta till. Sedan utlöses en distribution av en privateDNSZoneGroup inom den privata slutpunkten, som associerar den privata slutpunkten med den privata DNS-zonen. I exemplet groupId är blobför Azure Storage-blobar . Mer information om för andra Azure-tjänster finns i DNS-konfigurationen groupIdför azure private endpoint under kolumnen Subresource. När principen hittar groupId i den privata slutpunkten distribueras en privateDNSZoneGroup i den privata slutpunkten och länkar den till resurs-ID:t för den privata DNS-zonen som anges som parameter. I exemplet är resurs-ID:t för den privata DNS-zonen:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net
Följande kodexempel visar principdefinitionen:
{
"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 – Matchning på groupId & privateLinkServiceId
Den här principen utlöses om du skapar en privat slutpunktsresurs med en tjänstspecifik groupId och privateLinkServiceId. groupId är ID:t för gruppen som hämtats från fjärrresursen (tjänsten) som den här privata slutpunkten ska ansluta till. privateLinkServiceId är resurs-ID för fjärrresursen (tjänsten) som den privata slutpunkten ska ansluta till. Utlös sedan en distribution av en privateDNSZoneGroup inom den privata slutpunkten, som associerar den privata slutpunkten med den privata DNS-zonen.
I exemplet groupId är för Azure Cosmos DB (SQL) och måste innehålla privateLinkServiceId Microsoft.DocumentDb/databaseAccounts.SQL Mer information om och privateLinkServiceId för andra Azure-tjänster finns i DNS-konfigurationengroupId för azure private endpoint under kolumnen Subresource. När principen hittar groupId och privateLinkServiceId i den privata slutpunkten distribueras en privateDNSZoneGroup i den privata slutpunkten. Och den är länkad till resurs-ID:t för den privata DNS-zonen som anges som parameter. Följande principdefinition visar resurs-ID:t för den privata DNS-zonen:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com
Följande kodexempel visar principdefinitionen:
{
"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"
}
}
}
Principtilldelningar
När principdefinitioner har distribuerats tilldelar du principerna i önskat omfång i hanteringsgruppens hierarki. Se till att principtilldelningarna riktar in sig på de Azure-prenumerationer som programteamen använder för att distribuera PaaS-tjänster med privat slutpunktsåtkomst exklusivt.
Viktigt!
Förutom att tilldela rollenDefinition som definierats i principen, kom ihåg att tilldela rollen Privat DNS-zondeltagare i prenumerationen och resursgruppen där de privata DNS-zonerna finns till den hanterade identiteten som skapas av principtilldelningen DeployIfNotExists som ansvarar för att skapa och hantera DNS-posten för den privata slutpunkten i den privata DNS-zonen. Det beror på att den privata slutpunkten finns i azure-prenumerationen för programägare, medan den privata DNS-zonen finns i en annan prenumeration (till exempel en central anslutningsprenumeration).
När plattformsteamet har slutfört konfigurationen:
- Programteamens Azure-prenumerationer är redo för teamet att sedan skapa Azure PaaS-tjänster med privat slutpunktsåtkomst exklusivt.
- Teamet måste se till att DNS-posterna för privata slutpunkter registreras automatiskt (och tas bort när en privat slutpunkt tas bort) från motsvarande privata DNS-zoner.
Programägarens upplevelse
När plattformsteamet har distribuerat plattformsinfrastrukturkomponenterna (privata DNS-zoner och principer) har programägaren följande upplevelse när de försöker distribuera en Azure PaaS-tjänst till Azure-prenumerationen. Den här upplevelsen är densamma oavsett om de utför sina aktiviteter via Azure-portalen eller andra klienter, till exempel PowerShell eller CLI, eftersom Azure-principer styr deras prenumerationer.
Skapa ett lagringskonto via Azure-portalen. På fliken Grundläggande inställningar väljer du önskade inställningar, anger ett namn för ditt lagringskonto och väljer Nästa.
På fliken Nätverk väljer du Privat slutpunkt. Om du väljer ett annat alternativ än Privat slutpunkt kan du inte skapa lagringskontot i avsnittet Granska + skapa i distributionsguiden på Azure-portalen. Principen hindrar dig från att skapa den här tjänsten om den offentliga slutpunkten är aktiverad.
Det går att skapa den privata slutpunkten nu eller efter att du har skapat lagringskontot. Det här exemplet visar hur du skapar den privata slutpunkten när lagringskontot har skapats. Välj Granska + skapa för att slutföra steget.
När du har skapat lagringskontot skapar du en privat slutpunkt via Azure-portalen.
I avsnittet Resurs letar du reda på lagringskontot som du skapade i föregående steg. Under målunderresurs väljer du Blob och sedan Nästa.
När du har valt ditt virtuella nätverk och undernät i avsnittet Konfiguration ska du se till att Integrera med privat DNS-zon har angetts till Nej. Annars hindrar Azure-portalen dig från att skapa den privata slutpunkten. Med Azure Policy kan du inte skapa en privat DNS-zon med prefixet
privatelink.
Välj Granska + skapa och välj sedan Skapa för att distribuera den privata slutpunkten.
Efter några minuter
DeployIfNotExistsutlöses principen. Den efterföljandednsZoneGroupdistributionen lägger sedan till nödvändiga DNS-poster för den privata slutpunkten i den centralt hanterade DNS-zonen.När du har skapat den privata slutpunkten väljer du den och granskar dess fullständiga domännamn och privata IP-adress:
Kontrollera aktivitetsloggen för resursgruppen där den privata slutpunkten skapades. Eller så kan du kontrollera aktivitetsloggen för själva den privata slutpunkten. Du kommer att märka att efter några minuter körs en
DeployIfNotExistprincipåtgärd och som konfigurerar DNS-zongruppen på den privata slutpunkten:
Om det centrala nätverksteamet går till den
privatelink.blob.core.windows.netprivata DNS-zonen bekräftar de att DNS-posten finns där för den privata slutpunkten som du skapade och att både namnet och IP-adressen matchar värdena i den privata slutpunkten.
Nu kan programteam använda lagringskontot via en privat slutpunkt från valfritt virtuellt nätverk i nav- och ekernätverksmiljön och lokalt. DNS-posten har registrerats automatiskt i den privata DNS-zonen.
Om en programägare tar bort den privata slutpunkten tas motsvarande poster i den privata DNS-zonen bort automatiskt.
Nästa steg
Granska DNS för lokala resurser och Azure-resurser. Granska Planera för fjärråtkomst till virtuell dator.
Viktigt!
Den här artikeln beskriver DNS- och Private Link-integrering i stor skala med hjälp av DINE-principer (DeployIfNotExists) som tilldelats hanteringsgruppen. Det innebär att du inte behöver hantera DNS-integreringen i koden när du skapar privata slutpunkter med den här metoden, eftersom den hanteras av principerna. Det är också osannolikt att programteamen har RBAC-åtkomst till de centraliserade privata DNS-zonerna.
Nedan visas användbara länkar att granska när du skapar en privat slutpunkt med Bicep och HashiCorp Terraform.
För att skapa privata slutpunkter med Infrastruktur som kod:
Skapa en privat slutpunkt med HashiCorp Terraform azurerm_private_endpoint i Terrafrom Registry.
Du kan fortfarande skapa privata slutpunkter i verktygen Infrastruktur som kod, men om du använder DINE-principmetoden enligt beskrivningen i den här artikeln bör du lämna DNS-integreringssidan borta från koden och låta DINE-principerna som har nödvändig RBAC till de privata DNS-zonerna hantera detta i stället.