Zarządzanie zasadami sieciowymi dla kontroli bezserwerowego ruchu wychodzącego

Na tej stronie wyjaśniono, jak skonfigurować zasady sieciowe i zarządzać nimi w celu kontrolowania wychodzących połączeń sieciowych z obciążeń bezserwerowych w usłudze Azure Databricks.

Aby uzyskać informacje o kontrolce ruchu przychodzącego, zobacz Kontrolka ruchu przychodzącego oparta na kontekście.

Wymagania

• Obszar roboczy usługi Azure Databricks musi znajdować się w warstwie Premium.

• Uprawnienia do zarządzania zasadami sieciowymi są ograniczone do administratorów kont.

Uzyskiwanie dostępu do zasad sieci

Aby utworzyć, wyświetlić i zaktualizować zasady sieciowe na koncie:

1. W konsoli konta kliknij pozycję Zabezpieczenia.
2. Kliknij kartę Sieć .
3. W obszarze Zasady kliknij pozycję Kontrola dostępu przychodzącego i wychodzącego oparta na kontekście.

Tworzenie zasad sieciowych

1. Kliknij Utwórz nowe zasady sieciowe.

2. Wprowadź nazwę polityki.

3. Kliknij kartę Egress.

   Aby ustawić reguły ruchu przychodzącego, zobacz Ustawianie reguł ruchu przychodzącego.

4. Wybierz tryb dostępu do sieci:

   • Zezwalaj na dostęp do wszystkich miejsc docelowych: nieograniczony dostęp do Internetu dla ruchu wychodzącego. Jeśli wybierzesz opcję Pełny dostęp, dostęp wychodzący do Internetu pozostanie nieograniczony.
   • Ograniczony dostęp do określonych miejsc docelowych: dostęp wychodzący jest ograniczony do określonych miejsc docelowych.

Konfigurowanie zasad sieci

W poniższych krokach opisano opcjonalne ustawienia trybu dostępu z ograniczeniami.

Ustaw reguły ruchu wychodzącego

Przed ustawieniem reguł ruchu wychodzącego należy pamiętać:

• W przypadku korzystania z zasobnika S3 w magazynie metadanych, należy użyć interfejsu API REST, aby jawnie dodać zasobnik do listy dozwolonych ruchu wychodzącego, co umożliwi pomyślne uzyskanie dostępu.
• Maksymalna liczba obsługiwanych miejsc docelowych to 2500.
• Liczba nazw FQDN, które można dodać jako dozwolone domeny, jest ograniczona do 100 na zasady.

• Domeny dodane jako wpisy usługi Private Link dla programu równoważenia obciążenia są niejawnie umieszczone na liście dozwolonych w zasadach sieciowych. Usunięcie domeny lub prywatnego punktu końcowego może skutkować tym, że pełne wymuszenie zmiany przez polityki sieciowe zajmie do 24 godzin. Zobacz Konfigurowanie łączności prywatnej z zasobami w sieci wirtualnej.
• Zasobniki Delta Sharing są automatycznie umieszczone na białej liście w zasadach sieciowych.

1. Aby udzielić bezserwerowego dostępu obliczeniowego do dodatkowych domen, kliknij Dodaj cel powyżej listy dozwolonych domen.

   

   Filtr FQDN umożliwia dostęp do wszystkich domen, które współużytkujące ten sam adres IP. Obsługa modelu aprowizowana w punktach końcowych uniemożliwia dostęp do Internetu, gdy dostęp do sieci jest ustawiony na ograniczony. Jednak szczegółowa kontrola z filtrowaniem opartym na FQDN nie jest obsługiwana.

2. Aby zezwolić obszarowi roboczemu na dostęp do dodatkowych kont usługi Azure Storage, kliknij przycisk Dodaj lokalizację docelową nad listą Dozwolone miejsca docelowe magazynu .

   

Wymuszanie zasad

Tryb uruchamiania suchego umożliwia przetestowanie konfiguracji zasad i monitorowanie połączeń wychodzących bez zakłócania dostępu do zasobów. Po włączeniu trybu suchego uruchomienia żądania naruszające zasady są rejestrowane, ale nie są blokowane. Możesz wybrać spośród następujących opcji:

1. Databricks SQL: Magazyny SQL Databricks działają w trybie testowym.

2. Obsługa modeli AI: Punkty końcowe obsługujące model działają w trybie testowym.

3. Wszystkie produkty: Wszystkie usługi Azure Databricks działają w trybie testowym, zastępując wszystkie inne opcje.

   

Aktualizowanie zasad domyślnych

Każde konto usługi Azure Databricks zawiera domyślne zasady. Domyślne zasady są skojarzone ze wszystkimi obszarami roboczymi bez jawnego przypisania zasad sieciowych, w tym nowo utworzonych obszarów roboczych. Te zasady można modyfikować, ale nie można ich usunąć.

Domyślne zasady są stosowane tylko do przestrzeni roboczych, które mają co najmniej poziom Premium.

Kojarzenie zasad sieciowych z obszarami roboczymi

Jeśli zasady domyślne zostały zaktualizowane przy użyciu dodatkowych konfiguracji, są one automatycznie stosowane do obszarów roboczych, które nie mają istniejących zasad sieciowych.

Obszar roboczy musi znajdować się w warstwie Premium.

Aby skojarzyć obszar roboczy z innymi zasadami, wykonaj następujące czynności:

1. Wybierz obszar roboczy.
2. W Polityka sieciowakliknij Aktualizuj zasady sieciowe.
3. Wybierz odpowiednie zasady sieciowe z listy.
4. Kliknij pozycję Zastosuj zasady.

Stosowanie zmian zasad sieciowych

Większość aktualizacji konfiguracji sieci jest automatycznie propagowana do bezserwerowego środowiska obliczeniowego w ciągu dziesięciu minut. Obejmuje to:

• Dodawanie nowej zewnętrznej lokalizacji lub połączenia w Unity Catalog.
• Podłączanie obszaru roboczego do innego magazynu metadanych.
• Zmiana dozwolonych miejsc docelowych magazynu lub Internetu.

Ponowne uruchamianie lub ponowne wdrażanie obciążeń bezserwerowych

Należy zaktualizować tylko podczas przełączania trybu dostępu do Internetu lub podczas aktualizowania trybu suchego uruchamiania.

Aby określić odpowiednią procedurę ponownego uruchamiania, zapoznaj się z następującą listą według produktu:

• Databricks ML Serving: Ponownie wdrażaj swój punkt końcowy obsługi uczenia maszynowego. Zobacz Tworzenie niestandardowych punktów końcowych do obsługi modeli
• Potoki: Zatrzymaj, a następnie uruchom ponownie działające potoki deklaratywne Lakeflow Spark. Zobacz Uruchom aktualizację potoku.
• Bezserwerowy magazyn SQL: zatrzymaj i uruchom ponownie magazyn SQL. Zobacz Zarządzanie usługą SQL Warehouse.
• Lakeflow Jobs: zmiany zasad sieciowych są automatycznie stosowane po uruchomieniu nowej pracy lub ponownym uruchomieniu istniejącej pracy.
• Notatniki:
  • Jeśli notes nie wchodzi w interakcję z platformą Spark, możesz zakończyć, a następnie ponownie podłączyć bezserwerowe zasoby obliczeniowe w celu odświeżenia zasad sieciowych.
  • Jeśli notes współdziała z platformą Spark, zasób bezserwerowy odświeża się i automatycznie wykrywa zmianę. Większość zmian zostanie odświeżona w ciągu dziesięciu minut, ale przełączanie trybów dostępu do Internetu, aktualizowanie trybu suchego uruchamiania lub zmiana między dołączonymi zasadami, które mają różne typy wymuszania, może potrwać do 24 godzin. Aby przyspieszyć odświeżanie tych konkretnych typów zmian, wyłącz wszystkie skojarzone notesy i zadania.

Zależności interfejsu użytkownika pakietów zasobów usługi Databricks

W przypadku korzystania z trybu ograniczonego dostępu z bezserwerową kontrolą ruchu wychodzącego funkcje interfejsu użytkownika pakiety zasobów Databricks wymagają dostępu do określonych domen zewnętrznych. Jeśli dostęp wychodzący jest całkowicie ograniczony, użytkownicy mogą zobaczyć błędy w interfejsie obszaru roboczego podczas korzystania z pakietów zasobów Databricks.

Aby funkcje interfejsu użytkownika pakietu zasobów usługi Databricks działały z restrykcyjnymi zasadami sieci, dodaj te domeny do sekcji Dozwolone domeny w twojej polityce:

• github.com
• objects.githubusercontent.com
• release-assets.githubusercontent.com
• checkpoint-api.hashicorp.com
• releases.hashicorp.com
• registry.terraform.io

Weryfikowanie wymuszania zasad sieciowych

Możesz sprawdzić, czy polityka sieciowa jest prawidłowo egzekwowana, poprzez próbę dostępu do ograniczonych zasobów z różnych obciążeń bezserwerowych. Proces weryfikacji różni się w zależności od produktu bezserwerowego.

Weryfikacja za pomocą potoków deklaratywnych Spark w Lakeflow

1. Utwórz notebook Pythona. Możesz użyć przykładowego notesu udostępnionego w wikipedia python tutorial Lakeflow Spark Declarative Pipelines.
2. Utwórz potok:
   1. W obszarze roboczym kliknij Zadania i rury na pasku bocznym.
   2. Kliknij Utwórz, a następnie ETL Pipeline.
   3. Skonfiguruj potok danych przy użyciu następujących ustawień:
      • Tryb Przetwarzania: bezserwerowy
      • Kod Źródłowy: Wybierz notatnik, który utworzyłeś.
      • pl-PL: Opcje przechowywania: Katalog Unity. Wybierz żądany wykaz i schemat.
   4. Kliknij pozycję Utwórz.
3. Uruchom potok przetwarzania.
4. Na stronie rury danych kliknij przycisk Start.
5. Poczekaj na zakończenie przetwarzania.
6. Weryfikowanie wyników
   • Zaufane miejsce docelowe: potok działa pomyślnie i zapisuje dane w miejscu docelowym.
   • Niezaufane miejsce docelowe: rura kończy się niepowodzeniem, a błędy wskazują, że dostęp do sieci jest zablokowany.

Weryfikowanie przy użyciu usługi Databricks SQL

1. Utwórz usługę SQL Warehouse.

2. Uruchom zapytanie testowe w edytorze SQL, które próbuje uzyskać dostęp do zasobu kontrolowanego przez zasady sieciowe.

3. Sprawdź wyniki:

   • Zaufane miejsce docelowe: Zapytanie powiodło się.
   • Niezaufane miejsce docelowe: zapytanie kończy się niepowodzeniem z powodu błędu dostępu do sieci.

4. Aby nawiązać połączenie z siecią z funkcji zdefiniowanej przez użytkownika przy użyciu standardowej biblioteki języka Python, uruchom następującą definicję funkcji zdefiniowanej przez użytkownika:

   CREATE OR REPLACE TEMPORARY FUNCTION ping_google(value DOUBLE)
   RETURNS STRING
   LANGUAGE python
   AS $$
   import requests
   
   url = "https://www.google.com"
   response = requests.get(url, timeout=5)
   
   if response.status_code == 200:
      return "UDF has network!"
   else:
    return "UDF has no network!"
   $$;
   

Weryfikowanie przy użyciu obsługi modelu

Zanim rozpoczniesz

Po utworzeniu punktu końcowego obsługującego model obraz kontenera jest kompilowany w celu obsługi modelu. Zasady sieci są wymuszane na tym etapie procesu budowania. W przypadku używania modelu obsługującego zasady sieciowe należy wziąć pod uwagę następujące kwestie:

• Dostęp do zależności: Wszelkie zewnętrzne zależności kompilacji, takie jak pakiety Python z PyPI i conda-forge, obrazy bazowe kontenerów czy pliki z zewnętrznych adresów URL określone w środowisku modelu lub kontekście Docker, które są wymagane przez środowisko modelu, muszą zostać dopuszczone przez politykę sieciową.

  • Jeśli na przykład model wymaga określonej wersji biblioteki scikit-learn, która musi zostać pobrana podczas kompilacji, zasady sieciowe muszą zezwolić na dostęp do repozytorium hostujące pakiet.

• Błędy kompilacji: Jeśli zasady sieciowe blokują dostęp do niezbędnych zależności, kompilacja kontenera obsługującego model zakończy się niepowodzeniem. Zapobiega to pomyślnemu wdrożeniu punktu końcowego, co może spowodować problemy z magazynowaniem lub poprawnym działaniem.

  Zobacz Sprawdź dzienniki odmów.

• Rozwiązywanie problemów z odmową: W fazie kompilacji są rejestrowane odmowy dostępu do sieci. Te dzienniki zawierają network_source_type pole o wartości ML Build. Te informacje mają kluczowe znaczenie dla identyfikowania określonych zablokowanych zasobów, które należy dodać do zasad sieci, aby umożliwić pomyślne ukończenie kompilacji.

Weryfikowanie dostępu do sieci środowiska uruchomieniowego

W poniższych krokach pokazano, jak zweryfikować zasady sieciowe dla wdrożonego modelu w czasie wykonywania, w szczególności w przypadku prób uzyskania dostępu do zasobów zewnętrznych podczas wnioskowania. Przyjęto założenie, że kontener obsługujący model został pomyślnie skompilowany, co oznacza, że wszystkie zależności czasu kompilacji były dozwolone w zasadach sieciowych.

1. Tworzenie modelu testowego

   1. W notesie języka Python utwórz model, który próbuje uzyskać dostęp do publicznego zasobu internetowego w czasie wnioskowania, na przykład podczas pobierania pliku lub tworzenia żądania interfejsu API.

   2. Uruchom ten notes, aby wygenerować model w obszarze roboczym testowym. Na przykład:

      import mlflow
      import mlflow.pyfunc
      import mlflow.sklearn
      import requests
      
      class DummyModel(mlflow.pyfunc.PythonModel):
          def load_context(self, context):
              # This method is called when the model is loaded by the serving environment.
              # No network access here in this example, but could be a place for it.
              pass
      
          def predict(self, _, model_input):
              # This method is called at inference time.
              first_row = model_input.iloc[0]
              try:
                  # Attempting network access during prediction
                  response = requests.get(first_row['host'])
              except requests.exceptions.RequestException as e:
                  # Return the error details as text
                  return f"Error: An error occurred - {e}"
              return [response.status_code]
      
      with mlflow.start_run(run_name='internet-access-model'):
          wrappedModel = DummyModel()
      
          # When this model is deployed to a serving endpoint,
          # the environment will be built. If this environment
          # itself (e.g., specified conda_env or python_env)
          # requires packages from the internet, the build-time SEG policy applies.
          mlflow.pyfunc.log_model(
              artifact_path="internet_access_ml_model",
              python_model=wrappedModel,
              registered_model_name="internet-http-access"
          )
      

2. Tworzenie punktu końcowego obsługującego

   1. W menu nawigacji przestrzeni roboczej wybierz AI/ML.

   2. Kliknij kartę Podawanie.

   3. Kliknij Utwórz punkt końcowy obsługujący.

   4. Skonfiguruj punkt końcowy przy użyciu następujących ustawień:

      • Nazwa punktu końcowego obsługi: podaj opisową nazwę.
      • Szczegóły jednostki: wybierz Model rejestru.
      • Model: wybierz model utworzony w poprzednim kroku (internet-http-access).

   5. Kliknij przycisk Potwierdź. Na tym etapie rozpoczyna się proces tworzenia kontenera do obsługi modelu. Zasady sieci dla ML Build zostaną wymuszone. Jeśli kompilacja zakończy się niepowodzeniem z powodu zablokowanego dostępu do sieci dla zależności, punkt końcowy nie stanie się gotowy.

   6. Poczekaj, aż punkt końcowy obsługujący osiągnie stan Gotowe . Jeśli nie będzie przygotowany, sprawdź logi odrzuceń dla wpisów network_source_type: ML Build.

      Zobacz Sprawdź dzienniki odmów.

3. Wykonaj zapytanie dotyczące punktu końcowego.

   1. Użyj opcji Punkt końcowy zapytania na stronie obsługującego punkt końcowy, aby wysłać żądanie testowe.

      { "dataframe_records": [{ "host": "[https://www.google.com](https://www.google.com)" }] }
      

4. Zweryfikuj efekt dostępu w czasie wykonywania:

   • Dostęp do Internetu włączony w czasie wykonywania: zapytanie kończy się powodzeniem i zwraca kod stanu, taki jak 200.
   • Dostęp do Internetu ograniczony w czasie wykonywania: zapytanie kończy się niepowodzeniem z powodu błędu dostępu do sieci, takiego jak komunikat o błędzie z try-except bloku w kodzie modelu, wskazujący przekroczenie limitu czasu połączenia lub niepowodzenie rozpoznawania hosta.

Aktualizowanie zasad sieciowych

Zasady sieciowe można zaktualizować w dowolnym momencie po jego utworzeniu. Aby zaktualizować zasady sieciowe:

1. Na stronie szczegółów zasad sieciowych w konsoli kont zmodyfikuj zasady:
   • Zmień tryb dostępu do sieci.
   • Włącz lub wyłącz tryb testowy dla wybranych usług.
   • Dodaj lub usuń FQDN lub lokalizacje magazynowania.
2. Kliknij Aktualizacji.
3. Zapoznaj się z Zastosowanie zmian zasad sieciowych, aby upewnić się, że aktualizacje zostały zastosowane do istniejących obciążeń.

Sprawdzanie dzienników odmowy

Dzienniki odmowy są przechowywane w tabeli system.access.outbound_network w Unity Catalog. Te dzienniki śledzą, kiedy żądania sieci wychodzące są odrzucane. Aby uzyskać dostęp do logów odmów, sprawdź, czy schemat dostępu jest włączony w magazynie metadanych Unity Catalog. Patrz Włączanie tabel systemowych.

Użyj zapytania SQL, takiego jak poniższe, aby wyświetlić zdarzenia odmowy. Jeśli dzienniki symulacji są włączone, zapytanie zwraca zarówno dzienniki odmowy, jak i dzienniki symulacji, które można odróżnić przy użyciu kolumny access_type. Dzienniki odmowy mają wartość DROP, natomiast w dziennikach symulacji widnieje DRY_RUN_DENIAL.

Poniższy przykład pobiera dzienniki z ostatnich 2 godzin:

SELECT *
FROM system.access.outbound_network
WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
ORDER BY event_time DESC;

W przypadku trybu testowego i zewnętrznych modeli generatywnych sztucznej inteligencji, prawdziwe jest następujące twierdzenie:

• Jeśli zasady sieciowe zablokowały dostęp do niezbędnych zależności, najpierw sprawdź dzienniki odmowy w programie system.access.outbound_network. Ponadto dzienniki kompilacji dla kontenera obsługującego model mogą zawierać przydatne informacje o tym, które domeny zostały zablokowane.
• Jeśli kompilacja kontenera obsługującego model zakończy się niepowodzeniem, sprawdź dzienniki odmowy w usłudze system.access.outbound_network aby określić, które domeny zostały zablokowane.
• Wymuszanie dostępu do modelu zewnętrznego za pośrednictwem Mosaic AI Serving nadal odbywa się nawet w trybie testowym.

Ograniczenia

• pl-PL: Rozmiar przekazywania artefaktów: w przypadku korzystania z wewnętrznego systemu plików Databricks MLflow w formacie dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> przesyłanie artefaktów jest ograniczone do 5 GB dla API log_artifact, log_artifacts oraz log_model.
• Serwowanie modelu: kontrola ruchu wychodzącego nie ma zastosowania podczas tworzenia obrazów do serwowania modelu.
• Dostarczenie dzienników odmowy dla krótkotrwałych obciążeń z odśmiecania pamięci (GC): dzienniki odmowy z krótkotrwałych obciążeń GC, które trwają krócej niż 120 sekund, mogą nie zostać dostarczone przed zakończeniem działania węzła z powodu opóźnień związanych z rejestrowaniem. Mimo że dostęp jest nadal wymuszany, może brakować odpowiedniego wpisu dziennika.
• Łączność sieciowa dla funkcji zdefiniowanych przez użytkownika (UDF) usługi Databricks SQL: aby włączyć dostęp sieciowy na platformie Databricks SQL, skontaktuj się z zespołem ds. kont Databricks.

• Rejestrowanie eventhooków potoku: deklaratywne potoki Lakeflow Spark, których eventhooki są skierowane do innego obszaru roboczego, nie są rejestrowane. Dotyczy to aplikacji Eventhooks skonfigurowanych zarówno dla obszarów roboczych między regionami, jak i obszarów roboczych w tym samym regionie.
• Zmiany powiązań obszaru roboczego Unity Catalog: Zmiany w powiązaniach obszaru roboczego Unity Catalog mogą zacząć działać dopiero po 24 godzinach. Aby przyspieszyć ten proces, dodaj kubełek pamięci do polityki sieciowej. Zobacz Ograniczanie dostępu katalogu do określonych obszarów roboczych.

• Dostęp do sieci w chmurach: obszary robocze Azure, które korzystają z zasobników S3 używanych do lokalizacji zewnętrznych Unity Catalog, nie są obecnie dozwolone przez zasady sieciowe bezserwerowe.

Dalsze kroki

• Konfigurowanie kontroli ruchu przychodzącego opartego na kontekście: zdefiniuj zasady dostępu przychodzącego na podstawie tożsamości, typu żądania i źródła sieci w celu zabezpieczenia dostępu do obszaru roboczego. Zobacz Kontrola dostępu oparta na kontekście.
• Zarządzanie regułami prywatnych punktów końcowych: kontroluj ruch sieciowy do i z prywatnych punktów końcowych, definiując określone reguły zezwalające na połączenia lub odmawiające im zwiększonych zabezpieczeń. Zobacz Zarządzanie regułami prywatnego punktu końcowego.
• Skonfiguruj zaporę dla bezserwerowego dostępu obliczeniowego: zaimplementuj zaporę, aby ograniczyć i zabezpieczyć połączenia sieciowe przychodzące i wychodzące dla bezserwerowych środowisk obliczeniowych. Zobacz Konfigurowanie zapory na potrzeby bezserwerowego dostępu obliczeniowego.
• Omówienie kosztów transferu danych i łączności: dowiedz się więcej o wpływach kosztów podczas implementowania mechanizmów kontroli zabezpieczeń sieci i łączności prywatnej na potrzeby obciążeń bezserwerowych. Zobacz Omówienie kosztów sieci bezserwerowych usługi Databricks.