Administrar directivas de red para el control de salida sin servidor

En esta página se explica cómo configurar y administrar directivas de red para controlar las conexiones de red salientes de las cargas de trabajo sin servidor en Azure Databricks.

Para obtener el control de entrada, consulte Control de entrada basado en contexto.

Requisitos

Azure

• El área de trabajo de Azure Databricks debe estar en el nivel Premium.

Azure China

• El área de trabajo de Azure Databricks debe estar en el nivel Premium.
• El control de salida sin servidor solo se admite en la región Norte de China 3. El área de trabajo debe estar en el Norte de China 3.
• Acceda a las directivas de red desde la consola de la cuenta de Azure China en accounts.databricks.azure. cn.

• Los permisos para administrar directivas de red están restringidos a los administradores de cuentas.

Acceso a directivas de red

Para crear, ver y actualizar directivas de red en su cuenta:

1. En la consola de la cuenta, haga clic en Seguridad.
2. Haga clic en la pestaña Redes .
3. En Directivas, haga clic en Control de entrada y salida basado en contexto.

Creación de una directiva de red

1. Haga clic en Crear nueva directiva de red.

2. Escriba un nombre de directiva.

3. Haga clic en la pestaña Salida .

   Para establecer reglas de entrada, consulte Establecimiento de reglas de entrada.

4. Elija un modo de acceso a la red:

   • Permitir el acceso a todos los destinos: acceso a Internet saliente sin restricciones. Si elige Acceso total, el acceso saliente a Internet permanece sin restricciones.
   • Acceso restringido a destinos específicos: el acceso saliente está limitado a destinos especificados.

Configuración de directivas de red

En los pasos siguientes se describe la configuración opcional para el modo de acceso restringido:

• Establecimiento de reglas de salida
• Aplicación de directivas
• Bloquear destinos de Internet

Establecimiento de reglas de salida

Antes de establecer las reglas de salida, tenga en cuenta:

• Al usar un cubo S3 en el metastore, debe usar la API REST para agregar explícitamente el cubo a la lista de permitidos de salida para que el acceso se realice correctamente.
• El número máximo de destinos admitidos es 2500.
• El número de destinos de almacenamiento (allowed_storage_destinations) que se pueden agregar está limitado a 100 por directiva.
• El número de FQDN que se pueden agregar como dominios permitidos está limitado a 100 por directiva.

• Los dominios agregados como entradas de Private Link para un equilibrador de carga están permitidos implícitamente en las directivas de red. Cuando se quita un dominio o se elimina el punto de conexión privado, los controles de directivas de red pueden tardar hasta 24 horas en aplicar completamente el cambio. Consulte Configuración de la conectividad privada a los recursos de la red virtual.
• Los buckets OpenSharing están incluidos implícitamente en la lista de permitidos de las políticas de red.

1. Para conceder acceso de proceso sin servidor a dominios adicionales, haga clic en Agregar destino encima de la lista Dominios permitidos.

   

   El filtro FQDN permite el acceso a todos los dominios que comparten la misma dirección IP.

   Nota:

   Los puntos de conexión de rendimiento aprovisionados para el Modelos de servicio no admiten el filtrado granular de FQDN. Al establecer el acceso de red a restringido, se bloquea todo el acceso a Internet para estos puntos de conexión.

2. Para permitir que el área de trabajo acceda a cuentas de almacenamiento de Azure adicionales, haga clic en el botón Agregar destino encima del Todos los destinos de almacenamiento permitidos lista.

   

Aplicación de directivas

El modo de ejecución seca permite probar la configuración de la directiva y supervisar las conexiones salientes sin interrumpir el acceso a los recursos. Cuando el modo de ejecución seca está habilitado, las solicitudes que infringen la directiva se registran pero no se bloquean. Puede seleccionar entre las siguientes opciones:

1. Databricks SQL: los almacenes de SQL de Databricks funcionan en modo de ejecución seca.

2. Servicio de modelos de IA: los puntos de conexión de servicio de modelos funcionan en modo de ejecución seca.

3. Todos los productos: todos los servicios Azure Databricks funcionan en modo de ejecución seca, reemplazando todas las demás selecciones.

   

Bloquear destinos de Internet

Bloquee destinos de Internet específicos de las cargas de trabajo sin servidor. Use destinos bloqueados como alternativa ligera al modo de acceso restringido para bloquear dominios conocidos incorrectos sin cambiar el modo de cumplimiento general.

Configure destinos bloqueados mediante la API REST de directivas de red. La API requiere un token de OAuth de administrador de cuenta. Los tokens de acceso personal no se admiten para las API de nivel de cuenta.

Consulte Autenticación de máquina a máquina de OAuth.

Los destinos bloqueados se comportan de la siguiente manera:

• Cada entrada especifica un destination (un nombre de dominio completo o FQDN) y un internet_destination_type de DNS_NAME.
• No se admiten intervalos IP ni destinos de almacenamiento.
• Los destinos bloqueados siempre se aplican independientemente del modo de acceso a la red de la directiva.
• Los destinos bloqueados tienen prioridad sobre los destinos permitidos.
• La API rechaza las configuraciones en las que un destino permitido es un subdominio de un destino bloqueado. Sin embargo, se permite el patrón "permitir ampliamente, bloquear de forma estrecha" (por ejemplo, permitir example.com y bloquear api.example.com).

Las denegaciones se registran en la system.access.outbound_network tabla del catálogo de Unity incluso cuando el acceso a la red está establecido en Acceso completo. Consulte Comprobación de los registros de denegación.

Para bloquear un destino de Internet:

1. Recupere su política de red. Ejecute el siguiente comando:

   Reemplace <ACCOUNT_HOST> por accounts.azuredatabricks.net.

   curl --location --request GET \
     'https://<ACCOUNT_HOST>/api/2.0/accounts/<ACCOUNT_ID>/network-policies/<NETWORK_POLICY_ID>' \
     --header 'Authorization: Bearer <OAUTH_TOKEN>'
   

   Guarde el cuerpo de la respuesta como network-policy.json.

2. Edite network-policy.json para agregar blocked_internet_destinations en egress.network_access. En el ejemplo siguiente se bloquea un dominio único en modo de acceso completo :

   {
     "network_policy_id": "my-policy",
     "account_id": "...",
     "egress": {
       "network_access": {
         "restriction_mode": "FULL_ACCESS",
         "blocked_internet_destinations": [
           {
             "destination": "malicious-domain.example.com",
             "internet_destination_type": "DNS_NAME"
           }
         ]
       }
     }
   }
   

3. Envíe la directiva actualizada con una PUT solicitud al mismo punto de conexión mediante el siguiente comando. El PUT cuerpo debe contener la política de red completa. Los campos que omita se borran.

   curl --location --request PUT \
     'https://<ACCOUNT_HOST>/api/2.0/accounts/<ACCOUNT_ID>/network-policies/<NETWORK_POLICY_ID>' \
     --header 'Content-Type: application/json' \
     --header 'Authorization: Bearer <OAUTH_TOKEN>' \
     --data @network-policy.json
   

También puede administrar directivas de red con la CLI de Databricks mediante databricks account network-policies update-network-policy-rpco con el recurso de Terraform databricks_account_network_policy . Consulte el grupo de comandosaccount network-policies.

Actualización de la directiva predeterminada

Cada cuenta de Azure Databricks incluye una directiva default. La directiva predeterminada está asociada a todas las áreas de trabajo sin ninguna asignación de directiva de red explícita, incluidas las áreas de trabajo recién creadas. Puede modificar esta directiva, pero no se puede eliminar.

Las directivas predeterminadas solo se aplican a las áreas de trabajo con al menos el nivel Premium.

Asocia una política de red a espacios de trabajo

Si ha actualizado la directiva predeterminada con configuraciones adicionales, se aplican automáticamente a las áreas de trabajo que no tienen una directiva de red existente.

El área de trabajo debe estar en el nivel Premium.

Para asociar el área de trabajo a otra directiva, haga lo siguiente:

1. Seleccione un área de trabajo.
2. En Directiva de red, haga clic en Actualizar Directiva de red.
3. Seleccione la directiva de red deseada en la lista.
4. Haga clic en Aplicar directiva.

Aplicación de cambios en la directiva de red

La mayoría de las actualizaciones de configuración de red se propagan automáticamente a su cómputo sin servidor en diez minutos. Esto incluye:

• Agregar una nueva ubicación externa o conexión del catálogo de Unity.
• Adjunte el área de trabajo a otro metastore.
• Cambiar el almacenamiento permitido o los destinos de Internet.

Reinicio o reimplementación de cargas de trabajo sin servidor

Solo tiene que actualizar al cambiar el modo de acceso a Internet o al actualizar el modo de ejecución seca.

Para determinar el procedimiento de reinicio adecuado, consulte la siguiente lista por producto:

• Databricks ML Serving: vuelva a implementar el punto de conexión de servicio de ML. Consulte Creación de un modelo personalizado que atiende puntos de conexión
• Canalizaciones: detenga y reinicie las canalizaciones de Lakeflow en ejecución. Consulte Ejecutar una actualización de canalización.
• Almacén SQL sin servidor: Detener y reiniciar el almacén SQL. Consulte Administración de un almacenamiento de SQL.
• Trabajos de Lakeflow: los cambios de directiva de red se aplican automáticamente cuando se desencadena una nueva ejecución de trabajo o se reinicia una ejecución de trabajo existente.
• Cuadernos:
  • Si su portátil no se comunica con Spark, puede cerrar y volver a conectar el servicio deproceso sin servidor para actualizar la política de red.
  • Si el cuaderno interactúa con Spark, el recurso sin servidor se actualiza y detecta automáticamente el cambio. La mayoría de los cambios se actualizarán en diez minutos, pero cambiar los modos de acceso a Internet, actualizar el modo de ejecución seca o cambiar entre las directivas adjuntas que tienen diferentes tipos de cumplimiento pueden tardar hasta 24 horas. Para acelerar una actualización en estos tipos específicos de cambios, desactive todos los cuadernos y trabajos asociados.

La automatización declarativa agrupa las dependencias de la interfaz de usuario

Cuando se utiliza el modo de acceso restringido con control de salida sin servidor, las funciones de la interfaz de usuario de los paquetes de automatización declarativa requieren acceso a dominios externos específicos. Si el acceso saliente está completamente restringido, es posible que los usuarios vean errores en la interfaz del área de trabajo al trabajar con agrupaciones de automatización declarativa.

Para mantener las características de la interfaz de usuario de paquetes de Automatización declarativa que funcionan con directivas de red restringidas, agregue estos dominios a los dominios permitidos en la directiva:

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

Comprobación de la aplicación de directivas de red

Puede validar que la directiva de red se aplica correctamente intentando acceder a recursos restringidos de diferentes cargas de trabajo sin servidor. El proceso de validación varía en función del producto sin servidor.

Canalizaciones de Lakeflow

1. Cree un cuaderno de Python. Puedes utilizar el cuaderno de ejemplo que se proporciona en el tutorial de Python de Wikipedia sobre canalizaciones de Lakeflow.
2. Cree una canalización:
   1. En el área de trabajo, haga clic en Trabajos y canalizaciones en la barra lateral.
   2. Haga clic en Crear y, a continuación, en Canalización de ETL.
   3. Configure la canalización con los valores siguientes:
      • Modo de canalización: sin servidor
      • Código fuente: seleccione el cuaderno que creó.
      • Opciones de almacenamiento: Catálogo de Unity. Seleccione el catálogo y el esquema deseados.
   4. Haga clic en Crear.
3. Ejecución de la canalización
4. En la página de canalización, haga clic en Iniciar.
5. Espere a que se complete la canalización.
6. Comprobación de los resultados
   • Destino de confianza: la canalización se ejecuta correctamente y escribe datos en el destino.
   • Destino que no es de confianza: la canalización produce errores, lo que indica que el acceso a la red está bloqueado.

SQL Databricks

Validación con Databricks SQL

1. Cree un almacén de datos SQL.

2. Ejecute una consulta de prueba en el editor de SQL que intente acceder a un recurso controlado por la directiva de red.

3. Compruebe los resultados:

   • Destino de confianza: la consulta se realiza correctamente.
   • Destino que no es de confianza: la consulta produce un error de acceso a la red.

4. Para conectarse a una red desde una UDF mediante una biblioteca de Python estándar, ejecute la siguiente definición de UDF:

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

Servicio de modelos

Validación con el servicio de modelos

Antes de empezar

Cuando se crea un punto de conexión de servicio de modelos, se construye una imagen de contenedor para ejecutar el modelo. Las directivas de red se aplican durante esta fase de compilación. Al usar el servicio de modelos con directivas de red, tenga en cuenta lo siguiente:

• Acceso a las dependencias: Cualquier dependencia de compilación externa, como paquetes de Python de PyPI y conda-forge, imágenes de contenedor base o archivos de URL externas especificadas en el entorno de su modelo o en el contexto de Docker requerido por el entorno de su modelo, debe estar permitida por su directiva de red.
  • Por ejemplo, si el modelo requiere una versión específica de scikit-learn que debe descargarse durante la compilación, la directiva de red debe permitir el acceso al repositorio que hospeda el paquete.
• Errores de compilación: Si la directiva de red bloquea el acceso a las dependencias necesarias, se produce un error en la compilación del contenedor de servicio del modelo. Esto impide que el punto de conexión de servicio se despliegue con éxito y puede causar una falla de almacenamiento o funcionar correctamente. Consulte Comprobación de los registros de denegación.
• Solución de problemas de denegación: Las denegaciones de acceso de red durante la fase de compilación se registran. Estos registros presentan un network_source_type campo con el valor ML Build. Esta información es fundamental para identificar los recursos bloqueados específicos que se deben agregar a la directiva de red para permitir que la compilación se complete correctamente.

Validación del acceso a la red en tiempo de ejecución

En los pasos siguientes se muestra cómo validar la directiva de red para un modelo implementado en tiempo de ejecución, específicamente para los intentos de acceder a recursos externos durante la inferencia. Esto supone que el contenedor de servicio de modelos se ha compilado correctamente, lo que significa que se permitieron las dependencias en tiempo de compilación en la directiva de red.

1. Creación de un modelo de prueba

   1. En un cuaderno de Python, cree un modelo que intente acceder a un recurso de Internet público en el momento de la inferencia, como descargar un archivo o realizar una solicitud de API.

   2. Ejecute este cuaderno para generar un modelo en el área de trabajo de prueba. Por ejemplo:

      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 serverless network policy applies.
          mlflow.pyfunc.log_model(
              artifact_path="internet_access_ml_model",
              python_model=wrappedModel,
              registered_model_name="internet-http-access"
          )
      

2. Creación de un punto de conexión de servicio

   1. En la navegación del área de trabajo, seleccione AI/ML.
   2. Haga clic en la pestaña Servicio.
   3. Haga clic en Crear punto de conexión de servicio.
   4. Configure el punto de conexión con los valores siguientes:
      • Nombre del punto de conexión de servicio: proporcione un nombre descriptivo.
      • Detalles de la entidad: Seleccione Modelo del registro de modelos.
      • Modelo: elija el modelo que creó en el paso anterior (internet-http-access).
   5. Haga clic en Confirmar. En esta fase, comienza el proceso de creación del contenedor de servicio de modelos. Se aplicarán directivas de red para ML Build . Si se produce un error en la compilación debido a un acceso de red bloqueado para las dependencias, el punto de conexión no estará listo.
   6. Espere a que el punto de servicio llegue al estado de Listo. Si no llega a estar listo, compruebe los registros de denegación para las entradas de network_source_type: ML Build. Consulte Comprobación de los registros de denegación.

3. Consulte el punto de conexión.

   1. Use la opción Punto de conexión de consulta en la página de punto de conexión de servicio para enviar una solicitud de prueba.

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

4. Compruebe el resultado del acceso en tiempo de ejecución:

   • Acceso a Internet habilitado en tiempo de ejecución: la consulta se realiza correctamente y devuelve un código de estado como 200.
   • Acceso a Internet restringido en tiempo de ejecución: La consulta falla debido a un error de acceso a la red, como el mensaje de error del bloque try-except en el código del modelo, que indica un tiempo de espera de conexión o fallo en la resolución del host.

Actualización de una directiva de red

Puede actualizar una directiva de red en cualquier momento después de crearla. Para actualizar una directiva de red:

1. En la página de detalles de la directiva de red de la consola de cuentas, modifique la directiva:
   • Cambie el modo de acceso a la red.
   • Habilite o deshabilite el modo de ejecución seca para servicios específicos.
   • Agregue o quite los destinos de almacenamiento o FQDN.
2. Haga clic en Update(Actualizar).
3. Consulte Aplicar cambios de directiva de red para comprobar que las actualizaciones se aplican a las cargas de trabajo existentes.

Comprobación de los registros de denegación

Los registros de denegación se almacenan en la system.access.outbound_network tabla del catálogo de Unity. Estos registros realizan un seguimiento cuando se deniegan las solicitudes de red salientes. Para acceder a los registros de denegación de acceso, compruebe que el esquema de acceso está habilitado en el metastore del catálogo de Unity. Consulte Habilitar tablas del sistema.

Use una consulta SQL como la siguiente para ver los eventos de denegación. Si se habilitan los registros de ejecución en seco, la consulta devuelve los registros de denegación y los registros de ejecución en seco, que puede distinguir mediante la columna access_type. Los registros de denegación tienen un valor de DROP, mientras que los registros de ejecución en seco muestran DRY_RUN_DENIAL.

En el ejemplo siguiente se recuperan los registros de las últimas 2 horas:

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

En el caso del modo de ejecución seca y los modelos de inteligencia artificial externos, se cumple lo siguiente:

• Si la directiva de red ha bloqueado el acceso a las dependencias necesarias, compruebe primero los registros de denegación en system.access.outbound_network. Además, los registros de compilación del contenedor de servicio de modelos pueden proporcionar información útil sobre qué dominios se bloquearon.
• Si se produce un error en la compilación del contenedor de servicio del modelo, compruebe los registros de denegación en system.access.outbound_network para determinar qué dominios se bloquearon.
• La aplicación de las restricciones de acceso externo al modelo a través de Modelo de servicio continúa incluso en modo de simulación.

Limitaciones

• Tamaño de carga de artefactos: al usar el sistema de archivos interno de Databricks de MLflow con el dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> formato, las cargas de artefactos se limitan a 5 GB para las log_artifact, log_artifacts y log_model APIs.
• Entrega de registros de denegación para cargas de trabajo de recolección de basura (GC) de corta duración: Los registros de denegación de cargas de trabajo de GC que duren menos de 120 segundos pueden no ser entregados antes de que el nodo finalice debido a los retrasos en el registro. Aunque todavía se aplica el acceso, es posible que falte la entrada de registro correspondiente.
• Conectividad de red para funciones definidas por el usuario (UDF) de Databricks SQL: para habilitar el acceso a la red en Databricks SQL, póngase en contacto con el equipo de la cuenta de Databricks.

• Registro de eventhooks de pipelines: los eventhooks de Lakeflow Pipelines dirigidos a otro espacio de trabajo no se registran. Esto se aplica a los Eventhooks configurados para espacios de trabajo entre regiones y espacios de trabajo dentro de la misma región.
• Cambios de enlace del área de trabajo del catálogo de Unity: los cambios en los enlaces del área de trabajo del catálogo de Unity pueden tardar hasta 24 horas en ser efectivos. Para acelerar este proceso, agregue el cubo de almacenamiento a la directiva de red. Consulte Vinculación de catálogo de espacio de trabajo.

• Acceso a red a través de nubes: Las áreas de trabajo de Azure que utilizan cubos S3 para las ubicaciones externas del Unity Catalog no están permitidas actualmente por las políticas de red de computación sin servidor.

Pasos siguientes

• Configurar el control de entrada basado en contexto: defina directivas de acceso de entrada basadas en identidad, tipo de solicitud y origen de red para proteger el acceso al área de trabajo. Consulte Control de entrada basado en contexto.
• Administrar reglas de punto de conexión privado: controle el tráfico de red hacia y desde los puntos de conexión privados mediante la definición de reglas específicas que permitan o denieguen conexiones para mejorar la seguridad. Consulte Administración de reglas de punto de conexión privado.
• Configurar un firewall para el acceso a proceso sin servidor: implemente un firewall para restringir y proteger las conexiones de red entrantes y salientes para los entornos de proceso sin servidor. Consulte Configuración de un firewall para el acceso a procesos sin servidor.
• Descripción de los costos de transferencia de datos y conectividad: obtenga información sobre las implicaciones de los costos al implementar controles de seguridad de red y conectividad privada para cargas de trabajo sin servidor. Consulte Descripción de los costos de red de Databricks.