Gerenciar políticas de rede para o controle de saída serverless

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 serverless no Databricks.

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

Requisitos

• Seu Databricks workspace deve estar na camada Enterprise.

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

Acessando políticas de rede

Para criar, view, e atualizar políticas de rede em seu account:

1. No consoleaccount, clique em Segurança .
2. Clique na tab Rede .
3. Em Políticas , clique em 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 para a política .

3. Clique na tab 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 externo à Internet permanecerá irrestrito.
   • Acesso restrito a destinos específicos : o acesso de saída é limitado a destinos específicos.

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

Definir regras de saída

Antes de definir regras de saída, observe:

• Ao usar um bucket S3 em seu metastore, o senhor 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 é 2500.
• O número de FQDNs que podem ser adicionados como domínios permitidos é limitado a 100 por política.
• Os buckets do OpenSharing estão implicitamente na lista de permissões nas políticas de rede.

1. Para conceder ao site serverless compute acesso a domínios adicionais, clique em Add destination acima da lista Allowed domains (Domínios permitidos ).

   

   O filtro FQDN permite o acesso a todos os domínios que compartilham o mesmo endereço IP.

nota

modelo oferecido de provisionamento Taxa de transferência endpoint don't support granular FQDN filtering. Ao definir o acesso à rede como restrito, todo o acesso à internet é bloqueado para esses dispositivos.

2. Para permitir que o site workspace acesse uma conta de armazenamento Azure adicional, clique no botão Add destination (Adicionar destino ) acima da lista Allowed storage destinations (Destinos de armazenamento permitidos ).

Somente locais de armazenamento externo vinculados a um workspace ou a todos os espaços de trabalho são incluídos automaticamente nas políticas de rede. Para verificar se um local está vinculado ao seu workspace, siga estes passos:

1. No Catalog Explorer, abra o local externo e verifique a tab do espaço de trabalho para confirmar se seu workspace foi atribuído. Consulte Atribuir um local externo a um espaço de trabalho específico.
2. API/CLI: Use vinculações de espaço de trabalho para recuperar vinculações para o local externo:
   • API: Veja vinculações de espaço de trabalho.
   • CLI: Veja o grupo de comandosworkspace-bindings.

Você deve adicionar todos os FQDNs válidos para acessar serviços adicionais.

nota

Direct access to cloud storage services from user code containers, such as REPLs or UDFs, is not permitted by default. To enable this access, add the storage resource's FQDN under Allowed Domains in your policy. Adding only the storage resource's base domain could inadvertently grant access to all storage resources in the region.

Aplicação da política

O modo de execução a seco permite que o senhor teste a configuração da política e monitore as conexões de saída sem interromper o acesso ao recurso. 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 do Databricks SQL operam em modo de execução a seco.

2. AI servindo modelo : o endpoint servindo modelo opera no modo de execução a seco.

3. All product : Todos os Databricks serviços operam no modo de execução a seco, substituindo todas as outras seleções.

   

Bloquear destinos de internet

Bloquear destinos de internet

nota

This feature is in Public Preview and available to SEG-eligible workspaces. For workspaces on the Enterprise tier that are not yet SEG-eligible, blocked destinations are supported only in the default policy when network access is set to Full access.

Bloquear destinos de internet específicos das suas cargas de trabalho serverless. Use destinos bloqueados como uma alternativa leve ao modo de acesso restrito para bloquear domínios mal-intencionados conhecidos sem alternar o modo de aplicação geral.

Configure destinos bloqueados através da API REST de políticas de rede. A API requer um token OAuth de administrador de account. Tokens de acesso pessoal não são compatíveis com APIs no nível da account.

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

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 de IP e destinos de armazenamento não são compatíveis.
• Os destinos bloqueados são sempre aplicados independentemente do modo de acesso de rede da política.
• Os destinos bloqueados têm precedência sobre os 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 estritamente" é permitido (por exemplo, permitindo example.com e bloqueando api.example.com).

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

Para bloquear um destino de internet:

1. Recupere sua política de rede. Executar o seguinte comando:

   Substitua <ACCOUNT_HOST> por accounts.gcp.databricks.com.

   Bash

   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 total :

   JSON

   {
     "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 solicitação PUT para o mesmo endpoint usando o seguinte comando. O corpo PUT deve conter a política de rede completa. Quaisquer campos que você omitir são limpos.

   Bash

   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-rpc, ou com o recurso databricks_account_network_policy do Terraform. Consulte grupo de comandoaccount network-policies.

Atualize a política do site default

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

Associar uma política de rede ao espaço de trabalho

Se o senhor tiver atualizado a política default com configurações adicionais, elas serão aplicadas automaticamente ao espaço de trabalho que não tiver uma política de rede existente.

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

1. Selecione um workspace.
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 .

Aplique alterações na política de rede

A maioria das atualizações de configuração de rede é propagada automaticamente para o site serverless compute em dez minutos. Isso inclui:

• Adição de um novo local ou conexão externa do Unity Catalog.
• Anexar o site workspace a um metastore diferente.
• Alterar o armazenamento permitido ou os destinos da Internet.

nota

O senhor deve reiniciar o site compute se modificar a configuração do acesso à Internet ou do modo de execução a seco.

Reinicie ou reimplante as cargas de trabalho do serverless

O senhor só precisa atualizar quando mudar o modo de acesso à Internet ou quando atualizar o modo de execução a seco.

Para determinar o procedimento de reinicialização adequado, consulte a lista a seguir por produto:

• Databricks ML Serving : Reimplante seu endpoint de serviço de ML. Consulte Criar endpoint de modelo de serviço personalizado
• pipeline : Pare e reinicie o pipeline LakeFlow Spark Declarative em execução. Consulte execução de uma atualização pipeline.
• sem servidor SQL warehouse : Pare e reinicie o SQL warehouse. Consulte gerenciar a SQL warehouse.
• LakeFlow Trabalhos : As alterações na política de rede são aplicadas automaticamente quando uma nova execução de trabalho é acionada ou quando uma execução de trabalho existente é reiniciada.
• Notebook :
  • Se o seu Notebook não interagir com Spark, você poderá encerrar e reconectar compute serverless para refresh a política de rede.
  • Se o Notebook interagir com Spark, o recurso serverless 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 alternar entre políticas anexadas que tenham diferentes tipos de aplicação pode levar até 24 horas. Para agilizar um refresh sobre esses tipos específicos de alterações, desative todos os Notebook e Job associados.

Dependências da interface do usuário dos pacotes de automação declarativa

Ao usar o modo de acesso restrito com controle de saída serverless , os recursos da interface do usuário do Declarative Automation 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 workspace ao trabalhar com Pacotes de Automação Declarativa.

Para que o recurso da interface do usuário do Declarative Automation Bundles continue funcionando com políticas de rede restritas, adicione estes domínios aos domínios permitidos em sua política:

• github.com
• objetos.githubusercontent.com
• release-ativo.githubusercontent.com
• checkpoint-api.hashicorp.com
• releases.hashicorp.com
• registro.Terraform.io

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

O senhor pode validar se a sua política de rede está sendo aplicada corretamente tentando acessar recursos restritos de diferentes cargas de trabalho do serverless. O processo de validação varia de acordo com o produto serverless.

Lakeflow Spark Declarative Pipelines

1. Crie um notebook Python . Você pode usar o Notebook de exemplo fornecido no tutorial Python sobre o pipeline declarativoLakeFlow Spark na Wikipédia.

2. Criar um pipeline:

   1. Em seu site workspace, clique em Jobs & pipeline na barra lateral.

   2. Clique em Create e, em seguida, em ETL pipeline .

   3. Configure o pipeline com as seguintes definições:

      • pipeline Mode : sem servidor
      • Código-fonte : Selecione o Notebook que o senhor criou.
      • Opções de armazenamento : Unity Catalog. Selecione o catálogo e o esquema desejados.

   4. Clique em Criar .

3. execução o pipeline.

4. Na página pipeline, clique em começar .

5. Aguarde a conclusão do pipeline.

6. Verifique os resultados

   • Destino confiável : O pipeline foi executado com sucesso e gravou os 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 SQL warehouse.

2. executar uma consulta de teste no editor SQL que tenta acessar um recurso controlado pela sua política de rede.

3. Verifique os resultados:

   • Destino confiável : a consulta foi 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 Python biblioteca padrão, execute a seguinte definição UDF:

   SQL

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

Model serving

Validar com o modelo servindo

Antes de começar

Quando um modelo servindo endpoint é criado, uma imagem de contêiner é criada para servir o seu modelo. As políticas de rede são aplicadas durante esse estágio de construção. Ao usar o modelo servindo com políticas de rede, considere o seguinte:

• Acesso a dependências: Todas as dependências externas de compilação, como Python pacote de PyPI e conda-forge, imagens de contêineres básicos ou arquivos de URLs externos especificados no ambiente do seu modelo ou no contexto de Docker exigido pelo ambiente do seu modelo devem ser permitidos pela sua política de rede.

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

• Falhas na construção: se a sua política de rede bloquear o acesso a dependências necessárias, a construção do contêiner de servindo modelos falhará. Isso impede que o endpoint de disponibilização seja implantado com sucesso e pode fazer com que ele falhe ao 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 registros. Esses logs recorrem a um campo network_source_type com o valor ML Build. Essas informações são cruciais para identificar o recurso bloqueado específico que deve ser adicionado à sua política de rede para permitir que a compilação seja concluída com êxito.

Valide 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 tempo de execução, especificamente para tentativas de acesso a recursos externos durante a inferência. Isso pressupõe que o contêiner servindo modelo tenha sido criado com êxito, o que significa que todas as dependências de tempo de criação foram permitidas na política de rede.

1. Crie um modelo de teste

   1. Em um notebook 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 API.

   2. Execute este Notebook para gerar um modelo no teste workspace. Por exemplo:

      Python

      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 workspace, selecione AI/ML.

   2. Clique em Serving tab.

   3. Clique em Criar endpoint de serviço .

   4. Configure o endpoint com as seguintes definições:

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

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

   6. Aguarde até que o site endpoint atinja o estado Ready (Pronto ). Se ele não ficar pronto, verifique se há entradas network_source_type: ML Build no site logs. Consulte Recusa de cheque logs.

3. Consultar o site endpoint.

   1. Use a opção Query endpoint (Ponto de extremidade de consulta) na página endpoint para enviar uma solicitação de teste.

      JSON

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

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

   • Acesso à Internet ativado 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 na resolução do host.

Atualizar uma política de rede

Você pode atualizar uma política 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 da conta, modifique a política:

   • Altere o modo de acesso à rede.
   • Ativar ou desativar o modo de execução a seco para um serviço específico.
   • Adicione ou remova destinos de armazenamento ou FQDN.

2. Clique em Atualizar .

3. Consulte Aplicar alterações na política de rede para verificar se as atualizações são aplicadas às cargas de trabalho existentes.

Verificar a recusa logs

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 acessar logs de negação, verifique se o esquema de acesso está habilitado no seu metastore Unity Catalog . Consulte Ativar tabelas do sistema.

Use uma consulta SQL como a que está abaixo para view eventos de negação. Se os logs de execução a seco estiverem ativados, a consulta retornará logs de negação e logs de execução a seco, que o senhor pode distinguir usando a coluna access_type. Denial logs tem um valor DROP , enquanto dry-execução logs mostra DRY_RUN_DENIAL .

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

SQL

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 geradores externos AI, o seguinte é verdadeiro:

• Se a política de rede bloqueou o acesso às dependências necessárias, verifique primeiro o log de negações em system.access.outbound_network. Além disso, a compilação logs para o seu contêiner servindo modelo pode fornecer informações úteis sobre quais domínios foram bloqueados.
• Se a compilação do contêiner servindo modelo falhar, verifique o registro de negação em system.access.outbound_network para determinar quais domínios foram bloqueados.
• A aplicação do acesso ao modelo externo através do modelo interativo continua mesmo no modo de execução a seco.

nota

Pode haver uma latência perceptível entre o momento do acesso e o momento em que a negação logs aparece.

Limitações

• Tamanho upload de artefato : ao usar o sistema de arquivos Databricks interno do MLflow com o formato dbfs:/databricks/mlflow-tracking/<experiment_id>/<run_id>/artifacts/<artifactPath> , o upload de artefatos é limitado a 5 GB para APIs log_artifact, log_artifacts e log_model .

• Negação log entrega para cargas de trabalho de coleta de lixo (GC) de curta duração : A negação logs de cargas de trabalho de GC de curta duração, que duram menos de 120 segundos, pode não ser entregue antes que o nó seja encerrado devido a atrasos no registro. Embora o acesso ainda seja aplicado, a entrada correspondente em log pode estar ausente.

• Conectividade de rede para funções definidas pelo usuário (UDFs) d Databricks SQL : Para habilitar o acesso à rede n Databricks SQL, entre em contato com a equipe de Databricks account .

• Registro de eventos de pipeline : LakeFlow Spark Eventhooks de pipeline declarativos que têm como alvo outro workspace não são logs. Isso se aplica a Eventhooks configurados tanto para espaços de trabalho entre regiões quanto para espaços de trabalho na mesma região.

• Alterações nas vinculações workspace Unity Catalog : As alterações nas vinculações workspace Unity Catalog podem levar até 24 horas para entrar em vigor. Para agilizar esse processo, adicione o bucket de armazenamento à política de rede. Consulte a vinculação do catálogo de espaços de trabalho.

Próximos passos

• Configure 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 workspace . Veja Controle de entrada baseado em contexto.
• Configure a conectividade privada : utilize o serviço Privado Connect para estabelecer acesso seguro e isolado ao serviço Google Cloud a partir da sua rede virtual, sem passar pela Internet pública. Consulte Ativar serviço privado Connect para o seu workspace.
• 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 serverless . Consulte Compreender os custos de rede do Databricks.