Udostępnij za pośrednictwem

Ograniczanie łączności publicznej w usłudze Azure HDInsight

  • Artykuł

W domyślnej architekturze sieci wirtualnej usługi Azure HDInsight dostawca zasobów usługi HDInsight komunikuje się z klastrem za pośrednictwem sieci publicznej. W tym artykule przedstawiono zaawansowane mechanizmy kontroli, których można użyć do tworzenia klastra usługi HDInsight z ograniczeniami, w którym łączność przychodząca jest ograniczona do sieci prywatnej.

Jeśli potrzebujesz łączności publicznej między klastrem usługi HDInsight i zasobami zależnymi, rozważ ograniczenie łączności klastra, postępując zgodnie z wytycznymi w temacie Kontrolowanie ruchu sieciowego w usłudze Azure HDInsight. Oprócz ograniczania łączności publicznej można skonfigurować zasoby zależności z obsługą Azure Private Link do użycia z klastrami usługi HDInsight.

Na poniższym diagramie przedstawiono, jak może wyglądać potencjalna architektura sieci wirtualnej usługi HDInsight w przypadku resourceProviderConnection ustawienia ruchu wychodzącego:

Diagram architektury usługi HDInsight przy użyciu połączenia wychodzącego dostawcy zasobów.

Uwaga

Ograniczenie łączności publicznej jest wymaganiem wstępnym dla włączenia Private Link i nie powinno być traktowane jako ta sama funkcja.

Inicjowanie klastra z ograniczeniami

Domyślnie dostawca zasobów usługi HDInsight używa połączenia przychodzącego z klastrem przy użyciu publicznych adresów IP. resourceProviderConnection Gdy właściwość sieci jest ustawiona na wychodzący, odwraca połączenia z dostawcą zasobów usługi HDInsight, aby połączenia zawsze inicjowane z wewnątrz klastra i wychodzące do dostawcy zasobów.

W tej konfiguracji bez połączenia przychodzącego nie ma potrzeby konfigurowania tagów usługi dla ruchu przychodzącego w sieciowej grupie zabezpieczeń. Nie ma również potrzeby pomijania zapory ani wirtualnego urządzenia sieciowego za pośrednictwem tras zdefiniowanych przez użytkownika.

Uwaga

Implementacje w usłudze Microsoft Azure Government mogą nadal wymagać tagów usługi dla ruchu przychodzącego w sieciowej grupie zabezpieczeń i trasach zdefiniowanych przez użytkownika.

Po utworzeniu klastra skonfiguruj prawidłowe rozpoznawanie nazw DNS, dodając rekordy DNS, które są wymagane dla ograniczonego klastra usługi HDInsight. Następujący rekord DNS o nazwie kanonicznej (CNAME) jest tworzony w zarządzanej przez platformę Azure publicznej strefie DNS: azurehdinsight.net.

<clustername>    CNAME    <clustername>-int

Aby uzyskać dostęp do klastra przy użyciu w pełni kwalifikowanych nazw domen (FQDN), możesz użyć jednej z tych technik zgodnie z potrzebami:

  • Użyj prywatnych adresów IP wewnętrznego modułu równoważenia obciążenia bezpośrednio.
  • Użyj własnej prywatnej strefy DNS, aby zastąpić punkty końcowe klastra. W takim przypadku nazwa strefy musi mieć wartość azurehdinsight.net.

Na przykład w przypadku prywatnej strefy azurehdinsight.netDNS możesz dodać prywatne adresy IP zgodnie z potrzebami:

<clustername>        A   10.0.0.1
<clustername-ssh>    A   10.0.0.2

Uwaga

Nie zalecamy umieszczania klastrów z ograniczeniami w tej samej sieci wirtualnej (z prywatną strefą DNS dla azurehdinsight.netprogramu ) jako innych klastrów, w których włączono łączność publiczną. Może to spowodować niezamierzone zachowanie rozpoznawania nazw DNS lub konflikty.

Aby ułatwić konfigurację dns, zwracamy nazwy FQDN i odpowiadające im prywatne adresy IP w ramach odpowiedzi klastra GET . Możesz użyć tego fragmentu kodu programu PowerShell, aby rozpocząć pracę:

<#
    This script is an example to help you get started with automation and can be adjusted based on your needs.
    This script assumes:
    - The HDInsight cluster has already been created, and the context where this script is run has permissions to read/write resources in the same resource group.
    - The private DNS zone resource exists in the same subscription as the HDInsight cluster.
We recommend that you use the latest version of the Az.HDInsight module.

#>
$subscriptionId = "<Replace with subscription for deploying HDInsight clusters, and containing private DNS zone resource>"

$clusterName = "<Replace with cluster name>"
$clusterResourceGroupName = "<Replace with resource group name>"

# For example, azurehdinsight.net for public cloud.
$dnsZoneName = "<Replace with private DNS zone name>"
$dnsZoneResourceGroupName = "<Replace with private DNS zone resource group name>"

Connect-AzAccount -SubscriptionId $subscriptionId

# 1. Get cluster endpoints
$clusterEndpoints = $(Get-AzHDInsightCluster -ClusterName $clusterName ` -ResourceGroupName $clusterResourceGroupName).ConnectivityEndpoints

$endpointMapping = @{}

foreach($endpoint in $clusterEndpoints)
{
    $label = $endpoint.Location.ToLower().Replace(".$dnsZoneName".ToLower(), "")
    $ip = $endpoint.PrivateIPAddress

    $endpointMapping.Add($label, $ip)
}

# 2. Confirm that the DNS zone exists.
Get-AzPrivateDnsZone -ResourceGroupName $dnsZoneResourceGroupName -Name $dnsZoneName -ErrorAction Stop

# 3. Update DNS entries for the cluster in the private DNS zone:
#    - If the entries already exist, update to the new IP.
#    - If the entries don't exist, create them.
$recordSets = Get-AzPrivateDnsRecordSet -ZoneName $dnsZoneName -ResourceGroupName $dnsZoneResourceGroupName -RecordType A

foreach($label in $endpointMapping.Keys)
{
    $updateRecord = $null

    foreach($record in $recordSets)
    {
        if($record.Name -eq $label)
        {
            $updateRecord = $record
            break;
        }
        
    }

    if($null -ne $updateRecord)
    {
        $updateRecord.Records[0].Ipv4Address = $endpointMapping[$label]
        Set-AzPrivateDnsRecordSet -RecordSet $updateRecord | Out-Null
    }
    else
    {
        New-AzPrivateDnsRecordSet `
            -ResourceGroupName $dnsZoneResourceGroupName `
            -ZoneName $dnsZoneName `
            -Name $label `
            -RecordType A `
            -Ttl 3600 `
            -PrivateDnsRecord (New-AzPrivateDnsRecordConfig -Ipv4Address $endpointMapping[$label]) | Out-Null
    }
}

Konfigurowanie resourceProviderConnection ruchu wychodzącego umożliwia również dostęp do zasobów specyficznych dla klastra przy użyciu prywatnych punktów końcowych. Te zasoby obejmują:

  • Magazyn: Azure Data Lake Storage Gen2 i Azure Blob Storage
  • Magazyny metadanych SQL: Apache Ranger, Ambari, Oozie i Hive
  • Azure Key Vault

Nie jest wymagane używanie prywatnych punktów końcowych dla tych zasobów. Jeśli jednak planujesz używać prywatnych punktów końcowych dla tych zasobów, musisz utworzyć zasoby i skonfigurować prywatne punkty końcowe i wpisy DNS przed utworzeniem klastra usługi HDInsight. Wszystkie te zasoby powinny być dostępne z poziomu podsieci klastra za pośrednictwem prywatnego punktu końcowego lub w inny sposób. Jeśli planujesz użyć prywatnego punktu końcowego, zaleca się korzystanie z podsieci klastra.

Podczas nawiązywania połączenia z usługą Azure Data Lake Storage Gen2 za pośrednictwem prywatnego punktu końcowego upewnij się, że konto magazynu Gen2 ma punkt końcowy ustawiony zarówno blob dla parametru , jak i dfs. Aby uzyskać więcej informacji, zobacz Tworzenie prywatnego punktu końcowego.

Korzystanie z zapory (opcjonalnie)

Klastry usługi HDInsight mogą nadal łączyć się z publicznym Internetem, aby uzyskać zależności wychodzące. Jeśli chcesz ograniczyć dostęp, możesz skonfigurować zaporę, ale nie jest to wymagane.

Tworzenie klastrów

Poniższy fragment kodu JSON zawiera dwie właściwości sieci, które należy skonfigurować w szablonie usługi Azure Resource Manager w celu utworzenia prywatnego klastra usługi HDInsight:

networkProperties: {
    "resourceProviderConnection": "Outbound"
}

Pełny szablon zawierający wiele funkcji zabezpieczeń przedsiębiorstwa usługi HDInsight, w tym Private Link, można znaleźć w temacie Szablon zabezpieczeń przedsiębiorstwa usługi HDInsight.

Aby utworzyć klaster przy użyciu programu PowerShell, zobacz przykład.

Aby utworzyć klaster przy użyciu interfejsu wiersza polecenia platformy Azure, zobacz przykład.

Następne kroki