Gerenciar políticas de rede para controle de saída sem servidor

Esta página explica como configurar e gerenciar políticas de rede para controlar conexões de rede de saída de suas cargas de trabalho sem servidor no Azure Databricks.

Para controle de entrada, consulte Controle de entrada baseado em contexto.

Requerimentos

• Seu espaço de trabalho do Azure Databricks deve estar na camada Premium.

• As permissões para gerenciar políticas de rede são restritas aos administradores de conta.

Aceder a políticas de rede

Para criar, visualizar e atualizar políticas de rede na sua conta:

1. No console da conta, clique em Segurança.
2. Clique na guia Rede .
3. Em Políticas, clique em Controle de entrada ou saída baseado no contexto.

Criar uma política de rede

1. Clique em Criar nova política de rede.

2. Insira um nome de política.

3. Clique na guia Saída .

   Para definir regras de entrada, consulte Definir regras de entrada.

4. Escolha um modo de acesso à rede:

   • Permitir acesso a todos os destinos: Acesso irrestrito à internet de saída. Se você escolher Acesso total, o acesso de saída à Internet permanecerá irrestrito.
   • Acesso restrito a destinos específicos: o acesso de saída é limitado a destinos especificados.

Configurar políticas de rede

As etapas a seguir descrevem as configurações opcionais para o modo de acesso restrito.

Definir regras de saída

Antes de definir as regras de saída, observe:

• Ao usar um bucket do S3 em seu metastore, você deve usar a API REST para adicionar explicitamente o bucket à sua lista de permissões de saída para que o acesso seja bem-sucedido.
• O número máximo de destinos suportados é de 2500.
• O número de FQDNs que podem ser adicionados como domínios permitidos é limitado a 100 por política.

• Os domínios adicionados como entradas de Link Privado para um balanceador de carga são implicitamente permitidos nas diretivas de rede. Quando um domínio é removido ou o ponto de extremidade privado é excluído, pode levar até 24 horas para que os controles de diretiva de rede apliquem totalmente a alteração. Consulte Configurar conectividade privada para recursos em sua rede virtual.
• Os buckets de partilha Delta estão implicitamente listados nas políticas de rede.

1. Para conceder ao computador sem servidor acesso a domínios adicionais, clique em Adicionar destino acima da lista Domínios permitidos .

   

   O filtro FQDN permite o acesso a todos os domínios que compartilham o mesmo endereço IP. O serviço de modelo provisionado em todos os endpoints de rede evita o acesso à Internet quando o acesso à rede é definido como restrito. No entanto, o controle granular com filtragem FQDN não é suportado.

2. Para permitir que seu espaço de trabalho acesse contas de armazenamento adicionais do Azure, clique no botão Adicionar destino acima da lista Destinos de armazenamento permitidos .

   

Aplicação de políticas

O modo de execução seca permite testar a configuração da política e monitorar as conexões de saída sem interromper o acesso aos recursos. Quando o modo de execução seca está ativado, as solicitações que violam a política são registradas, mas não bloqueadas. Você pode selecionar entre as seguintes opções:

1. Databricks SQL: Os armazéns Databricks SQL operam no modo de execução seca.

2. Servimento de modelo de IA: Os terminais de serviço de modelo operam no modo de execução a seco.

3. Todos os produtos: Todos os serviços do Azure Databricks operam no modo de execução seca, substituindo todas as outras seleções.

   

Atualizar a política padrão

Cada conta do Azure Databricks inclui uma política padrão . A política padrão é associada a todos os espaços de trabalho sem atribuição explícita de diretiva de rede, incluindo espaços de trabalho recém-criados. Você pode modificar essa política, mas ela não pode ser excluída.

As políticas padrão só são aplicadas a espaços de trabalho com, pelo menos, a camada Premium.

Associar uma política de rede a espaços de trabalho

Se você tiver atualizado sua política padrão com configurações adicionais, elas serão aplicadas automaticamente a espaços de trabalho que não têm uma diretiva de rede existente.

Seu espaço de trabalho deve estar no nível Premium.

Para associar seu espaço de trabalho a uma política diferente, faça o seguinte:

1. Selecione um espaço de trabalho.
2. Em Diretiva de Rede, clique em Atualizar diretiva de rede.
3. Selecione a política de rede desejada na lista.
4. Clique em Aplicar política.

Aplicar alterações na política de rede

A maioria das atualizações de configuração de rede propaga-se automaticamente para a computação sem servidor em dez minutos. Isto inclui:

• Adicionar um novo local externo ou conexão do Catálogo Unity.
• Anexando seu espaço de trabalho a um metastore diferente.
• Alterar o armazenamento permitido ou os destinos da Internet.

Reiniciar ou reimplantar cargas de trabalho sem servidor

Você só precisa atualizar ao mudar o modo de acesso à Internet ou ao atualizar o modo de execução a seco.

Para determinar o procedimento de reinicialização apropriado, consulte a seguinte lista por produto:

• Databricks ML Serving: Reimplante seu ponto de extremidade de serviço de ML. Consulte Criar pontos finais de serviço para modelos personalizados
• Pipelines: Pare e reinicie os Lakeflow Spark Declarative Pipelines em execução. Consulte Executar uma atualização de pipeline.
• SQL warehouse sem servidor: pare e reinicie o SQL warehouse. Consulte Gerenciar um depósito SQL.
• Lakeflow Jobs: As alterações de política de rede são aplicadas automaticamente quando uma nova execução de trabalho é acionada ou uma execução de trabalho existente é reiniciada.
• Cadernos:
  • Se o seu notebook não interagir com o Spark, pode interromper e depois voltar a conectar a computação serverless para atualizar a política de rede.
  • Se o seu bloco de notas interagir com o Spark, o recurso sem servidor é atualizado e deteta automaticamente a alteração. A maioria das alterações será atualizada em dez minutos, mas alternar os modos de acesso à Internet, atualizar o modo de execução a seco ou alterar entre políticas anexadas que têm diferentes tipos de imposição pode levar até 24 horas. Para agilizar uma atualização nesses tipos específicos de alterações, desative todos os blocos de anotações e trabalhos associados.

Dependências da interface de utilizador do Databricks Asset Bundles

Quando você usa o modo de acesso restrito com controle de saída sem servidor, os recursos da interface do usuário do Databricks Asset Bundles exigem acesso a domínios externos específicos. Se o acesso de saída for completamente restrito, os usuários poderão ver erros na interface do espaço de trabalho ao trabalhar com Databricks Asset Bundles.

Para manter os recursos da interface do usuário do Databricks Asset Bundles funcionando com políticas de rede restritas, adicione estes domínios aos domínios permitidos em sua política:

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

Verificar a aplicação da política de rede

Você pode validar se sua diretiva de rede é aplicada corretamente tentando acessar recursos restritos de diferentes cargas de trabalho sem servidor. O processo de validação varia dependendo do produto sem servidor.

Valide usando pipelines declarativos Lakeflow Spark

1. Crie um bloco de anotações Python. Você pode usar o bloco de anotações de exemplo fornecido no tutorial Lakeflow Spark Declarative Pipelines wikipedia python.
2. Crie um fluxo de trabalho:
   1. No espaço de trabalho, clique no Jobs & Pipelines na barra lateral.
   2. Clique em Criar e, em seguida, em Pipeline de ETL.
   3. Configure o pipeline com as seguintes configurações:
      • Modo de pipeline: sem servidor
      • Código-fonte: Selecione o bloco de anotações que você criou.
      • Opções de armazenamento: Unity Catalog. Selecione o catálogo e o esquema desejados.
   4. Clique em Criar.
3. Executar o pipeline.
4. Na página do pipeline, clique em Iniciar.
5. Aguarde a conclusão do pipeline.
6. Verificar os resultados
   • Destino confiável: o pipeline é executado com êxito e grava dados no destino.
   • Destino não confiável: o pipeline falha com erros, indicando que o acesso à rede está bloqueado.

Validar com Databricks SQL

1. Crie um armazém SQL.

2. Execute uma consulta de teste no editor SQL que tenta acessar um recurso controlado pela sua diretiva de rede.

3. Verifique os resultados:

   • Destino confiável: a consulta é bem-sucedida.
   • Destino não confiável: a consulta falha com um erro de acesso à rede.

4. Para se conectar a uma rede a partir de uma UDF usando uma biblioteca Python padrão, execute a seguinte definição 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!"
   $$;
   

Valide com o serviço de modelos

Antes de começar

Quando um endpoint de serviço de modelo é criado, uma imagem de contentor é gerada para fornecer o seu modelo. As políticas de rede são implementadas durante esta fase de construção. Ao usar o serviço de modelo com diretivas de rede, considere o seguinte:

• Acesso a dependências: Quaisquer dependências de compilação externas, como pacotes Python do PyPI e conda-forge, imagens de contentores base ou ficheiros de URLs externas especificados no ambiente do modelo ou no contexto do Docker exigido pelo ambiente do modelo, devem ser permitidas pela política de rede.

  • Por exemplo, se o seu modelo requer uma versão específica do scikit-learn que precisa ser baixada durante a compilação, a política de rede deve permitir o acesso ao repositório que hospeda o pacote.

• Falhas de compilação: Se sua política de rede bloquear o acesso às dependências necessárias, o modelo que serve a compilação de contêiner falhará. Isso impede que o endpoint de serviço seja implantado com êxito e pode impedir o seu adequado armazenamento ou funcionamento.

  Consulte Verificar logs de negação.

• Solução de problemas de negações: As recusas de acesso à rede durante a fase de compilação são registradas. Esses logs apresentam um network_source_type campo com o valor ML Build. Essas informações são cruciais para identificar os recursos bloqueados específicos que devem ser adicionados à sua política de rede para permitir que a compilação seja concluída com êxito.

Validar o acesso à rede em tempo de execução

As etapas a seguir demonstram como validar a diretiva de rede para um modelo implantado em tempo de execução, especificamente para tentativas de acessar recursos externos durante a inferência. Isto pressupõe que o contentor de execução do modelo tenha sido construído com sucesso, o que significa que quaisquer dependências no momento de construção foram permitidas na política de rede.

1. Criar um modelo de teste

   1. Em um bloco de anotações Python, crie um modelo que tente acessar um recurso público da Internet no momento da inferência, como baixar um arquivo ou fazer uma solicitação de API.

   2. Execute este bloco de anotações para gerar um modelo no espaço de trabalho de teste. Por exemplo:

      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. Criar um endpoint de serviço

   1. Na navegação do espaço de trabalho, selecione AI/ML.

   2. Clique na guia Servir .

   3. Clique em Criar Endpoint de Serviço.

   4. Configure o ponto de extremidade com as seguintes configurações:

      • Nome do Ponto Final de Serviço: forneça um nome descritivo.
      • Detalhes da entidade: Selecione Modelo do registo de modelos.
      • Modelo: Escolha o modelo que você criou na etapa anterior (internet-http-access).

   5. Clique em Confirmar. Nesta etapa, inicia-se o processo de construção do contêiner de execução do modelo. As políticas de rede para ML Build serão aplicadas. Se a compilação falhar devido a bloqueio de acesso à rede para as dependências, o endpoint não ficará pronto.

   6. Aguarde até que o ponto de extremidade de serviço atinja o estado Pronto . Caso não esteja pronto, verifique os logs de recusas para entradas network_source_type: ML Build.

      Consulte Verificar logs de negação.

3. Consulte o ponto de extremidade.

   1. Utilize a opção Consultar endpoint na página do endpoint de serviço para enviar uma solicitação de teste.

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

4. Verifique o resultado para acesso em tempo de execução:

   • Acesso à Internet habilitado em tempo de execução: a consulta é bem-sucedida e retorna um código de status como 200.
   • Acesso à Internet restrito em tempo de execução: a consulta falha com um erro de acesso à rede, como a mensagem de erro do bloco try-except no código do modelo, indicando um tempo limite de conexão ou falha de resolução de anfitrião.

Atualizar uma política de rede

Você pode atualizar uma diretiva de rede a qualquer momento após sua criação. Para atualizar uma política de rede:

1. Na página de detalhes da política de rede no console de contas, modifique a política:
   • Altere o modo de acesso à rede.
   • Habilite ou desabilite o modo de execução seca para serviços específicos.
   • Adicione ou remova FQDN ou destinos de armazenamento.
2. Clique em Atualizar.
3. Consulte Aplicar alterações de diretiva de rede para verificar se as atualizações são aplicadas a cargas de trabalho existentes.

Verifique os registros de negação

Os logs de negação são armazenados na tabela system.access.outbound_network no Unity Catalog. Esses logs rastreiam quando as solicitações de rede de saída são negadas. Para aceder aos registos de negação, verifique se o schema de acesso está ativado no metastore do Catálogo Unity. Consulte Ativar tabelas do sistema.

Use uma consulta SQL como a abaixo para exibir eventos de negação. Se os logs de execução seca estiverem habilitados, a consulta retornará os logs de negação e os logs de execução seca, que você pode distinguir usando a coluna access_type. Os logs de negação têm um valor DROP , enquanto os logs de execução seca mostram DRY_RUN_DENIAL.

O exemplo a seguir recupera logs das últimas 2 horas:

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

Para o modo de execução a seco e modelos de IA generativa externos, o seguinte é verdadeiro:

• Se a sua política de rede tiver bloqueado o acesso às dependências necessárias, primeiro verifique os logs de negação em system.access.outbound_network. Além disso, os logs de compilação para seu contêiner de serviço de modelo podem fornecer informações úteis sobre quais domínios foram bloqueados.
• Se a compilação do contêiner de serviço do modelo falhar, verifique os logs de negação em system.access.outbound_network para determinar quais domínios foram bloqueados.
• A aplicação das regras para acesso a modelos externos através do Mosaic AI Serving continua mesmo no modo de teste.

Limitações

• Tamanho do carregamento de artefatos: Ao usar o sistema de arquivos Databricks interno do MLflow com o dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> formato, os carregamentos de artefatos são limitados a 5 GB para log_artifact, log_artifactse log_model APIs.
• Serviço de modelos: O controle de saída não se aplica ao criar imagens para serviço de modelos.
• Entrega de registos de negação para cargas de trabalho de coleta de lixo (GC) de curta duração: os registos de negação provenientes de cargas de trabalho de coleta de lixo com menos de 120 segundos de duração podem não ser entregues antes do término do nó devido a atrasos no registo. Embora o acesso ainda seja controlado, o registo correspondente no log pode estar em falta.
• Conectividade de rede para funções definidas pelo usuário (UDFs) do Databricks SQL: para habilitar o acesso à rede no Databricks SQL, entre em contato com a equipe da conta do Databricks.

• Registo de eventhook de pipeline: os eventhooks do Lakeflow Spark Declarative Pipelines que têm como alvo outro espaço de trabalho não são registados. Isso se aplica a Eventhooks configurados para espaços de trabalho entre regiões e espaços de trabalho na mesma região.
• Alterações na vinculação do espaço de trabalho do Catálogo Unity: as alterações nas associações do espaço de trabalho do Catálogo Unity podem levar até 24 horas para entrar em vigor. Para agilizar esse processo, adicione o bucket de armazenamento à diretiva de rede. Consulte Limitar o acesso do catálogo a espaços de trabalho específicos.

• Acesso à rede entre nuvens: os espaços de trabalho do Azure que usam buckets do S3 usados para locais externos do Unity Catalog não são atualmente permitidos pelas políticas de rede sem servidor.

Próximos passos

• Configurar controle de entrada baseado em contexto: defina políticas de acesso de entrada com base na identidade, no tipo de solicitação e na origem da rede para proteger o acesso ao espaço de trabalho. Consulte Controle de entrada baseado no contexto.
• Gerenciar regras de ponto final privado: controle o tráfego de rede de e para seus pontos de extremidade privados definindo regras específicas que permitem ou negam conexões para maior segurança. Consulte Gerenciar regras de ponto de extremidade privado.
• Configurar um firewall para acesso à computação sem servidor: implemente um firewall para restringir e proteger as conexões de rede de entrada e saída para seus ambientes de computação sem servidor. Consulte Configurar um firewall para acesso à computação sem servidor.
• Compreender os custos de transferência de dados e conectividade: saiba mais sobre as implicações de custo ao implementar controles de segurança de rede e conectividade privada para cargas de trabalho sem servidor. Consulte Compreender os custos de rede sem servidor Databricks.