Integrace služby Private Link a DNS ve velkém měřítku
Tento článek popisuje, jak integrovat službu Azure Private Link pro služby PaaS se zónami Azure Privátní DNS v hvězdicové síťové architektuře.
Úvod
Mnoho zákazníků sestavuje svou síťovou infrastrukturu v Azure pomocí hvězdicové síťové architektury, kde:
- Sdílené síťové služby (například síťová virtuální zařízení, brány ExpressRoute nebo brány VPN nebo servery DNS) se nasazují v centrální virtuální síti (VNet).
- Paprskové virtuální sítě využívají sdílené služby prostřednictvím partnerského vztahu virtuálních sítí.
V hvězdicových síťových architekturách se vlastníci aplikací obvykle poskytují s předplatným Azure, které zahrnuje virtuální síť (paprsk) připojenou k virtuální síti centra . V této architektuře mohou nasadit své virtuální počítače a mít privátní připojení k jiným virtuálním sítím nebo k místním sítím prostřednictvím ExpressRoute nebo VPN.
Virtuální zařízení centrální sítě, jako je Azure Firewall, poskytuje odchozí připojení k internetu. Kromě toho se toto zařízení, například s proxy serverem DNS služby Azure Firewall, nebo jinou službou v centru nebo vedle tohoto centra, obvykle používá k přizpůsobení předávání DNS.
Mnoho aplikačních týmů vytváří svá řešení pomocí kombinace prostředků Azure IaaS a PaaS. Některé služby Azure PaaS (například SQL Managed Instance) je možné nasadit v zákaznických virtuálních sítích. V důsledku toho provoz zůstává privátní v rámci sítě Azure a je plně směrovatelný z místního prostředí.
Některé služby Azure PaaS (například Azure Storage nebo Azure Cosmos DB) se ale nedají nasadit ve virtuálních sítích zákazníka a jsou přístupné přes svůj veřejný koncový bod. V některých případech tato konfigurace způsobuje kolize se zásadami zabezpečení zákazníka. Podnikový provoz nemusí povolit nasazení nebo přístup k podnikovým prostředkům (jako je databáze SQL) přes veřejné koncové body.
Azure Private Link podporuje přístup k seznamu služeb Azure přes privátní koncové body, ale vyžaduje, abyste tyto záznamy privátních koncových bodů zaregistrovali v odpovídající privátní zóně DNS.
Tento článek popisuje, jak můžou aplikační týmy nasazovat služby Azure PaaS ve svých předplatných, které jsou přístupné jenom přes privátní koncové body.
Tento článek také popisuje, jak můžou aplikační týmy zajistit automatickou integraci služeb s privátními zónami DNS. Dělají automatizaci prostřednictvím Azure Privátní DNS, což eliminuje potřebu ručního vytváření nebo odstraňování záznamů v DNS.
Integrace služby Private Link a DNS v architekturách hvězdicové sítě
Privátní DNS zóny se obvykle hostují centrálně ve stejném předplatném Azure, ve kterém se nasazuje virtuální síť centra. Tento postup centrálního hostování je řízený překladem názvů DNS mezi místními místy a dalšími potřebami centrálního překladu DNS, jako je Active Directory. Ve většině případů mají oprávnění ke správě záznamů DNS v zónách jenom správci sítí a identit.
Aplikační týmy mají oprávnění k vytvoření prostředku Azure ve vlastním předplatném. Nemají žádná oprávnění v předplatném centrálního síťového připojení, která zahrnuje správu záznamů DNS v privátních zónách DNS. Toto omezení přístupu znamená, že nemají možnost vytvářet záznamy DNS vyžadované při nasazování služeb Azure PaaS s privátními koncovými body.
Následující diagram znázorňuje typickou architekturu vysoké úrovně pro podniková prostředí s centrálním překladem DNS a překlad názvů pro prostředky Private Linku se provádí přes Azure Privátní DNS:
Z předchozího diagramu je důležité zdůraznit, že:
- Místní servery DNS mají nakonfigurované podmíněné služby předávání pro každou veřejnou zónu DNS privátního koncového bodu, které odkazují na Privátní DNS Resolver hostovaný ve virtuální síti centra.
- Překladač Privátní DNS hostovaný ve virtuální síti centra používá jako předávací nástroj DNS poskytovaný Azure (168.63.129.16).
- Virtuální síť centra musí být propojená s názvy zón Privátní DNS pro služby Azure (například
privatelink.blob.core.windows.net, jak je znázorněno v diagramu). - Všechny virtuální sítě Azure používají Privátní DNS Resolver hostovaný ve virtuální síti centra.
- Protože Privátní DNS Resolver není autoritativní pro firemní domény zákazníka, protože se jedná pouze o předávací modul (například názvy domén služby Active Directory), měl by obsahovat odchozí koncové body předávací servery do firemních domén zákazníka, které odkazují na místní servery DNS (172.16.10 a 172.16.16.11) nebo servery DNS nasazené v Azure, které jsou pro takové zóny autoritativní.
Poznámka:
Privátní překladač DNS můžete nasadit ve virtuální síti centra společně s bránou ExpressRoute atd. Musíte ale zajistit, aby bylo povolené překlad veřejných plně kvalifikovaných názvů domén a odpovědi s platnou odpovědí prostřednictvím pravidla sady pravidel předávání DNS cílovému serveru DNS. Vzhledem k tomu, že některé služby Azure spoléhají na schopnost překládat veřejné názvy DNS tak, aby fungovaly. Další informace najdete tady.
I když předchozí diagram znázorňuje jednu hvězdicovou architekturu, zákazníci možná budou muset rozšířit využití Azure napříč několika oblastmi, aby vyřešili požadavky na odolnost, blízkost nebo rezidenci dat, objevilo se několik scénářů, ve kterých musí být stejná instance PaaS s podporou privátního propojení přístupná prostřednictvím několika privátních koncových bodů (PE).
Následující diagram znázorňuje typickou architekturu vysoké úrovně pro podniková prostředí s centrálním překladem DNS nasazeným v centru (jedna pro oblast), kde se překlad názvů pro prostředky Private Link provádí přes Azure Privátní DNS.
Doporučujeme nasadit několik regionálních privátních koncových bodů přidružených k instanci PaaS, jednu v každé oblasti, kde existují klienti, povolit službu Private Link pro každou oblast a Privátní DNS zón. Při práci se službami PaaS s integrovanými funkcemi zotavení po havárii (geograficky redundantní účty úložiště, skupiny převzetí služeb při selhání služby SQL Db atd.) je povinné více privátních koncových bodů oblasti.
Tento scénář vyžaduje ruční údržbu nebo aktualizace sady záznamů DNS služby Private Link v každé oblasti, protože pro tyto účely aktuálně neexistuje žádná automatizovaná správa životního cyklu.
V případě jiných případů použití je možné nasadit jeden globální privátní koncový bod, který umožňuje přístup všem klientům přidáním směrování z příslušných oblastí do jednoho privátního koncového bodu v jedné oblasti.
Aby bylo možné povolit překlad, a proto připojení z místních sítí do privatelink privátní zóny DNS a privátních koncových bodů, je potřeba zřídit příslušnou konfiguraci DNS (například podmíněné předávací servery) v infrastruktuře DNS.
Existují dvě podmínky, které musí být splněné, aby týmy aplikací vytvořily požadované prostředky Azure PaaS ve svém předplatném:
- Centrální síťový tým nebo centrální tým platformy musí zajistit, aby aplikační týmy mohly nasazovat a přistupovat ke službám Azure PaaS pouze prostřednictvím privátních koncových bodů.
- Centrální síťové týmy a/nebo centrální platformy musí zajistit, aby při vytváření privátních koncových bodů nastavili způsob zpracování odpovídajících záznamů. Nastavte odpovídající záznamy tak, aby se automaticky vytvořily v centralizované privátní zóně DNS, která odpovídá vytvářené službě.
- Záznamy DNS musí dodržovat životní cyklus privátního koncového bodu, proto se při odstranění privátního koncového bodu automaticky odeberou.
Poznámka:
Pokud jsou plně kvalifikované názvy domén v pravidlech sítě založené na překladu DNS potřeba použít v zásadách brány Azure Firewall a brány firewall (tato funkce umožňuje filtrovat odchozí provoz pomocí libovolného protokolu TCP/UDP, včetně protokolů NTP, SSH, RDP a dalších). Proxy DNS služby Azure Firewall musíte povolit, aby používal plně kvalifikované názvy domén ve vašich pravidlech sítě. Tyto paprskové virtuální sítě pak musí změnit nastavení DNS z vlastního serveru DNS na proxy DNS služby Azure Firewall. Změna nastavení DNS paprskové virtuální sítě vyžaduje restartování všech virtuálních počítačů uvnitř této virtuální sítě.
Následující části popisují, jak týmy aplikací umožňují tyto podmínky pomocí služby Azure Policy. Příklad používá Azure Storage jako službu Azure, kterou aplikační týmy potřebují nasadit. Stejný princip se ale vztahuje na většinu služeb Azure, které podporují Službu Private Link.
Konfigurace vyžadovaná týmem platformy
Požadavky na konfiguraci týmu platformy zahrnují vytvoření privátních zón DNS, nastavení definic zásad, nasazení zásad a nastavení přiřazení zásad.
Vytváření privátních zón DNS
Vytvořte privátní zóny DNS v předplatném centrálního připojení pro podporované služby Private Link. Další informace najdete v tématu Konfigurace DNS privátního koncového bodu Azure.
V tomto případě je příkladem účet úložiště s objektem blob . Překládá se na vytvoření privatelink.blob.core.windows.net privátní zóny DNS v předplatném připojení.
Definice zásad
Kromě privátních zón DNS musíte také vytvořit sadu vlastních definic Azure Policy. Tyto definice vynucují použití privátních koncových bodů a automatizují vytváření záznamu DNS v zóně DNS, kterou vytvoříte:
Denyveřejný koncový bod pro zásady služeb PaaS.Tato zásada zabrání uživatelům ve vytváření služeb Azure PaaS s veřejnými koncovými body a zobrazí jim chybovou zprávu, pokud při vytváření prostředku nevybere privátní koncový bod.
Přesné pravidlo zásad se může mezi službami PaaS lišit. V případě účtů Azure Storage se podívejte na vlastnost networkAcls.defaultAction , která definuje, jestli jsou požadavky z veřejných sítí povolené nebo ne. V tomto případě nastavte podmínku tak, aby odepřela vytvoření typu prostředku Microsoft.Storage/storageAccounts , pokud vlastnost networkAcls.defaultAction není
Deny. Následující definice zásady ukazuje chování:{ "mode": "All", "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Storage/storageAccounts" }, { "field": "Microsoft.Storage/storageAccounts/networkAcls.defaultAction", "notEquals": "Deny" } ] }, "then": { "effect": "Deny" } } }Denymožnost vytvořit privátní zónu DNS se zásadami předponyprivatelink.Použijte centralizovanou architekturu DNS s podmíněným předáváním a privátními zónami DNS hostovanými v předplatných spravovaných týmem platformy. Je nutné zabránit vlastníkům týmů aplikací vytvářet vlastní privátní zóny DNS služby Private Link a propojit služby se svými předplatnými.
Ujistěte se, že když váš tým aplikace vytvoří privátní koncový bod, bude možnost
Integrate with private DNS zonenastavená naNowebu Azure Portal.
Pokud vyberete
Yesmožnost , Azure Policy vám brání ve vytváření privátního koncového bodu. V definici zásady odmítne možnost vytvořit typ prostředku Microsoft.Network/privateDnsZones , pokud má zóna předponuprivatelink. Následující definice zásady ukazuje předponuprivatelink:{ "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" } } }DeployIfNotExistsautomaticky vytvořit požadovaný záznam DNS v centrální privátní zóně DNS.Následující příklady zásad ukazují dva přístupy k identifikaci, které
privateDNSZoneGroupse vytvoří v privátním koncovém bodu.První zásada spoléhá na
groupIddobu, kdy druhá zásada používá obojíprivateLinkServiceIdigroupID. Druhou zásadu použijte, kdyžgroupIddojde ke střetu (kolidu) s jiným prostředkem.Například SQL
groupIdse používá pro Cosmos DB i Synapse Analytics. Pokud byly k vytvořeníprivateDNSZoneGrouppoložky privátního koncového bodu přiřazeny oba typy prostředků a první zásada, vytvoří se a mapuje na nesprávnou zónu Privátní DNS, a to buď ve službě Cosmos DB, nebo Synapse Analytics. Potom může přepínat mezi jednotlivými zónami kvůli kolidovánígroupId, které první zásada hledá ve svém pravidlu zásad.Seznam prostředků
groupIdprivate-link najdete ve sloupci subresources v části Co je privátní koncový bod?
Tip
Integrované definice Azure Policy se neustále přidávají, odstraňují a aktualizují. Důrazně doporučujeme používat předdefinované zásady a spravovat vlastní zásady (pokud jsou k dispozici). Pomocí AzPolicyAdvertizer vyhledejte existující předdefinované zásady, které mají následující název xxx ... používat privátní zóny DNS. Cílové zóny Azure (ALZ) navíc mají iniciativu zásad, nakonfigurujte služby Azure PaaS tak, aby používaly privátní zóny DNS, které obsahují také integrované zásady a pravidelně se aktualizují. Pokud pro vaši situaci není k dispozici předdefinovaná zásada, zvažte vytvoření problému na azure-policy webu zásad správného řízení Azure na webu pro zpětnou vazbu · Komunita sleduje nový integrovaný proces návrhů zásad v úložišti Azure Policy na GitHubu.
První DeployIfNotExists zásada – porovnávání pouze u groupId
Tato zásada se aktivuje, pokud vytvoříte prostředek privátního koncového bodu s konkrétní groupIdslužbou . Je groupId ID skupiny získané ze vzdáleného prostředku (služby), ke které se má tento privátní koncový bod připojit. Potom aktivuje nasazení v rámci privátního privateDNSZoneGroup koncového bodu, které přidruží privátní koncový bod k zóně privátního DNS. V příkladu groupId jsou blobobjekty blob služby Azure Storage . Další informace o groupId dalších službách Azure najdete v části Konfigurace DNS privátního koncového bodu Azure ve sloupci Subresource . Když zásada najde groupId v privátním koncovém bodu, nasadí privateDNSZoneGroup v rámci privátního koncového bodu a připojí ho k ID prostředku privátní zóny DNS, které je zadané jako parametr. V tomto příkladu je ID prostředku privátní zóny DNS:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.blob.core.windows.net
Následující ukázka kódu ukazuje definici zásady:
{
"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"
}
}
}
}
Druhá DeployIfNotExists zásada – porovnávání groupIdprivateLinkServiceId
Tato zásada se aktivuje, pokud vytvoříte prostředek privátního koncového bodu s konkrétní groupId službou a privateLinkServiceId. Je groupId ID skupiny získané ze vzdáleného prostředku (služby), ke které se má tento privátní koncový bod připojit. Jedná se privateLinkServiceId o ID prostředku vzdáleného prostředku (služby), ke kterému se má tento privátní koncový bod připojit. Pak aktivujte nasazení v rámci privátního privateDNSZoneGroup koncového bodu, které přidruží privátní koncový bod k zóně privátního DNS.
V příkladu groupId je SQL pro Službu Azure Cosmos DB (SQL) a privateLinkServiceId musí obsahovat Microsoft.DocumentDb/databaseAccounts. Další informace o službách groupId Azure a privateLinkServiceId dalších službách Azure najdete v části Konfigurace DNS privátního koncového bodu Azure ve sloupci Subresource . Když zásada najde groupId a privateLinkServiceId v privátním koncovém bodu, nasadí privateDNSZoneGroup v rámci privátního koncového bodu. A je propojený s ID prostředku privátní zóny DNS, které je zadané jako parametr. Následující definice zásady ukazuje ID prostředku privátní zóny DNS:
/subscriptions/<subscription-id>/resourceGroups/<resourceGroupName>/providers/Microsoft.Network/privateDnsZones/privatelink.documents.azure.com
Následující ukázka kódu ukazuje definici zásady:
{
"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"
}
}
}
Přiřazení zásad
Po nasazení definic zásad přiřaďte zásady v požadovaném oboru v hierarchii skupin pro správu. Ujistěte se, že přiřazení zásad cílí na předplatná Azure, která aplikační týmy používají k nasazení služeb PaaS s výhradním přístupem k privátnímu koncovému bodu.
Důležité
Kromě přiřazení roleDefinition definované v zásadách nezapomeňte přiřadit roli role přispěvatele zóny Privátní DNS v předplatném a skupině prostředků, kde jsou privátní zóny DNS hostované na spravovanou identitu vytvořenou přiřazením DeployIfNotExists zásady, která bude zodpovědná za vytvoření a správu záznamu DNS privátního koncového bodu v privátní zóně DNS. Důvodem je to, že privátní koncový bod se nachází v předplatném Azure vlastníka aplikace, zatímco privátní zóna DNS se nachází v jiném předplatném (například v předplatném centrálního připojení).
Jakmile tým platformy dokončí konfiguraci:
- Předplatná Azure týmů aplikací jsou připravená pro tým, aby pak vytvořily služby Azure PaaS s výhradním přístupem k privátnímu koncovému bodu.
- Tým musí zajistit, aby se záznamy DNS pro privátní koncové body automaticky zaregistrovaly (a odeberou se po odstranění privátního koncového bodu) z odpovídajících privátních zón DNS.
Prostředí vlastníka aplikace
Jakmile tým platformy nasadí komponenty infrastruktury platformy (privátní zóny a zásady DNS), vlastník aplikace má při pokusu o nasazení služby Azure PaaS do předplatného Azure následující prostředí. Toto prostředí je stejné bez ohledu na to, jestli své aktivity provádí prostřednictvím webu Azure Portal nebo jiných klientů, jako je PowerShell nebo rozhraní příkazového řádku, protože zásady Azure řídí svá předplatná.
Vytvořte účet úložiště prostřednictvím webu Azure Portal. Na kartě Základy zvolte požadované nastavení, zadejte název účtu úložiště a vyberte Další.
Na kartě Sítě vyberte privátní koncový bod. Pokud vyberete jinou možnost než privátní koncový bod, azure Portal vám nedovolí vytvořit účet úložiště v části Zkontrolovat a vytvořit průvodce nasazením. Zásady vám brání v vytváření této služby, pokud je povolený veřejný koncový bod.
Privátní koncový bod teď nebo po vytvoření účtu úložiště je možné vytvořit. Tento příklad ukazuje vytvoření privátního koncového bodu po vytvoření účtu úložiště. Krok dokončete výběrem možnosti Zkontrolovat a vytvořit .
Po vytvoření účtu úložiště vytvořte privátní koncový bod prostřednictvím webu Azure Portal.
V části Prostředek vyhledejte účet úložiště, který jste vytvořili v předchozím kroku. V části cílový podsourc vyberte Objekt blob a pak vyberte Další.
V části Konfigurace po výběru virtuální sítě a podsítě se ujistěte, že možnost Integrace s privátní zónou DNS je nastavená na Ne. Jinak vám Azure Portal brání ve vytváření privátního koncového bodu. Azure Policy neumožňuje vytvořit privátní zónu DNS s předponou
privatelink.
Vyberte Zkontrolovat a vytvořit a pak vyberte Vytvořit a nasaďte privátní koncový bod.
Po několika minutách se
DeployIfNotExistszásady aktivují. NáslednédnsZoneGroupnasazení pak přidá požadované záznamy DNS pro privátní koncový bod v centrálně spravované zóně DNS.Po vytvoření privátního koncového bodu ho vyberte a zkontrolujte jeho plně kvalifikovaný název domény a privátní IP adresu:
Zkontrolujte protokol aktivit pro skupinu prostředků, ve které byl vytvořen privátní koncový bod. Nebo můžete zkontrolovat protokol aktivit samotného privátního koncového bodu. Všimněte si,
DeployIfNotExistže po několika minutách se spustí akce zásad a nakonfiguruje skupinu zón DNS na privátním koncovém bodu:
Pokud centrální síťový tým přejde do
privatelink.blob.core.windows.netprivátní zóny DNS, potvrdí, že pro vytvořený privátní koncový bod existuje záznam DNS, a název i IP adresa odpovídají hodnotám v privátním koncovém bodu.
V tomto okamžiku můžou aplikační týmy používat účet úložiště prostřednictvím privátního koncového bodu z jakékoli virtuální sítě v prostředí hvězdicové sítě a z místního prostředí. Záznam DNS se automaticky zaznamenal v privátní zóně DNS.
Pokud vlastník aplikace odstraní privátní koncový bod, odpovídající záznamy v privátní zóně DNS se automaticky odeberou.
Další kroky
Zkontrolujte DNS pro místní prostředky a prostředky Azure. Zkontrolujte plán vzdáleného přístupu k virtuálním počítačům.
Důležité
Tento článek popisuje integraci DNS a private linku ve velkém měřítku pomocí zásad DINE (DeployIfNotExists) přiřazených skupině pro správu. To znamená, že při vytváření privátních koncových bodů s tímto přístupem není potřeba zpracovávat integraci DNS v kódu, protože se zpracovává zásadami. Je také nepravděpodobné, že aplikační týmy mají přístup RBAC k centralizovaným Privátní DNS zón.
Níže najdete užitečné odkazy na kontrolu při vytváření privátního koncového bodu pomocí Bicep a HashiCorp Terraformu.
Vytvoření privátního koncového bodu pomocí infrastruktury jako kódu:
Rychlý start : Vytvoření privátního koncového bodu pomocí Bicep
Vytvořte privátní koncový bod pomocí azurerm_private_endpoint HashiCorp Terraform v Terrafrom Registry.
V nástrojích infrastruktury jako kódu ale můžete dál vytvářet privátní koncové body, pokud ale použijete přístup zásad DINE, jak je uvedeno v tomto článku, měli byste ponechat integraci DNS mimo váš kód a nechat zásady DINE, které mají požadované RBAC pro Privátní DNS Zónu, to místo toho zvládnou.
Váš názor
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu: https://aka.ms/ContentUserFeedback.
Odeslat a zobrazit názory pro