Hantera nätverksprinciper för serverlös utgående kontroll

Den här sidan beskriver hur du konfigurerar och hanterar nätverksprinciper för att styra utgående nätverksanslutningar från dina serverlösa arbetsbelastningar i Azure Databricks.

Information om ingresskontroll finns i Sammanhangsbaserad ingresskontroll.

Krav

• Din Azure Databricks-arbetsyta måste vara på Premium-nivån.

• Behörigheter för att hantera nätverksprinciper är begränsade till kontoadministratörer.

Åtkomst till nätverksprinciper

Skapa, visa och uppdatera nätverksprinciper i ditt konto:

1. I kontokonsolen klickar du på Säkerhet.
2. Klicka på fliken Nätverk .
3. Under Principer klickar du på Kontextbaserad ingress- och utgående kontroll.

Skapa en nätverksprincip

1. Klicka på Skapa ny nätverksprincip.

2. Ange ett principnamn.

3. Klicka på fliken Egress.

   Information om hur du anger ingressregler finns i Ange ingressregler.

4. Välj ett nätverksåtkomstläge:

   • Tillåt åtkomst till alla mål: Obegränsad utgående internetåtkomst. Om du väljer Fullständig åtkomst förblir utgående Internetåtkomst obegränsad.
   • Begränsad åtkomst till specifika mål: Utgående åtkomst är begränsad till angivna mål.

Konfigurera nätverksprinciper

Följande steg beskriver valfria inställningar för begränsat åtkomstläge.

Ange utgående regler

Notera innan du ställer in utgående regler:

• När du använder en S3-bucket i metaarkivet måste du använda REST-API :et för att uttryckligen lägga till bucketen i listan över tillåtna utgående objekt för att åtkomsten ska lyckas.
• Det maximala antalet mål som stöds är 2 500.
• Antalet FQDN:er som kan läggas till som tillåtna domäner är begränsat till 100 per princip.

• Domäner som läggs till som Private Link-poster för en lastbalanserare tillåts implicit i nätverksprinciper. När en domän tas bort eller den privata slutpunkten tas bort kan det ta upp till 24 timmar för nätverksprincipkontroller att helt framtvinga ändringen. Se Konfigurera privat anslutning till resurser i ditt virtuella nätverk.

1. Om du vill ge din serverlösa beräkningsåtkomst till ytterligare domäner klickar du på Lägg till mål ovanför listan Tillåtna domäner.

   

   FQDN-filtret ger åtkomst till alla domäner som delar samma IP-adress. Modellservering genom slutpunkter förhindrar internetåtkomst när nätverksåtkomsten är inställd på begränsad. Detaljerad kontroll med FQDN-filtrering stöds dock inte.

2. Om du vill tillåta att din arbetsyta får åtkomst till ytterligare Azure Storage-konton klickar du på knappen Lägg till mål ovanför listan Tillåtna lagringsmål .

   

Policyns efterlevnad

Med läget För torrkörning kan du testa din principkonfiguration och övervaka utgående anslutningar utan att störa åtkomsten till resurser. När läget för torrkörning är aktiverat loggas begäranden som bryter mot principen men blockeras inte. Du kan välja bland följande alternativ:

1. Databricks SQL: Databricks SQL-lager fungerar i torrkörningsläge.

2. AI-modellservering: Modellserverslutpunkter fungerar i torrkörningsläge.

3. Alla produkter: Alla Azure Databricks-tjänster fungerar i torrt körningsläge och åsidosätter alla andra val.

   

Uppdatera standardprincipen

Varje Azure Databricks-konto innehåller en standardprincip. Den standardprincipen är associerad med alla arbetsytor utan explicit tilldelning av nätverksprinciper, inklusive nyligen skapade arbetsytor. Du kan ändra den här principen, men den kan inte tas bort.

Standardprinciper tillämpas endast på arbetsytor med minst Premium-nivå.

Associera en nätverkspolicy med arbetsytor

Om du har uppdaterat standardprincipen med ytterligare konfigurationer tillämpas de automatiskt på arbetsytor som inte har någon befintlig nätverksprincip.

Din arbetsyta måste vara på Premium-nivå.

Om du vill associera din arbetsyta med en annan princip gör du följande:

1. Välj en arbetsyta.
2. I Nätverksprincipklickar du på Uppdatera nätverksprincip.
3. Välj önskad nätverksprincip i listan.
4. Klicka på Tillämpa princip.

Tillämpa ändringar i nätverksprinciper

De flesta uppdateringar av nätverkskonfigurationen sprids automatiskt till din serverlösa beräkning på tio minuter. Detta omfattar:

• Lägga till en ny extern plats eller anslutning för Unity Catalog.
• Anslut din arbetsyta till en annan metastore.
• Ändra tillåtna lagrings- eller Internetmål.

Starta om eller återdistribuera arbetsbelastningar utan server

Du behöver bara uppdatera när du växlar internetåtkomstläge eller när du uppdaterar läget för torrkörning.

Information om hur du fastställer lämplig omstartsprocedur finns i följande lista efter produkt:

• Databricks ML-servering: Återdistribuera din ML-tjänstslutpunkt. Se Skapa anpassade modeller för betjänande av slutpunkter
• Pipelines: Stoppa dina körande deklarativa pipelines i Lakeflow och starta sedan om dem. Se Kör en uppdatering i Lakeflow Deklarativa Pipelines.
• Serverless SQL Warehouse: Stoppa och starta om SQL-lagret. Se Hantera ett SQL-lager.
• Lakeflow-jobb: Ändringar i nätverksprinciper tillämpas automatiskt när en ny jobbkörning utlöses eller en befintlig jobbkörning startas om.
• Anteckningsböcker:
  • Om notebook-filen inte interagerar med Spark kan du avsluta och sedan återansluta den serverlösa beräkningen för att uppdatera nätverkspolicyn.
  • Om din notebook interagerar med Spark, uppdateras den serverlösa resursen och detekterar ändringen automatiskt. De flesta ändringar kommer att uppdateras på tio minuter, men det kan ta upp till 24 timmar att byta läge för internetåtkomst, uppdatera läget för torrkörning eller ändra mellan anslutna principer som har olika typer av tvingande. Om du vill påskynda en uppdatering av dessa specifika typer av ändringar inaktiverar du alla associerade notebook-filer och jobb.

Användargränssnittsberoenden för Databricks-resurspaket

När du använder begränsat åtkomstläge med serverlös utgående kontroll kräver Databricks Asset Bundles UI-funktioner åtkomst till specifika externa domäner. Om utgående åtkomst är helt begränsad kan användarna se fel i arbetsytans gränssnitt när de arbetar med Databricks Asset Bundles.

Om du vill att Databricks Asset Bundles-användargränssnittsfunktioner ska fungera med begränsade nätverksprinciper lägger du till dessa domäner i de tillåtna domänerna i din princip:

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

Verifiera efterlevnad av nätverkspolicy

Du kan kontrollera att din nätverksprincip tillämpas korrekt genom att försöka komma åt begränsade resurser från olika serverlösa arbetsbelastningar. Valideringsprocessen varierar beroende på den serverlösa produkten.

Verifiera med Lakeflow Deklarativa pipelines

1. Skapa en Python-anteckningsbok. Du kan använda exempelnotebooken som finns i wikipedia-python-självstudiekursen om deklarativa pipelines för Lakeflow.
2. Skapa en pipeline:
   1. På arbetsytan klickar du på Jobb och pipelines i sidofältet.
   2. Klicka på Skapa och ETL-pipeline.
   3. Konfigurera pipelinen med följande inställningar:
      • Pipelineläge: Serverlöst
      • Källkod: Välj den notebook som du skapade.
      • Lagringsalternativ: Unity Catalog. Välj önskad katalog och ditt schema.
   4. Klicka på Skapa.
3. Kör pipelinjen.
4. På pipelinesidan klickar du på Start.
5. Vänta tills pipelinen har slutförts.
6. Verifiera resultatet
   • Betrodd destination: Pipelinen körs framgångsrikt och skriver data till destinationen.
   • Ej betroddt mål: Pipelinen misslyckas med fel, vilket indikerar att nätverksåtkomsten är blockerad.

Verifiera med Databricks SQL

1. Skapa ett SQL-lager.

2. Kör en testfråga i SQL-redigeraren som försöker komma åt en resurs som styrs av din nätverksprincip.

3. Kontrollera resultatet:

   • Betrodd destination: Frågan lyckas.
   • Otrustad destination: Förfrågan misslyckas på grund av ett nätverksåtkomstfel.

4. Om du vill ansluta till ett nätverk från en UDF med hjälp av ett Standard Python-bibliotek kör du följande UDF-definition:

   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!"
   $$;
   

Verifiera med modellservering

Innan du börjar

När en modell som betjänar slutpunkten skapas skapas en containeravbildning för att hantera din modell. Nätverksprinciper tillämpas under den här byggfasen. Tänk på följande när du använder en modell som fungerar med nätverksprinciper:

• Beroendeåtkomst: Eventuella externa byggberoenden som Python-paket från PyPI och conda-forge, bascontaineravbildningar eller filer från externa URL:er som anges i modellens miljö eller Docker-kontext som krävs av modellens miljö måste tillåtas av din nätverksprincip.

  • Om din modell till exempel kräver en specifik version av scikit-learn som måste laddas ned under bygget, måste nätverksprincipen tillåta åtkomst till lagringsplatsen som är värd för paketet.

• Byggfel: Om din nätverksprincip blockerar åtkomsten till nödvändiga beroenden misslyckas den modell som hanterar containerbygget. Detta hindrar slutpunkten för servering från att distribueras korrekt och kan göra att den misslyckas med att lagra eller fungera korrekt.

  Se Kontrollera nekningsloggar.

• Felsökning av nekanden: Nätverksåtkomstnekelser under byggfasen loggas. De här loggarna innehåller ett network_source_type fält med värdet ML Build. Den här informationen är viktig för att identifiera de specifika blockerade resurser som måste läggas till i din nätverksprincip så att bygget kan slutföras.

Verifiera nätverksåtkomst under körning

Följande steg visar hur du validerar nätverksprinciper för en distribuerad modell vid körning, särskilt för försök att komma åt externa resurser under inferens. Detta förutsätter att den modell som betjänar containern har skapats korrekt, vilket innebär att eventuella byggtidsberoenden tilläts i nätverksprincipen.

1. Skapa en testmodell

   1. I en Python-notebook-fil skapar du en modell som försöker komma åt en offentlig Internetresurs vid slutsatsdragningstid, till exempel att ladda ned en fil eller göra en API-begäran.

   2. Kör den här notebook-filen för att generera en modell på testarbetsytan. Till exempel:

      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. Skapa en serverslutpunkt

   1. I navigeringen på arbetsytan väljer du AI/ML.

   2. Klicka på fliken Servering .

   3. Klicka på Skapa tjänstslutpunkt.

   4. Konfigurera slutpunkten med följande inställningar:

      • Serverdelsnamn: Ange ett beskrivande namn.
      • Entitetsinformation: Välj Modellregistermodell.
      • Modell: Välj den modell som du skapade i föregående steg (internet-http-access).

   5. Klicka på Bekräfta. I det här skedet börjar den modell som betjänar containerbyggprocessen. Nätverksprinciper för ML Build tillämpas. Om bygget misslyckas på grund av blockerad nätverksåtkomst för beroenden blir slutpunkten inte redo.

   6. Vänta tills tjänstslutpunkten uppnår statusen Klar. Om det inte blir klart, kontrollera nekningsloggarna för network_source_type: ML Build-poster.

      Se Kontrollera nekningsloggar.

3. Fråga slutpunkten.

   1. Använd alternativet Frågeslutpunkt på sidan serverdelsslutpunkt för att skicka en testbegäran.

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

4. Kontrollera resultatet för körningsåtkomst:

   • Internetåtkomst aktiverad vid körning: Frågan lyckas och returnerar en statuskod som 200.
   • Internetåtkomst begränsad vid körning: Frågan misslyckas med ett nätverksåtkomstfel, till exempel felmeddelandet från try-except blocket i modellkoden, vilket indikerar en tidsgräns för anslutningen eller fel vid värdmatchning.

Uppdatera en nätverkspolicy

Du kan uppdatera en nätverksprincip när som helst när den har skapats. För att uppdatera en nätverkspolicy:

1. Ändra policyn på sidan med detaljer om nätverkspolicyn i kontokonsolen.
   • Ändra nätverksåtkomstläget.
   • Aktivera eller inaktivera torrkörningsläge för specifika tjänster.
   • Lägg till eller ta bort FQDN- eller lagringsmål.
2. Klicka på Uppdatera.
3. Se Tillämpa ändringar i nätverksprinciper för att kontrollera att uppdateringarna tillämpas på befintliga arbetsbelastningar.

Kontrollera nekande loggar

Loggar för avslag lagras i tabellen system.access.outbound_network i Unity Catalog. Dessa loggar spårar när utgående nätverksbegäranden nekas. Kontrollera att åtkomstschemat är aktiverat i unity catalog-metaarkivet för att få åtkomst till denial-loggar. Se Åtkomstsystemtabeller.

Använd en SQL-fråga som den nedan för att visa överbelastningshändelser. Om torrkörningsloggar är aktiverade returnerar frågan både nekande loggar och torrkörningsloggar, som du kan särskilja med kolumnen access_type. Nekningsloggar har ett DROP-värde, medan provkörningsloggar visar DRY_RUN_DENIAL.

I följande exempel hämtas loggar från de senaste 2 timmarna:

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

För torrkörningsläge och externa generativa AI-modeller är följande sant:

• Om din nätverksprincip har blockerat åtkomsten till nödvändiga beroenden kontrollerar du först nekandeloggarna i system.access.outbound_network. Dessutom kan byggloggarna för din modell som betjänar containern ge användbar information om vilka domäner som blockerades.
• Om konstruktionen av container för modellhantering misslyckas bör du kontrollera nekningsloggarna i system.access.outbound_network för att avgöra vilka domäner som blockerades.
• Tillsyn för extern modellåtkomst via Mosaic AI Serving fortsätter även under torrkörningsläge.

Begränsningar

• Artefaktuppladdningsstorlek: När du använder MLflows interna Databricks-filsystem med dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> formatet är artefaktuppladdningar begränsade till 5 GB för log_artifact, log_artifactsoch log_model API:er.
• Modellbetjäning: Egresskontroll gäller inte när du skapar bilder för modellbetjäning.
• Leverans av nekandeloggar för kortlivade garbage collection (GC) arbetsbelastningar: Nekandeloggar från kortlivade GC-arbetsbelastningar som varar mindre än 120 sekunder kanske inte levereras innan noden avslutas på grund av loggningsfördröjningar. Även om åtkomst fortfarande tillämpas kan motsvarande loggpost saknas.
• Nätverksanslutning för databricks SQL-användardefinierade funktioner (UDF:er): Kontakta ditt Databricks-kontoteam om du vill aktivera nätverksåtkomst i Databricks SQL.
• Deltadelning: Vyer tillåts inte automatiskt om inte delade tabeller har samma lagringsplatser som vyberoendena.

• Pipeline eventhook loggning: Lakeflow Deklarativa Pipelines eventhooks som riktar sig till en annan arbetsyta loggas inte. Detta gäller eventhooks som konfigurerats för både arbetsytor mellan regioner och arbetsytor i samma region.

• Nätverksåtkomst mellan moln: Azure-arbetsytor som använder S3-bucketar som används för externa platser i Unity Catalog tillåts för närvarande inte av serverlösa nätverksprinciper.

Vad händer härnäst?

• Konfigurera kontextbaserad ingresskontroll: Definiera principer för inkommande åtkomst baserat på identitet, typ av begäran och nätverkskälla för att skydda åtkomsten till arbetsytan. Se Sammanhangsbaserad ingresskontroll.
• Hantera regler för privata slutpunkter: Kontrollera nätverkstrafik till och från dina privata slutpunkter genom att definiera specifika regler som tillåter eller nekar anslutningar för förbättrad säkerhet. Se Hantera regler för privata slutpunkter.
• Konfigurera en brandvägg för serverlös beräkningsåtkomst: Implementera en brandvägg för att begränsa och skydda inkommande och utgående nätverksanslutningar för dina serverlösa beräkningsmiljöer. Se Konfigurera en brandvägg för serverlös beräkningsåtkomst.
• Förstå kostnader för dataöverföring och anslutning: Lär dig mer om kostnadskonsekvenser när du implementerar nätverkssäkerhetskontroller och privat anslutning för serverlösa arbetsbelastningar. Se Förstå kostnader för serverlösa nätverk i Databricks.