Konfigurera utgående nätverkstrafik för Azure HDInsight-kluster med hjälp av brandväggen
Den här artikeln innehåller stegen för att skydda utgående trafik från ditt HDInsight-kluster med hjälp av Azure Firewall. Stegen nedan förutsätter att du konfigurerar en Azure Firewall för ett befintligt kluster. Om du distribuerar ett nytt kluster bakom en brandvägg skapar du först ditt HDInsight-kluster och undernät. Följ sedan stegen i den här guiden.
Bakgrund
HDInsight-kluster distribueras normalt i ett virtuellt nätverk. Klustret har beroenden för tjänster utanför det virtuella nätverket.
Inkommande hanteringstrafik kan inte skickas via en brandvägg. Du kan använda NSG-tjänsttaggar för inkommande trafik enligt beskrivningen här.
HDInsights utgående trafikberoenden definieras nästan helt och hållet med FQDN. Som inte har statiska IP-adresser bakom sig. Bristen på statiska adresser innebär att nätverkssäkerhetsgrupper inte kan låsa utgående trafik från ett kluster. IP-adresserna ändras tillräckligt ofta. Det går inte att konfigurera regler baserat på aktuell namnmatchning och användning.
Skydda utgående adresser med en brandvägg som kan styra utgående trafik baserat på FQDN. Azure Firewall begränsar utgående trafik baserat på FQDN för mål- eller FQDN-taggarna.
Konfigurera Azure Firewall med HDInsight
En sammanfattning av stegen för att låsa utgående trafik från din befintliga HDInsight med Azure Firewall är:
- Skapa ett undernät.
- Skapa en brandvägg.
Add application
regler för brandväggen.- Lägg till nätverksregler i brandväggen.
- Skapa en routningstabell.
Skapa nytt undernät
Skapa ett undernät med namnet AzureFirewallSubnet i det virtuella nätverk där klustret finns.
Skapa en ny brandvägg för klustret
Skapa en brandvägg med namnet Test-FW01 med hjälp av stegen i Distribuera brandväggen från Självstudie: Distribuera och konfigurera Azure Firewall med hjälp av Azure Portal.
Konfigurera brandväggen med programregler
Skapa en programregelsamling som gör att klustret kan skicka och ta emot viktig kommunikation.
Välj den nya brandväggen Test-FW01 från Azure Portal.
Gå till Regelsamling för inställningsregler.>+
Add application rule collection
>>Ange följande information på
Add application rule collection
skärmen:Övre avsnittet
Property Värde Name FwAppRule Prioritet 200 Åtgärd Tillåt Avsnittet FQDN-taggar
Name Källadress FQDN-tagg Kommentar Rule_1 * WindowsUpdate och HDInsight Krävs för HDI-tjänster Avsnittet Mål-FQDN
Name Källadresser Protokoll: Port Mål-FQDNS Kommentar Rule_2 * https:443 login.windows.net Tillåter Windows-inloggningsaktivitet Rule_3 * https:443 login.microsoftonline.com Tillåter Windows-inloggningsaktivitet Rule_4 * https:443 storage_account_name.blob.core.windows.net Ersätt storage_account_name
med ditt faktiska lagringskontonamn. Kontrollera att "säker överföring krävs" är aktiverat på lagringskontot. Om du använder privat slutpunkt för att komma åt lagringskonton behövs inte det här steget och lagringstrafiken vidarebefordras inte till brandväggen.Rule_5 * http:80 azure.archive.ubuntu.com Tillåter att Ubuntu-säkerhetsuppdateringar installeras i klustret Rule_6 * https:433 pypi.org, pypi.python.org, files.pythonhosted.org Tillåter Python-paketinstallationer för Azure-övervakning Markera Lägga till.
Konfigurera brandväggen med nätverksregler
Skapa nätverksregler för att konfigurera HDInsight-klustret korrekt.
Om du fortsätter från föregående steg går du till Nätverksregelsamling>
+ Add network rule collection
.Ange följande information på
Add network rule collection
skärmen:Övre avsnittet
Property Värde Name FwNetRule Prioritet 200 Åtgärd Tillåt Avsnittet Tjänsttaggar
Name Protokoll Källadresser Tjänsttaggar Målportar Kommentar Rule_6 TCP * SQL 1433, 11000-11999 Om du använder sql-standardservrarna som tillhandahålls av HDInsight konfigurerar du en nätverksregel i avsnittet Tjänsttaggar för SQL som gör att du kan logga och granska SQL-trafik. Såvida du inte har konfigurerat tjänstslutpunkter för SQL Server i HDInsight-undernätet, vilket kringgår brandväggen. Om du använder en anpassad SQL-server för metaarkivet Ambari, Oozie, Ranger och Hive behöver du bara tillåta trafiken till dina egna anpassade SQL-servrar. Se anslutningsarkitekturen för Azure SQL Database och Azure Synapse Analytics för att se varför portintervallet 11000-11999 också behövs utöver 1433. Rule_7 TCP * Azure Monitor * (valfritt) Kunder som planerar att använda funktionen för automatisk skalning bör lägga till den här regeln. Markera Lägga till.
Skapa och konfigurera en routningstabell
Skapa en routningstabell med följande poster:
Alla IP-adresser från hälso- och hanteringstjänster med en nästa hopptyp av Internet. Den bör innehålla 4 IP-adresser för de allmänna regionerna samt 2 IP-adresser för din specifika region. Den här regeln behövs bara om ResourceProviderConnection är inställd på Inkommande. Om ResourceProviderConnection är inställt på Utgående krävs inte dessa IP-adresser i UDR.
En virtuell installationsväg för IP-adressen 0.0.0.0/0 och nästa hopp är din privata IP-adress för Azure Firewall.
Om du till exempel vill konfigurera routningstabellen för ett kluster som skapats i usa-regionen "USA, östra" använder du följande steg:
Välj Din Azure-brandvägg Test-FW01. Kopiera den privata IP-adress som visas på sidan Översikt . I det här exemplet använder vi en exempeladress på 10.0.2.4.
Gå sedan till Alla tjänster>Nätverksvägstabeller och Skapa routningstabell.>
Från den nya vägen navigerar du till Inställningsvägar>>+ Lägg till. Lägg till följande vägar:
Vägnamn | Adressprefix | Nästa hopptyp | Nexthop-adress |
---|---|---|---|
168.61.49.99 | 168.61.49.99/32 | Internet | NA |
23.99.5.239 | 23.99.5.239/32 | Internet | NA |
168.61.48.131 | 168.61.48.131/32 | Internet | NA |
138.91.141.162 | 138.91.141.162/32 | Internet | NA |
13.82.225.233 | 13.82.225.233/32 | Internet | NA |
40.71.175.99 | 40.71.175.99/32 | Internet | NA |
0.0.0.0 | 0.0.0.0/0 | Virtuell installation | 10.0.2.4 |
Slutför konfigurationen av routningstabellen:
Tilldela routningstabellen som du skapade till ditt HDInsight-undernät genom att välja Undernät under Inställningar.
Välj + Associera.
På skärmen Associera undernät väljer du det virtuella nätverk som klustret skapades till. Och det undernät som du använde för ditt HDInsight-kluster.
Välj OK.
Gränsnods- eller anpassad programtrafik
Stegen ovan gör att klustret kan fungera utan problem. Du måste fortfarande konfigurera beroenden för att anpassa dina anpassade program som körs på kantnoderna, om tillämpligt.
Programberoenden måste identifieras och läggas till i Azure Firewall eller routningstabellen.
Vägar måste skapas för programtrafiken för att undvika asymmetriska routningsproblem.
Om dina program har andra beroenden måste de läggas till i Azure Firewall. Skapa programregler för att tillåta HTTP/HTTPS-trafik och nätverksregler för allt annat.
Loggning och skalning
Azure Firewall kan skicka loggar till några olika lagringssystem. Anvisningar om hur du konfigurerar loggning för brandväggen finns i Självstudie: Övervaka Loggar och mått för Azure Firewall.
När du har slutfört loggningskonfigurationen kan du, om du använder Log Analytics, visa blockerad trafik med en fråga som:
AzureDiagnostics | where msg_s contains "Deny" | where TimeGenerated >= ago(1h)
Det är användbart att integrera Azure Firewall med Azure Monitor-loggar när du först får ett program att fungera. Särskilt när du inte känner till alla programberoenden. Du kan lära dig mer om Azure Monitor-loggar från Analysera loggdata i Azure Monitor
Mer information om skalningsgränserna för Azure Firewall och ökningar av begäranden finns i det här dokumentet eller läs vanliga frågor och svar.
Åtkomst till klustret
När brandväggen har konfigurerats kan du använda den interna slutpunkten (https://CLUSTERNAME-int.azurehdinsight.net
) för att komma åt Ambari inifrån det virtuella nätverket.
Om du vill använda den offentliga slutpunkten (https://CLUSTERNAME.azurehdinsight.net
) eller ssh-slutpunkten (CLUSTERNAME-ssh.azurehdinsight.net
) kontrollerar du att du har rätt vägar i routningstabellen och NSG-reglerna för att undvika det asymmetriska routningsproblem som beskrivs här. Specifikt i det här fallet måste du tillåta klientens IP-adress i reglerna för inkommande NSG och även lägga till den i den användardefinierade routningstabellen med nästa hopp inställt som internet
. Om routningen inte är korrekt konfigurerad visas ett timeoutfel.