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

Esta página explica como configurar e gerir políticas de rede para controlar ligações de saída a partir das suas cargas de trabalho serverless no Azure Databricks.

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

Requerimentos

Azure

• O seu espaço de trabalho Azure Databricks deve estar no nível Premium.

Azure China

• O seu espaço de trabalho Azure Databricks deve estar no nível Premium.
• O controlo de saída serverless é suportado apenas na região China North 3. O seu espaço de trabalho deve ser na China Norte 3.
• Aceda às políticas de rede a partir da consola da conta Azure China em accounts.databricks.azure. cn.

• 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

Os passos seguintes descrevem as definições opcionais para o modo de acesso restrito:

• Definir regras de saída
• Aplicação de políticas
• Blocar destinos de internet

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 destinos de armazenamento (allowed_storage_destinations) que podem ser adicionados é limitado a 100 por política.
• O número de FQDNs que podem ser adicionados como domínios permitidos é limitado a 100 por política.

• Domínios adicionados como entradas do Private Link para um balanceador de carga estã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 diretiva de rede apliquem totalmente a alteração. Consulte Configurar conectividade privada para recursos em sua rede virtual.
• Os buckets do OpenSharing estão implicitamente incluídos na lista de permissões 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.

   Nota

   Os endpoints de largura de banda provisionada para o Model Serving não suportam filtragem granular de FQDN. Quando defines o acesso à rede para restrito, todo o acesso à internet fica bloqueado para esses endpoints.

2. Para permitir que o seu espaço de trabalho aceda a contas de armazenamento Azure adicionais, 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 Azure Databricks operam em modo de ensaio a seco, sobrepondo-se a todas as outras seleções.

   

Blocar destinos de internet

Bloqueie destinos específicos na Internet das suas cargas de trabalho serverless. Use destinos bloqueados como uma alternativa leve ao modo de acesso restrito para bloquear domínios conhecidos e maus sem alterar o modo geral de aplicação.

Configurar destinos bloqueados através das políticas de rede da API REST. A API requer um token OAuth de administrador da conta. Os tokens de acesso pessoal não são suportados para APIs de nível de conta.

Consulte a autenticação OAuth de máquina para máquina.

Os destinos bloqueados comportam-se da seguinte forma:

• Cada entrada especifica um destination (um nome de domínio totalmente qualificado, ou FQDN) e um internet_destination_type de DNS_NAME.
• Intervalos IP e destinos de armazenamento não são suportados.
• Destinos bloqueados são sempre aplicados, independentemente do modo de acesso à rede da política.
• Destinos bloqueados têm prioridade sobre destinos permitidos.
• A API rejeita configurações onde um destino permitido é um subdomínio de um destino bloqueado. No entanto, o padrão "permitir amplamente, bloquear estreitamente" é permitido (por exemplo, permitir example.com e bloquear api.example.com).

As recusas são registadas na system.access.outbound_network tabela do Unity Catalog mesmo quando o acesso à rede está definido como Acesso Total. Consulte Verificar logs de negação.

Para bloquear um destino na internet:

1. Obtenha a política da sua rede. Execute o seguinte comando:

   Substituir <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 o corpo da resposta como network-policy.json.

2. Edite network-policy.json para acrescentar blocked_internet_destinations em egress.network_access. O exemplo seguinte bloqueia um único domínio em modo de acesso total :

   {
     "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. Submeta a política atualizada com uma solicitação PUT no mesmo endpoint usando o seguinte comando. O corpo PUT deve conter a política de rede completa. Qualquer campo que omitas fica limpo.

   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
   

Também pode gerir políticas de rede com a CLI Databricks usando databricks account network-policies update-network-policy-rpc, ou com o recurso Terraform databricks_account_network_policy . Consulte account network-policies o grupo de comandos.

Atualizar a política padrão

Cada conta Azure Databricks inclui uma política default. 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
• Oleodutos: Pare e depois reinicie os seus oleodutos Lakeflow em funcionamento. 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.

A Automação Declarativa Agrupa Dependências de UI

Quando utiliza o modo de acesso restrito com controlo de saída sem servidor, as funcionalidades da UI do Bündel Declarativo de Automação exigem acesso a domínios externos específicos. Se o acesso de saída for completamente restringido, os utilizadores podem detetar erros na interface do espaço de trabalho ao trabalhar com Pacotes de Automação Declarativa.

Para manter as funcionalidades da interface do Declarative Automation Bundles a funcionar com políticas de rede restritas, adicione estes domínios aos domínios Permitidos na 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.

Condutas de fluxo de lago

1. Cria um caderno em Python. Pode usar o caderno de exemplo fornecido no tutorial de Wikipédia em Python do Lakeflow Pipelines.
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.

Databricks SQL

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 ligar a uma rede a partir de um UDF usando uma biblioteca Python padrão, 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!"
   $$;
   

Serviço de modelos

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 externas de compilação, como pacotes Python do PyPI e conda-forge, imagens base de contêiner, ou ficheiros de URLs externas especificadas no ambiente do seu modelo ou no contexto Docker exigido pelo ambiente do seu modelo, devem ser permitidas pela sua 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 na compilação: Se a sua política de rede bloquear o acesso às dependências necessárias, a construção do contentor de serviço do modelo falha. 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. Num caderno Python, crie um modelo que tente aceder a um recurso público da internet no momento da inferência, como descarregar um ficheiro ou fazer um pedido 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 serverless network 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 endpoint com as seguintes definiçõ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 prova a seco e modelos externos de IA, 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 fiscalização do acesso externo ao modelo através do Model Serving continua mesmo em modo de ensaio geral.

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.
• 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 ganchos de eventos de pipelines: Os ganchos de eventos dos pipelines Lakeflow que têm como destino 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. Ver Encadernação de catálogo de espaço de trabalho.

• Acesso à rede entre clouds: Os espaços de trabalho do Azure que utilizam buckets S3 para localizações externas do Catálogo Unity não são permitidos atualmente pelas políticas de rede serverless.

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 Gerir 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 do Databricks.