Limitare la connettività pubblica in Azure HDInsight

Nell'architettura di rete virtuale predefinita di Azure HDInsight il provider di risorse HDInsight comunica con il cluster tramite una rete pubblica. In questo articolo vengono illustrati i controlli avanzati che è possibile usare per creare un cluster HDInsight con restrizioni in cui la connettività in ingresso è limitata a una rete privata.

Se si vuole la connettività pubblica tra il cluster HDInsight e le risorse dipendenti, è consigliabile limitare la connettività del cluster seguendo le linee guida in Controllare il traffico di rete in Azure HDInsight. Oltre a limitare la connettività pubblica, è possibile configurare le risorse di dipendenza abilitate per collegamento privato di Azure da usare con i cluster HDInsight.

Il diagramma seguente illustra l'aspetto di un'architettura di rete virtuale HDInsight potenziale quando resourceProviderConnection è impostato su in uscita:

Diagramma che mostra l'architettura di HDInsight usando una connessione al provider di risorse in uscita.

Nota

La limitazione della connettività pubblica è un prerequisito per l'abilitazione di collegamento privato e non deve essere considerata la stessa funzionalità.

Inizializzare un cluster con restrizioni

Per impostazione predefinita, il provider di risorse HDInsight usa una connessione in ingresso al cluster usando indirizzi IP pubblici. Quando la resourceProviderConnection proprietà di rete è impostata su in uscita, inverte le connessioni al provider di risorse HDInsight, in modo che le connessioni vengano sempre avviate dall'interno del cluster e vengano aperte al provider di risorse.

In questa configurazione, senza una connessione in ingresso, non è necessario configurare i tag del servizio in ingresso nel gruppo di sicurezza di rete. Non è inoltre necessario ignorare il firewall o l'appliance virtuale di rete tramite route definite dall'utente.

Nota

Le implementazioni in Microsoft Azure per enti pubblici potrebbero comunque richiedere i tag del servizio in ingresso nel gruppo di sicurezza di rete e nelle route definite dall'utente.

Dopo aver creato il cluster, configurare la risoluzione DNS appropriata aggiungendo i record DNS necessari per il cluster HDInsight con restrizioni. Il record DNS del nome canonico seguente (CNAME) viene creato nella zona DNS pubblica gestita da Azure: azurehdinsight.net.

<clustername>    CNAME    <clustername>-int

Per accedere al cluster usando nomi di dominio completi (FQDN), è possibile usare una di queste tecniche in base alle esigenze:

  • Usare direttamente gli indirizzi IP privati del servizio di bilanciamento del carico interno.
  • Usare la propria zona DNS privata per eseguire l'override degli endpoint del cluster. In questo caso, il nome della zona deve essere azurehdinsight.net.

Ad esempio, per la zona azurehdinsight.netDNS privata, è possibile aggiungere gli indirizzi IP privati in base alle esigenze:

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

Nota

Non è consigliabile inserire cluster con restrizioni nella stessa rete virtuale (con una zona DNS privata per azurehdinsight.net) come altri cluster in cui è abilitata la connettività pubblica. Potrebbe causare conflitti o comportamenti imprevisti di risoluzione DNS.

Per semplificare la configurazione dns, vengono restituiti i nomi di dominio completi e gli indirizzi IP privati corrispondenti come parte della risposta del cluster GET . È possibile usare questo frammento di codice di PowerShell per iniziare:

<#
    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
    }
}

La configurazione resourceProviderConnection in uscita consente anche di accedere a risorse specifiche del cluster usando endpoint privati. Tali risorse includono:

  • Archiviazione: Azure Data Lake Storage Gen2 e Archiviazione BLOB di Azure
  • Metastore SQL: Apache Ranger, Ambari, Oozie e Hive
  • Azure Key Vault

Non è obbligatorio usare endpoint privati per queste risorse. Tuttavia, se si prevede di usare endpoint privati per queste risorse, è necessario creare le risorse e configurare gli endpoint privati e le voci DNS prima di creare il cluster HDInsight. Tutte queste risorse devono essere accessibili dall'interno della subnet del cluster, tramite un endpoint privato o in altro modo. Se si prevede di usare un endpoint privato, è consigliabile sfruttare la subnet del cluster.

Quando ci si connette ad Azure Data Lake Storage Gen2 tramite un endpoint privato, assicurarsi che l'account di archiviazione Gen2 abbia un endpoint impostato sia per che dfsper blob . Per altre informazioni, vedere Creare un endpoint privato.

Usare un firewall (facoltativo)

I cluster HDInsight possono comunque connettersi a Internet pubblico per ottenere dipendenze in uscita. Se si vuole limitare l'accesso, è possibile configurare un firewall, ma non è un requisito.

Creare i cluster

Il frammento di codice JSON seguente include le due proprietà di rete che è necessario configurare nel modello di Azure Resource Manager per creare un cluster HDInsight privato:

networkProperties: {
    "resourceProviderConnection": "Outbound"
}

Per un modello completo con molte delle funzionalità di sicurezza aziendali di HDInsight, tra cui collegamento privato, vedere modello di sicurezza aziendale HDInsight.

Per creare un cluster usando PowerShell, vedere l'esempio.

Per creare un cluster usando l'interfaccia della riga di comando di Azure, vedere l'esempio.

Passaggi successivi