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 em Azure Databricks.

Para obter controle de entrada, consulte o controle de entrada baseado em contexto.

Requisitos

Azure

• Seu workspace Azure Databricks deve estar na camada Premium.

Azure China

• Seu workspace Azure Databricks deve estar na camada Premium.
• O controle de saída sem servidor tem suporte apenas na região Norte da China 3. Seu workspace deve estar no Norte da China 3.
• Acesse as políticas de rede do console de conta do Azure China em accounts.databricks.azure. cn.

• 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 seguintes etapas descrevem as configurações opcionais para o modo de acesso restrito:

• Definir regras de saída
• Imposição de política
• Bloquear destinos da Internet

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 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.

• Os domínios adicionados como entradas do Link Privado para um balanceador de carga são implicitamente incluídos na lista de permissões 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 openSharing 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.

   Observação

   Os endpoints de throughput provisionado do Model Serving não oferecem suporte às seguintes políticas: Quando você define o acesso à rede como 'restrito', todo o acesso à Internet é bloqueado para esses dispositivos.

2. Para permitir que seu workspace acesse contas de armazenamento Azure adicionais, clique no botão Add destination acima da lista de Allowed storage destinations.

   

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 produtos: todos os serviços Azure Databricks operam no modo de execução a seco, substituindo todas as outras seleções.

   

Bloquear destinos da Internet

Bloqueie destinos específicos da Internet de suas cargas de trabalho sem servidor. Use destinos bloqueados como uma alternativa leve ao modo de acesso restrito para bloquear domínios conhecidos e inválidos sem alternar o modo de imposição geral.

Configure destinos bloqueados por meio da API REST das políticas de rede. A API requer um token OAuth do administrador da conta. Não há suporte para tokens de acesso pessoal para APIs de nível de conta.

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

Destinos bloqueados se comportam da seguinte maneira:

• Cada entrada especifica um destination (um nome de domínio totalmente qualificado, ou FQDN) e um internet_destination_type de DNS_NAME.
• Não há suporte para intervalos de IP e destinos de armazenamento.
• Os destinos bloqueados são sempre aplicados, independentemente do modo de acesso à rede da política.
• Destinos bloqueados têm precedência sobre destinos permitidos.
• A API rejeita configurações em que um destino permitido é um subdomínio de um destino bloqueado. No entanto, o padrão "permitir amplamente, bloquear de forma restrita" é permitido (por exemplo, permitindo example.com e bloqueando api.example.com).

As negações são registradas na tabela system.access.outbound_network no Unity Catalog, mesmo quando o acesso à rede está definido como Acesso total. Consulte Verificar logs de negação.

Para bloquear um destino da Internet:

1. Recupere sua política de rede. Execute o comando a seguir:

   Substitua <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>'
   

   Salve o corpo da resposta como network-policy.json.

2. Editar network-policy.json para adicionar blocked_internet_destinations em egress.network_access. O exemplo a seguir bloqueia um único domínio no modo de acesso 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. Envie a política atualizada com uma requisição PUT para o mesmo endpoint usando o comando abaixo. O PUT corpo deve conter a política de rede completa. Todos os campos que você omitir serão limpos.

   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
   

Você também pode gerenciar políticas de rede com a CLI do Databricks usando databricks account network-policies update-network-policy-rpcou 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 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 os pipelines 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 Declarative Automation Bundles

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 Automação Declarativa 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 quando estiverem trabalhando com Pacotes de Automação Declarativa.

Para manter os recursos de interface do usuário dos Pacotes de Automação Declarativa 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.

Pipelines do Lakeflow

1. Crie um bloco de anotações Python. Você pode usar o notebook de exemplo fornecido no Tutorial do Python do Wikipedia para pipelines do Lakeflow.
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.

SQL do Databricks

Validar com o Databricks SQL

1. Crie um armazém de dados SQL.

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 conectar-se a uma rede a partir de uma UDF usando uma biblioteca padrão de 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!"
   $$;
   

Serviço de modelo

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 bloco de anotações 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 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 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 seca e modelos de IA externos, 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 do acesso a modelos externos por meio do Model Serving continua mesmo no modo dry-run.

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.
• 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 em log de eventhook de pipelines: os eventhooks de pipelines do Lakeflow que visam outro workspace não são registrados em log. 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 Workspace-catalog binding.

• 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. Consulte Configurar um firewall para acesso à computação 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 do Databricks.