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ą, najpierw utwórz klaster usługi 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ądzania przychodzącego przez zaporę. Tagi usługi sieciowej grupy zabezpieczeń dla ruchu przychodzącego można użyć 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.
Zabezpieczanie adresów wychodzących za pomocą zapory, która może kontrolować ruch wychodzący na podstawie nazw FQDN. Usługa Azure Firewall ogranicza ruch wychodzący na podstawie nazwy FQDN tagów docelowych lub 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:
- Utwórz podsieć.
- Utwórz zaporę.
- Dodaj reguły aplikacji do zapory.
- Dodaj reguły sieciowe do zapory.
- 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 artykule Wdrażanie zapory z samouczka: wdrażanie i konfigurowanie usługi Azure Firewall przy użyciu witryny Azure Portal.
Konfigurowanie zapory przy użyciu reguł aplikacji
Utwórz kolekcję reguł aplikacji, która umożliwia klastrowi wysyłanie i odbieranie ważnej komunikacji.
Wybierz nową zaporę Test-FW01 w witrynie Azure Portal.
Przejdź do kolekcji> reguł aplikacji Ustawienia> Rules>i dodaj kolekcję reguł aplikacji.
Na ekranie Dodawanie kolekcji reguł aplikacji podaj następujące informacje:
Górna sekcja
Właściwości Wartość Nazwisko FwAppRule Priorytet 200 Akcja Zezwalaj Sekcja tagów FQDN
Nazwisko Adres źródłowy 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 nazwy FQDN Uwagi Rule_2 * https:443 login.windows.net Zezwala na działanie logowania systemu Windows Rule_3 * https:443 login.microsoftonline.com Zezwala na działanie logowania systemu Windows Rule_4 * https:443 storage_account_name.blob.core.windows.net Zastąp storage_account_nameciąg rzeczywistą nazwą konta magazynu. Upewnij się, że opcja "Wymagany bezpieczny transfer" jest włączona na koncie magazynu. Jeśli używasz prywatnego punktu końcowego do uzyskiwania dostępu do kont magazynu, ten krok nie jest wymagany, a ruch magazynu nie jest przekazywany do zapory.Rule_5 * http:80 azure.archive.ubuntu.com Zezwala na instalowanie aktualizacji zabezpieczeń systemu Ubuntu w klastrze 
Wybierz Dodaj.
Konfigurowanie zapory przy użyciu reguł sieci
Utwórz reguły sieciowe, aby poprawnie skonfigurować klaster usługi HDInsight.
Kontynuując poprzedni krok, przejdź do obszaru Kolekcja> reguł sieci+ Dodaj kolekcję reguł sieciowych.
Na ekranie Dodawanie kolekcji reguł sieci podaj następujące informacje:
Górna sekcja
Właściwości Wartość Nazwisko FwNetRule Priorytet 200 Akcja Zezwalaj Sekcja Tagi usługi
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 nie skonfigurowano punktów końcowych usługi dla programu SQL Server w podsieci usługi HDInsight, co spowoduje obejście zapory. Jeśli używasz niestandardowego serwera SQL dla magazynów metadanych Ambari, Oozie, Ranger i Hive, wystarczy zezwolić 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łę. 
Wybierz Dodaj.
Tworzenie i konfigurowanie tabeli tras
Utwórz tabelę tras z następującymi wpisami:
Wszystkie adresy IP z usług kondycji i zarządzania z typem następnego przeskoku Internetu. Powinien zawierać 4 adresy IP regionów ogólnych, a także 2 adresy IP dla określonego regionu. Ta reguła jest wymagana tylko wtedy, gdy właściwość ResourceProvider Połączenie ion jest ustawiona na wartość Przychodzące. Jeśli parametr ResourceProvider Połączenie ion jest ustawiony na wychodzący, 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:
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.
Następnie przejdź do pozycji Wszystkie usługi>Tabele tras sieciowych>i Utwórz tabelę tras.
Z nowej trasy przejdź do pozycji Ustawienia> Routes>+ Dodaj. Dodaj następujące trasy:
| Nazwa trasy | Prefiks adresu | Typ następnego przeskoku | Adres następnego przeskoku |
|---|---|---|---|
| 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 | Urządzenie wirtualne | 10.0.2.4 |
Ukończ konfigurację tabeli tras:
Przypisz utworzoną tabelę tras do podsieci usługi HDInsight, wybierając pozycję Podsieci w obszarze Ustawienia.
Wybierz pozycję + Skojarz.
Na ekranie Kojarzenie podsieci wybierz sieć wirtualną, do której został utworzony klaster. A podsieć użyta dla klastra usługi HDInsight.
Wybierz przycisk OK.
Ruch w węzłach brzegowych lub niestandardowych aplikacjach
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 zezwolić na ruch HTTP/HTTPS i reguły sieci dla wszystkich innych elementów.
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 wiesz o wszystkich zależnościach 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 systemu Ambari z 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.