Konfigurowanie wychodzącego ruchu sieciowego dla klastrów usługi Azure HDInsight przy użyciu zapory

Ten artykuł zawiera kroki zabezpieczania ruchu wychodzącego z klastra usługi HDInsight przy użyciu usługi Azure Firewall. W poniższych krokach założono, że konfigurujesz usługę Azure Firewall dla istniejącego klastra. Jeśli wdrażasz nowy klaster za zaporą sieciową, utwórz najpierw klaster HDInsight i podsieć. Następnie wykonaj kroki opisane w tym przewodniku.

Tło

Klastry usługi HDInsight są zwykle wdrażane w sieci wirtualnej. Klaster ma zależności od usług spoza tej sieci wirtualnej.

Nie można wysyłać ruchu zarządzającego przychodzącego przez zaporę. Możesz używać tagów usług NSG dla ruchu przychodzącego, zgodnie z dokumentacją tutaj.

Zależności ruchu wychodzącego usługi HDInsight są prawie całkowicie zdefiniowane za pomocą nazw FQDN. Które nie mają statycznych adresów IP. Brak adresów statycznych oznacza, że sieciowe grupy zabezpieczeń nie mogą blokować ruchu wychodzącego z klastra. Adresy IP zmieniają się często na tyle, że nie można skonfigurować reguł na podstawie bieżącego rozpoznawania nazw i użycia.

Zabezpiecz adresy wychodzące za pomocą firewalla, który może kontrolować ruch wychodzący na podstawie pełnych nazw domen (FQDN). Zapora Azure Firewall ogranicza ruch wychodzący na podstawie nazwy FQDN docelowego lub tagów FQDN.

Konfigurowanie usługi Azure Firewall za pomocą usługi HDInsight

Podsumowanie kroków blokowania ruchu wychodzącego z istniejącej usługi HDInsight za pomocą usługi Azure Firewall to:

1. Utwórz podsieć.
2. Utwórz zaporę.
3. Add application reguły dla zapory.
4. Dodaj reguły sieciowe do zapory.
5. Utwórz tabelę routingu.

Tworzenie nowej podsieci

Utwórz podsieć o nazwie AzureFirewallSubnet w sieci wirtualnej, w której istnieje klaster.

Tworzenie nowej zapory dla klastra

Utwórz zaporę o nazwie Test-FW01, wykonując kroki opisane w części Wdrażanie zapory z samouczka: wdrażanie i konfigurowanie Azure Firewall przy użyciu portalu Azure.

Konfigurowanie zapory przy użyciu reguł aplikacji

Utwórz kolekcję reguł aplikacji, która umożliwia klastrowi wysyłanie i odbieranie ważnej komunikacji.

1. Wybierz nową zaporę Test-FW01 w witrynie Azure Portal.

2. Przejdź do Ustawienia>Reguły>Kolekcja reguł aplikacji>+ Add application rule collection.

   

3. Na ekranie Add application rule collection podaj następujące informacje:

   Górna sekcja

   Własność	Wartość
   Nazwisko	FwAppRule
   Priorytet	200
   Akcja	Zezwól

   Sekcja tagów FQDN

   Nazwisko	Adresy źródłowe	Tag nazwy FQDN	Uwagi
   Rule_1	*	WindowsUpdate i HDInsight	Wymagane dla usług HDI

   Docelowa sekcja nazw FQDN

   Nazwisko	Adresy źródłowe	Protokół: Port	Docelowe w pełni kwalifikowane nazwy domen	Uwagi
   Rule_2	*	https:443	login.windows.net	Zezwala na aktywność logowania w systemie Windows
   Rule_3	*	https:443	login.microsoftonline.com	Zezwala na aktywność logowania do systemu Windows
   Rule_4	*	https:443	storage_account_name.blob.core.windows.net	Zastąp storage_account_name rzeczywistą nazwą konta magazynu. Upewnij się, że opcja "Wymagany bezpieczny transfer" jest włączona na koncie przechowywania. Jeśli używasz prywatnego punktu końcowego do uzyskiwania dostępu do kont magazynowych, ten krok nie jest potrzebny, a ruch ten nie jest przekazywany do zapory.
   Rule_5	*	http:80	azure.archive.ubuntu.com	Zezwala na instalowanie aktualizacji zabezpieczeń systemu Ubuntu w klastrze
   Rule_6	*	https:443	pypi.org, pypi.python.org, files.pythonhosted.org	Umożliwia instalowanie pakietów języka Python na potrzeby monitorowania platformy Azure

   

4. Wybierz Dodaj.

Konfigurowanie zapory przy użyciu reguł sieci

Utwórz reguły sieciowe, aby poprawnie skonfigurować klaster usługi HDInsight.

1. Kontynuując poprzedni krok, przejdź do kolekcji>+ Add network rule collection reguł sieciowych.

2. Na ekranie Add network rule collection podaj następujące informacje:

   Górna sekcja

   Nieruchomość	Wartość
   Nazwisko	FwNetRule
   Priorytet	200
   Akcja	Zezwól

   Sekcja Tagów Usług

   Nazwisko	Protokół	Adresy źródłowe	Tagi usługi	Porty docelowe	Uwagi
   Rule_6	TCP	*	SQL	1433, 11000-11999	Jeśli używasz domyślnych serwerów SQL udostępnianych przez usługę HDInsight, skonfiguruj regułę sieciową w sekcji Tagi usług dla języka SQL, która umożliwi rejestrowanie i inspekcję ruchu SQL. Jeśli skonfigurowałeś punkty końcowe usługi dla programu SQL Server w podsieci HDInsight, zapora zostanie pominięta. Jeśli używasz niestandardowego serwera SQL dla Ambari, Oozie, Ranger i magazynu metadanych Hive, wystarczy, że zezwolisz na ruch do własnych niestandardowych serwerów SQL. Zapoznaj się z architekturą łączności usług Azure SQL Database i Azure Synapse Analytics, aby dowiedzieć się, dlaczego zakres portów 11000-11999 jest również potrzebny oprócz 1433.
   Rule_7	TCP	*	Azure Monitor	*	(opcjonalnie) Klienci, którzy planują korzystać z funkcji automatycznego skalowania, powinni dodać tę regułę.

   

3. Wybierz Dodaj.

Tworzenie i konfigurowanie tabeli tras

Utwórz tabelę tras z następującymi wpisami:

• Wszystkie adresy IP i tagi usługi z usług Kondycja i zarządzanie z typem następnego przeskoku Internet. Powinien zawierać 4 adresy IP regionów ogólnych, a także tagi usług dla określonego regionu. Ta reguła jest wymagana tylko wtedy, gdy właściwość ResourceProviderConnection jest ustawiona na Przychodzące. Jeśli parametr ResourceProviderConnection jest ustawiony na Outbound, te adresy IP nie są potrzebne w trasach zdefiniowanych przez użytkownika.

• Jedna trasa urządzenia wirtualnego dla adresu IP 0.0.0.0/0 z następnym przeskokiem to prywatny adres IP usługi Azure Firewall.

Aby na przykład skonfigurować tabelę tras dla klastra utworzonego w regionie USA "Wschodnie stany USA", wykonaj następujące kroki:

1. Wybierz zaporę platformy Azure Test-FW01. Skopiuj prywatny adres IP wymieniony na stronie Przegląd. W tym przykładzie użyjemy przykładowego adresu 10.0.2.4.

2. Następnie przejdź do Wszystkie usługi>Sieć>Tabele tras i Utwórz tabelę tras.

3. Z nowej trasy przejdź do pozycji Ustawienia>>+ Dodaj. Dodaj następujące trasy:

Ukończ konfigurację tabeli tras:

1. Przypisz utworzoną tabelę tras do podsieci HDInsight, wybierając pozycję Podsieci w obszarze Ustawienia.

2. Wybierz + Skojarz.

3. Na ekranie Skojarz podsieć wybierz sieć wirtualną, w której został utworzony klaster. I podsieć, której użyto dla klastra usługi HDInsight.

4. Wybierz przycisk OK.

Ruch w węzłach brzegowych lub ruch aplikacji dostosowanych do indywidualnych wymagań

Powyższe kroki umożliwią działanie klastra bez problemów. Nadal musisz skonfigurować zależności, aby uwzględnić niestandardowe aplikacje uruchomione w węzłach brzegowych, jeśli ma to zastosowanie.

Zależności aplikacji muszą być identyfikowane i dodawane do usługi Azure Firewall lub tabeli tras.

Aby uniknąć problemów z routingiem asymetrycznym, należy utworzyć trasy dla ruchu aplikacji.

Jeśli aplikacje mają inne zależności, należy je dodać do usługi Azure Firewall. Utwórz reguły aplikacji, aby umożliwić ruch HTTP/HTTPS oraz reguły sieci dla całej reszty.

Rejestrowanie i skalowanie

Usługa Azure Firewall może wysyłać dzienniki do kilku różnych systemów magazynowania. Aby uzyskać instrukcje dotyczące konfigurowania rejestrowania dla zapory, wykonaj kroki opisane w artykule Samouczek: Monitorowanie dzienników i metryk usługi Azure Firewall.

Po zakończeniu konfiguracji rejestrowania, jeśli używasz usługi Log Analytics, możesz wyświetlić zablokowany ruch z zapytaniem, takim jak:

AzureDiagnostics | where msg_s contains "Deny" | where TimeGenerated >= ago(1h)

Integrowanie usługi Azure Firewall z dziennikami usługi Azure Monitor jest przydatne podczas pierwszego uruchamiania aplikacji. Szczególnie wtedy, gdy nie znasz wszystkich zależności aplikacji. Aby dowiedzieć się więcej na temat dzienników usługi Azure Monitor, zobacz Analizowanie danych dziennika w usłudze Azure Monitor

Aby dowiedzieć się więcej na temat limitów skalowania usługi Azure Firewall i zwiększenia liczby żądań, zobacz ten dokument lub zapoznaj się z często zadawanymi pytaniami.

Dostęp do klastra

Po pomyślnym skonfigurowaniu zapory możesz użyć wewnętrznego punktu końcowego (https://CLUSTERNAME-int.azurehdinsight.net), aby uzyskać dostęp do Ambari z wnętrza sieci wirtualnej.

Aby użyć publicznego punktu końcowego (https://CLUSTERNAME.azurehdinsight.net) lub punktu końcowego SSH (CLUSTERNAME-ssh.azurehdinsight.net), upewnij się, że masz odpowiednie trasy w tabeli tras i regułach sieciowej grupy zabezpieczeń, aby uniknąć problemu z routingiem asymetrycznym opisanym tutaj. W tym przypadku należy zezwolić na adres IP klienta w regułach sieciowej grupy zabezpieczeń dla ruchu przychodzącego, a także dodać go do tabeli tras zdefiniowanej przez użytkownika z następnym przeskokiem ustawionym jako internet. Jeśli routing nie jest poprawnie skonfigurowany, zostanie wyświetlony błąd przekroczenia limitu czasu.

Następne kroki

• Architektura sieci wirtualnej usługi Azure HDInsight
• Konfigurowanie wirtualnego urządzenia sieciowego