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 obter controle de entrada, consulte o controle de entrada baseado em contexto.

Requisitos

• Seu workspace do Azure Databricks deve estar na camada Premium.

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

Acessando políticas de rede

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

1. No console da conta, clique em Segurança.
2. Clique na guia Rede .
3. Em Políticas, clique no controle de entrada e saída baseado em 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 regras de saída, observe:

• Ao usar um bucket S3 em seu metastore, você deve usar a API REST para adicionar explicitamente o bucket à lista de permissões de saída para que o acesso seja bem-sucedido.
• O número máximo de destinos com suporte é 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 políticas 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 política de rede imponham totalmente a alteração. Veja Configuração da conectividade privada com recursos em sua VNet.
• Os buckets de compartilhamento Delta são implicitamente permitidos nas políticas de rede.

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

   

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

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

   

Imposição de política

O modo de execução a seco permite testar sua configuração de política e monitorar conexões de saída sem interromper o acesso aos recursos. Quando o modo de execução seca está habilitado, as solicitações que violam a política são registradas, mas não bloqueadas. É possível selecionar das seguintes opções:

1. SQL do Databricks: os armazéns SQL do Databricks operam no modo de execução a seco.

2. Serviço de modelo de IA: os pontos de extremidade 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 a seco, substituindo todas as outras seleções.

   

Atualizar a política padrão

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

As políticas padrão são aplicadas somente a workspaces 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 aos workspaces que não têm uma política de rede existente.

Seu workspace deve estar na camada Premium.

Para associar seu workspace a uma política diferente, faça o seguinte:

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

Aplicar alterações de política de rede

A maioria das atualizações de configuração de rede é propagada automaticamente para sua computação sem servidor em dez minutos. Isso inclui:

• Adicionando uma nova conexão ou localização externa do Catálogo do Unity.
• Anexando seu workspace a um metastore diferente.
• Alterando os destinos de armazenamento ou internet permitidos.

Reiniciar ou reimplantar cargas de trabalho sem servidor

Você só precisa atualizar ao alternar 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 endpoint de serviço de ML. Consulte Criar pontos de extremidade de serviço de modelo personalizados
• Pipelines: interrompa e reinicie seus Pipelines Declarativos de Spark do Lakeflow em execução. Consulte Como executar uma atualização de pipeline.
• Armazém SQL sem servidor: pare e reinicie o Armazém SQL. Confira Gerenciar um SQL warehouse.
• Trabalhos do Lakeflow: as alterações de política de rede são aplicadas automaticamente quando uma nova execução de trabalho é disparada ou uma execução de trabalho existente é reiniciada.
• Notebooks:
  • Se o notebook não interagir com o Spark, você poderá encerrar e, em seguida, reconectar a computação serverless para atualizar a política de rede.
  • Se o notebook interagir com o Spark, o recurso sem servidor será atualizado e detectará 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 desses tipos específicos de alterações, desative todos os notebooks e trabalhos associados.

Dependências da interface do usuário dos Pacotes de Ativos do Databricks

Quando você usa o modo de acesso restrito com controle de saída sem servidor, os recursos de interface do usuário dos Pacotes de Ativos do Databricks 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 workspace ao trabalhar com pacotes de ativos do Databricks.

Para manter os recursos de interface do usuário dos Pacotes de Ativos do Databricks funcionando com políticas de rede restritas, adicione esses 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 imposição da política de rede

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

Validar com Pipelines Declarativos do Lakeflow Spark

1. Crie um notebook em Python. Você pode usar o bloco de anotações de exemplo fornecido no tutorial do Python da Wikipédia do Lakeflow Spark Declarative Pipelines.
2. Crie um pipeline:
   1. No seu espaço de trabalho, clique no Tarefas e Pipelines na barra lateral.
   2. Clique Criar, depois ETL Pipeline.
   3. Defina o pipeline com as seguintes configurações:
      • Modo de pipeline: sem servidor
      • Código-fonte: selecione o notebook que você criou.
      • Opções de armazenamento: Catálogo do Unity. Selecione o catálogo e o esquema desejados.
   4. Clique em Criar.
3. Execute o pipeline.
4. Na página do pipeline, clique em Iniciar.
5. Aguarde a conclusão do pipeline.
6. Verifique 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 o Databricks SQL

1. Crie um SQL Warehouse.

2. Execute uma consulta de teste no editor do SQL que tenta acessar um recurso controlado por sua política 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 de uma UDF usando uma biblioteca padrão do Python, execute a seguinte definição 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!"
   $$;
   

Validar com o serviço de modelos

Antes de começar

Quando um ponto de extremidade de serviço de modelo é criado, uma imagem de contêiner é construída para servir o seu modelo. As políticas de rede são impostas durante esse estágio de build. Ao usar o serviço de modelos com políticas de rede, considere o seguinte:

• Acesso de dependência: quaisquer dependências externas de build, como pacotes Python de PyPI e Conda-Forge, imagens de contêiner base ou arquivos de URLs externas especificados no ambiente do modelo ou no contexto do Docker que o ambiente do modelo exige, devem ser permitidos pela política de rede.

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

• Falhas de build: Se a política de rede bloquear o acesso às dependências necessárias, o modelo que atende ao build de contêiner falhará. Isso impede que o endpoint de serviço seja implantado com êxito e, potencialmente, possa falhar em armazenar ou funcionar corretamente.

  Consulte Verificar logs de negação.

• Solução de problemas de negações: as negações de acesso à rede durante a fase de construçã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 à política de rede para permitir que o build seja concluído com êxito.

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

As etapas a seguir demonstram como validar a política de rede para um modelo implantado em runtime, especificamente para tentativas de acessar recursos externos durante a inferência. Isso pressupõe que o contêiner de entrega do modelo foi criado com êxito, o que significa que quaisquer dependências de tempo de compilação foram permitidas na política de rede.

1. Criar um modelo de teste

   1. Em um notebook Python, crie um modelo que tente acessar um recurso público da Internet em tempo de inferência, como baixar um arquivo ou fazer uma solicitação de API.

   2. Execute este notebook para criar um modelo no workspace 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 workspace, selecione IA/ML.

   2. Clique na guia Servir.

   3. Clique em Criar Endpoint de Serviço.

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

      • Nome do Endpoint de Serviço: Forneça um nome descritivo.
      • Detalhes da Entidade: Selecione Modelo do registro.
      • Modelo: escolha o modelo que você criou na etapa anterior (internet-http-access).

   5. Clique em Confirmar. Neste estágio, o processo de construção do contêiner de serviço do modelo começa. As políticas de rede para ML Build serão aplicadas. Se a compilação falhar devido ao acesso de rede bloqueado para dependências, o ponto de extremidade não ficará pronto.

   6. Aguarde até que o ponto de extremidade de serviço atinja o estado Pronto. Se não estiver pronto, verifique se há logs de negação para as entradas network_source_type: ML Build.

      Consulte Verificar logs de negação.

3. Consulte o ponto de extremidade.

   1. Use a opção Consultar ponto de extremidade na página do ponto de extremidade 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 do acesso em tempo de execução:

   • Acesso à Internet habilitado em runtime: a consulta é bem-sucedida e retorna um código de status como 200.
   • Acesso à Internet restrito em runtime: 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 na resolução do host.

Atualizar uma política de rede

Você pode atualizar uma política de rede a qualquer momento depois que ela for criada. 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 política de rede para verificar se as atualizações são aplicadas a cargas de trabalho existentes.

Verificar os logs de negação

Os logs de negação são armazenados na tabela system.access.outbound_network no Catálogo do Unity. Esses logs rastreiam quando as solicitações de rede de saída são negadas. Para acessar logs de recusas, verifique se o esquema de acesso está habilitado no metastore do Unity Catalog. Consulte Habilitar as 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á logs de negação e logs de execução seca, que você poderá 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 externos de IA generativos, o seguinte é verdadeiro:

• Se a 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 registros de compilação para o contêiner de disponibilização do modelo podem fornecer informações úteis sobre quais domínios foram bloqueados.
• Se o modelo que está servindo o build de contêiner falhar, verifique os logs de negação em system.access.outbound_network para determinar quais domínios foram bloqueados.
• A imposição para acesso a modelos externos por meio do Serviço do Mosaic AI continua mesmo no modo de simulação.

Limitações

• Tamanho do upload do artefato: ao usar o sistema de arquivos do Databricks interno do MLflow com o formato dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath>, os uploads de artefatos são limitados a 5 GB para log_artifact, log_artifacts e log_model APIs.
• Serviço de modelo: o controle de egressos não se aplica ao compilar imagens para serviço de modelo.
• Entrega de log de negação para cargas de trabalho de coleta de lixo (GC) de curta duração: logs de negação de cargas de trabalho de GC de curta duração, com menos de 120 segundos, podem não ser entregues antes da rescisão do nó devido a atrasos no registro em log. Embora o acesso ainda seja imposto, a entrada de log correspondente pode estar ausente.
• Conectividade de rede para UDFs (funções definidas pelo usuário) do Databricks SQL: para habilitar o acesso à rede no Databricks SQL, entre em contato com sua equipe de conta do Databricks.

• Registro de eventhooks de pipeline: Um pipeline declarativo Lakeflow Spark que tem como alvo outro espaço de trabalho não é registrado. Isso se aplica aos Eventhooks configurados tanto para workspaces entre regiões quanto para aqueles na mesma região.
• Alterações de associação do workspace do Catálogo do Unity: as alterações nas associações de workspace do Catálogo do Unity podem levar até 24 horas para serem efetivadas. Para agilizar esse processo, adicione o bucket de armazenamento à política de rede. Consulte Limitar acesso do catálogo a espaços de trabalho específicos.

• Acesso à rede entre nuvens: os workspaces do Azure que usam buckets S3 usados para locais externos do Catálogo do Unity não são permitidos atualmente por políticas de rede sem servidor.

Próximas etapas

• Configurar o 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 workspace. Consulte o controle de entrada baseado em contexto.
• Gerenciar regras de ponto de extremidade privado: controlar o tráfego de rede de e para seus pontos de extremidade privados definindo regras específicas que permitem ou negam conexões para segurança aprimorada. Consulte Gerenciar regras de ponto de extremidade privado.
• Configurar um firewall para acesso à computação sem servidor: implemente um firewall para restringir e proteger conexões de rede de entrada e saída para seus ambientes de computação sem servidor. Veja Configurar um firewall para acesso computacional sem servidor.
• Entenda 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 Noções básicas sobre os custos de rede sem servidor do Databricks.