Netwerkbeleid beheren voor serverless egress control

Op deze pagina wordt uitgelegd hoe u netwerkbeleid configureert en beheert om uitgaande netwerkverbindingen van uw serverloze workloads in Azure Databricks te beheren.

Zie Op context gebaseerde toegangsbescherming.

Vereisten

• Uw Azure Databricks-werkruimte moet zich in de Premium-laag bevinden.

• Machtigingen voor het beheren van netwerkbeleid zijn beperkt tot accountbeheerders.

Toegang tot netwerkbeleid

Netwerkbeleid in uw account maken, weergeven en bijwerken:

1. Klik in de accountconsole op Beveiliging.
2. Klik op het tabblad Netwerken .
3. Klik onder Beleid op contextgebaseerde controle voor inkomend en uitgaand verkeer.

Een netwerkbeleid maken

1. Klik op Nieuw netwerkbeleid maken.

2. Voer een beleidsnaam in.

3. Klik op het tabblad Uitgaand.

   Zie Ingangsregels instellen om de ingangsregels in te stellen.

4. Kies een netwerktoegangsmodus:

   • Toegang tot alle bestemmingen toestaan: onbeperkte uitgaande internettoegang. Als u Volledige toegang kiest, blijft uitgaande internettoegang onbeperkt.
   • Beperkte toegang tot specifieke bestemmingen: uitgaande toegang is beperkt tot opgegeven bestemmingen.

Netwerkbeleid configureren

In de volgende stappen worden optionele instellingen voor de modus voor beperkte toegang beschreven.

Uitgaande regels instellen

Voordat u uitgaande regels instelt, moet u het volgende in overweging nemen:

• Wanneer u een S3-bucket in uw metastore gebruikt, moet u de REST API gebruiken om de bucket expliciet toe te voegen aan uw uitgaande acceptatielijst voor toegang.
• Het maximum aantal ondersteunde bestemmingen is 2500.
• Het aantal FQDN's dat als toegestane domeinen kan worden toegevoegd, is beperkt tot 100 per beleid.

• Domeinen die zijn toegevoegd als Private Link-vermeldingen voor een load balancer, worden impliciet toegestaan in netwerkbeleid. Wanneer een domein wordt verwijderd of het privé-eindpunt wordt verwijderd, kan het tot 24 uur duren voordat netwerkbeleidsbesturingselementen de wijziging volledig afdwingen. Zie Privéconnectiviteit configureren voor resources in uw VNet.

1. Als u uw serverloze rekenkracht toegang wilt verlenen tot extra domeinen, klikt u op Doel toevoegen boven de lijst Toegestane domeinen.

   

   Het FQDN-filter biedt toegang tot alle domeinen die hetzelfde IP-adres delen. Modelbediening via geprovisioneerde eindpunten voorkomt internettoegang wanneer netwerktoegang is ingesteld op beperkt. Gedetailleerde controle met FQDN-filtering wordt echter niet ondersteund.

2. Als u uw werkruimte toegang wilt geven tot extra Azure-opslagaccounts, klikt u op de knop Bestemming toevoegen boven de lijst toegestane opslagbestemmingen .

   

Afdwingen van beleid

Met de modus Drooguitvoering kunt u uw beleidsconfiguratie testen en uitgaande verbindingen bewaken zonder de toegang tot resources te verstoren. Wanneer de modus voor droge uitvoering is ingeschakeld, worden aanvragen die in strijd zijn met het beleid geregistreerd, maar niet geblokkeerd. U kunt uit de volgende opties selecteren:

1. Databricks SQL: Databricks SQL-warehouses werken in de modus voor droge uitvoering.

2. AI-modeluitvoer: Endpoints voor modeluitvoer werken in dry-runmodus.

3. Alle producten: Alle Azure Databricks-services worden uitgevoerd in de dry-run modus, waardoor alle andere selecties worden overschreven.

   

Het standaardbeleid bijwerken

Elk Azure Databricks-account bevat een standaardbeleid. Het standaardbeleid is gekoppeld aan alle werkruimten zonder expliciete toewijzing van netwerkbeleid, inclusief zojuist gemaakte werkruimten. U kunt dit beleid wijzigen, maar het kan niet worden verwijderd.

Standaardbeleidsregels worden alleen toegepast op werkruimten met ten minste de Premium-laag.

Een netwerkbeleid koppelen aan werkruimten

Als u uw standaardbeleid hebt bijgewerkt met aanvullende configuraties, worden deze automatisch toegepast op werkruimten die geen bestaand netwerkbeleid hebben.

Uw werkruimte moet zich in de Premium-laag bevinden.

Ga als volgt te werk om uw werkruimte te koppelen aan een ander beleid:

1. Selecteer een werkruimte.
2. Klik in Netwerkbeleidop Netwerkbeleid bijwerken.
3. Selecteer het gewenste netwerkbeleid in de lijst.
4. Klik op Beleid toepassen.

Wijzigingen in netwerkbeleid toepassen

De meeste netwerkconfiguratie-updates worden in tien minuten automatisch doorgegeven aan uw serverloze berekening. Dit zijn onder andere de nieuwe mogelijkheden:

• Een nieuwe externe locatie of verbinding voor Unity Catalog toevoegen.
• Uw werkruimte koppelen aan een andere metastore.
• De toegestane opslag- of internetbestemmingen wijzigen.

Serverloze workloads opnieuw starten of opnieuw implementeren

U hoeft alleen bij te werken bij het schakelen tussen de internetverbindingsmodus of bij het bijwerken van de modus voor droge uitvoering.

Raadpleeg de volgende lijst per product om de juiste procedure voor opnieuw opstarten te bepalen:

• Databricks ML-server: implementeer uw ML-servereindpunt opnieuw. Zie Aangepaste modellen maken voor eindpunten
• Pijplijnen: stop en start de actieve Lakeflow-declaratieve pijplijnen opnieuw op. Zie Een update uitvoeren in Lakeflow Declarative Pipelines.
• serverloze SQL Warehouse-: stop en start het SQL-warehouse opnieuw. Zie Een SQL-warehouse beheren.
• Lakeflow-taken: wijzigingen in het netwerkbeleid worden automatisch toegepast wanneer een nieuwe taakuitvoering wordt geactiveerd of een bestaande taakuitvoering opnieuw wordt gestart.
• Notebooks:
  • Als uw notebook niet communiceert met Spark, kunt u de serverloze compute-eenheid beëindigen en vervolgens opnieuw koppelen om het netwerkbeleid te vernieuwen.
  • Als uw notebook communiceert met Spark, wordt de serverloze resource vernieuwd en wordt de wijziging automatisch gedetecteerd. De meeste wijzigingen worden over tien minuten vernieuwd, maar het schakelen tussen internettoegangsmodi, het bijwerken van de modus voor droge uitvoering of het wijzigen tussen gekoppelde beleidsregels met verschillende afdwingingstypen kan tot 24 uur duren. Als u een vernieuwing van deze specifieke typen wijzigingen wilt versnellen, schakelt u alle bijbehorende notitieblokken en taken uit.

Afhankelijkheden van de gebruikersinterface van Databricks Asset Bundles

Wanneer u de beperkte toegangsmodus gebruikt met serverloos uitgaande verkeerscontrole, hebben de gebruikersinterfacefuncties van Databricks Asset Bundles toegang nodig tot specifieke externe domeinen. Als uitgaande toegang volledig is beperkt, kunnen gebruikers fouten zien in de werkruimte-interface bij het werken met Databricks Asset Bundles.

Als u wilt dat de gebruikersinterfacefuncties van Databricks Asset Bundles werken met een beperkt netwerkbeleid, voegt u deze domeinen toe aan de toegestane domeinen in uw beleid:

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

Controleer de handhaving van het netwerkbeleid

U kunt controleren of uw netwerkbeleid correct wordt afgedwongen door te proberen toegang te krijgen tot gerestricteerde bronnen vanuit verschillende serverloze werklasten. Het validatieproces varieert afhankelijk van het serverloze product.

Valideren met declaratieve pijplijnen van Lakeflow

1. Maak een Python-notebook. U kunt het voorbeeldnotebook gebruiken dat wordt verstrekt in de Lakeflow Declarative Pipelines Wikipedia Python-tutorial.
2. Een pijplijn maken:
   1. Klik in uw werkruimte op Taken en pijplijnen in de zijbalk.
   2. Klik op Maken en vervolgens ETL Pipeline.
   3. Configureer de pijplijn met de volgende instellingen:
      • Pijplijnmodus: serverloos
      • Broncode: selecteer het notitieblok dat u hebt gemaakt.
      • Opslagopties: Unity Catalog. Selecteer de gewenste catalogus en het gewenste schema.
   4. Klik op Create.
3. Voer de pijplijn uit.
4. Klik op de pagina Pijplijn op Start.
5. Wacht tot de pijplijn is voltooid.
6. De resultaten controleren
   • Vertrouwde bestemming: De pijplijn wordt succesvol uitgevoerd en schrijft gegevens naar de bestemming.
   • Niet-vertrouwde bestemming: de pijplijn mislukt met fouten, wat aangeeft dat de netwerktoegang is geblokkeerd.

Valideren met Databricks SQL

1. Maak een SQL Warehouse.

2. Voer een testquery uit in de SQL-editor die probeert toegang te krijgen tot een resource die wordt beheerd door uw netwerkbeleid.

3. Controleer de resultaten:

   • Vertrouwde bestemming: de query slaagt.
   • Niet-vertrouwde bestemming: de query mislukt met een netwerktoegangsfout.

4. Als u verbinding wilt maken met een netwerk vanuit een UDF met behulp van een standaard Python-bibliotheek, voert u de volgende UDF-definitie uit:

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

Valideren met modelimplementatie

Voordat u begint

Wanneer een modelserve-eindpunt wordt aangemaakt, wordt er een containerimage opgebouwd om uw model te serveren. Netwerkbeleid wordt afgedwongen tijdens deze bouwfase. Houd rekening met het volgende bij het gebruik van het model dat wordt geleverd met netwerkbeleid:

• Afhankelijkheidstoegang: Eventuele externe buildafhankelijkheden, zoals Python-pakketten van PyPI en conda-forge, basiscontainerinstallatiekopieën of bestanden van externe URL's die zijn opgegeven in de omgeving van uw model of Docker-context die vereist zijn voor de omgeving van uw model, moeten worden toegestaan door uw netwerkbeleid.

  • Als uw model bijvoorbeeld een specifieke versie van scikit-learn vereist die moet worden gedownload tijdens de build, moet het netwerkbeleid toegang verlenen tot de opslagplaats die als host fungeert voor het pakket.

• Buildfouten: Als uw netwerkbeleid de toegang tot de benodigde afhankelijkheden blokkeert, mislukt het model voor containerbuild. Dit voorkomt dat het servereindpunt correct wordt geïmplementeerd en kan ertoe leiden dat het niet correct wordt opgeslagen of functioneert.

  Zie Denial-logboeken controleren.

• Problemen met afwijzingen oplossen: Afwijzingen voor netwerktoegang tijdens de buildfase worden gelogd. Deze logboeken bevatten een network_source_type veld met de waarde ML Build. Deze informatie is van cruciaal belang voor het identificeren van de specifieke geblokkeerde resources die moeten worden toegevoegd aan uw netwerkbeleid, zodat de build kan worden voltooid.

Runtime-netwerktoegang valideren

De volgende stappen laten zien hoe u netwerkbeleid voor een geïmplementeerd model tijdens runtime valideert, met name voor pogingen om toegang te krijgen tot externe resources tijdens deductie. Hierbij wordt ervan uitgegaan dat de container voor het uitvoeren van het model succesvol is opgebouwd. Dit betekent dat eventuele bouwafhankelijkheden zijn toegestaan in het netwerkbeleid.

1. Een testmodel maken

   1. Maak in een Python-notebook een model dat probeert toegang te krijgen tot een openbare internetresource tijdens deductietijd, zoals het downloaden van een bestand of het indienen van een API-aanvraag.

   2. Voer dit notebook uit om een model te genereren in de testwerkruimte. Voorbeeld:

      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. Een service-eindpunt maken

   1. Selecteer AI/ML in de werkruimtenavigatie.

   2. Klik op het tabblad Serveren .

   3. Klik op Een servereindpunt maken.

   4. Configureer het eindpunt met de volgende instellingen:

      • Naam van het servereindpunt: geef een beschrijvende naam op.
      • Entiteitsgegevens: modelregistermodel selecteren.
      • Model: Kies het model dat u in de vorige stap (internet-http-access) hebt gemaakt.

   5. Klik op Bevestigen. In deze fase begint het proces van het bouwen van modelbedieningscontainers. Netwerkbeleid voor ML Build wordt gehandhaafd. Als de build mislukt vanwege geblokkeerde netwerktoegang voor afhankelijkheden, wordt het eindpunt niet gereed.

   6. Wacht tot het servereindpunt de status Gereed heeft bereikt. Als het niet gereed is, controleert u de denial-logboeken op network_source_type: ML Build vermeldingen.

      Zie Denial-logboeken controleren.

3. Voer een query uit op het eindpunt.

   1. Gebruik de optie Query-eindpunt op de pagina met het servereindpunt om een testaanvraag te verzenden.

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

4. Controleer het resultaat voor runtimetoegang:

   • Internettoegang ingeschakeld tijdens runtime: de query slaagt en retourneert een statuscode zoals 200.
   • Internettoegang beperkt tijdens runtime: de query mislukt met een netwerktoegangsfout, zoals het foutbericht van het try-except blok in de modelcode, waarmee een verbindingstime-out of hostoplossingsfout wordt aangegeven.

Een netwerkbeleid bijwerken

U kunt een netwerkbeleid op elk gewenst moment bijwerken nadat het is gemaakt. Een netwerkbeleid bijwerken:

1. Wijzig het beleid op de detailpagina van het netwerkbeleid in uw accountconsole:
   • Wijzig de netwerktoegangsmodus.
   • De modus voor droge uitvoering voor specifieke services in- of uitschakelen.
   • FQDN- of opslagbestemmingen toevoegen of verwijderen.
2. Klik op bijwerken.
3. Raadpleeg Wijzigingen in het netwerkbeleid toepassen om te controleren of de updates worden toegepast op bestaande workloads.

Denial-logboeken controleren

Denial-logboeken worden opgeslagen in de system.access.outbound_network tabel in Unity Catalog. Deze logboeken houden bij wanneer uitgaande netwerkaanvragen worden geweigerd. Als u toegang wilt krijgen tot denial-logboeken, controleert u of het toegangsschema is ingeschakeld in uw Unity Catalog-metastore. Zie Access-systeemtabellen.

Gebruik een SQL-query zoals hieronder om denial-gebeurtenissen weer te geven. Als dry-run-logboeken zijn ingeschakeld, retourneert de query zowel denial-logboeken als dry-run-logboeken, die u kunt onderscheiden met behulp van de kolom access_type. Denial-logboeken hebben een DROP-waarde, terwijl dry-run-logboeken DRY_RUN_DENIALweergeven.

In het volgende voorbeeld worden logboeken opgehaald uit de afgelopen 2 uur:

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

Voor dry-run-modus en externe generatieve AI-modellen is het volgende waar:

• Als uw netwerkbeleid de toegang tot de benodigde afhankelijkheden heeft geblokkeerd, controleert u eerst de denial-logboeken in system.access.outbound_network. Daarnaast kunnen de buildlogboeken voor uw modelservercontainer nuttige informatie bieden over welke domeinen zijn geblokkeerd.
• Als het model voor containerbuild mislukt, controleert u de denial-logboeken system.access.outbound_network om te bepalen welke domeinen zijn geblokkeerd.
• De handhaving van toegang tot externe modellen via Mosaic AI Serving blijft doorgaan, zelfs in de testuitvoeringsmodus.

Beperkingen

• Uploadgrootte voor artefacten: bij gebruik van het interne Databricks-bestandssysteem van MLflow met de dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> indeling, zijn artefactuploads beperkt tot 5 GB voor log_artifact, log_artifactsen log_model API's.
• Modelbediening: Uitgaande controle is niet van toepassing bij het bouwen van afbeeldingen voor modelbediening.
• Denial-logboekbezorging voor kortdurende GC-workloads (garbage collection): Denial-logboeken van kortdurende GC-workloads die minder dan 120 seconden duren, worden mogelijk niet geleverd voordat de node wordt beëindigd vanwege vertragingen in logboekregistratie. Hoewel de toegang nog steeds wordt afgedwongen, ontbreekt de bijbehorende logboekvermelding mogelijk.
• Netwerkconnectiviteit voor door de gebruiker gedefinieerde Functies (UDF's) van Databricks SQL: neem contact op met uw Databricks-accountteam om netwerktoegang in Databricks SQL in te schakelen.
• Delta delen: weergaven zijn niet automatisch toegestaan, tenzij gedeelde tabellen dezelfde opslaglocaties hebben als de afhankelijkheden van de weergave.

• Logboekregistratie van pijplijn eventhook: Eventhooks van Lakeflow Declarative Pipelines die gericht zijn op een andere werkruimte, worden niet gelogd. Dit geldt voor Eventhooks die zijn geconfigureerd voor werkruimten tussen regio's en werkruimten in dezelfde regio.

• Netwerktoegang tussen clouds: Azure-werkruimten die gebruikmaken van S3-buckets die worden gebruikt voor externe locaties van Unity Catalog, zijn momenteel niet toegestaan door serverloos netwerkbeleid.

Wat is de volgende stap?

• Toegangsbeheer op basis van context configureren: definieer inkomend toegangsbeleid op basis van identiteit, aanvraagtype en netwerkbron om de toegang tot de werkruimte te beveiligen. Zie toegangsbeheer op basis van context.
• Regels voor privé-eindpunten beheren: beheer netwerkverkeer van en naar uw privé-eindpunten door specifieke regels te definiëren waarmee verbindingen voor verbeterde beveiliging worden toe- of geweigerd. Zie Regels voor privé-eindpunten beheren.
• Configureer een firewall voor serverloze rekentoegang: Implementeer een firewall om binnenkomende en uitgaande netwerkverbindingen voor uw serverloze rekenomgevingen te beperken en te beveiligen. Zie Een firewall configureren voor serverloze rekentoegang.
• Meer informatie over kosten voor gegevensoverdracht en connectiviteit: meer informatie over de gevolgen van kosten bij het implementeren van netwerkbeveiligingscontroles en privéconnectiviteit voor serverloze workloads. Zie Inzicht in de serverloze netwerkkosten van Databricks.