Configuração de uma VPC gerenciada pelo cliente

Visão geral

Por default, os clusters são criados em uma única VPC (Virtual Private Cloud) da AWS que o Databricks cria e configura na sua account da AWS. Opcionalmente, você pode criar seus workspaces do Databricks na sua própria VPC, um recurso conhecido como customer-managed VPC. Você pode usar uma customer-managed VPC para exercer mais controle sobre suas configurações de rede e cumprir com os padrões específicos de segurança e governança na nuvem que sua organização pode exigir. Para configurar seu workspace e usar AWS PrivateLink para qualquer tipo de conexão, seu workspace deve usar uma customer-managed VPC.

Uma VPC gerenciada pelo cliente é uma boa solução se você tiver:

  • Políticas de segurança que impeçam que provedores de PaaS criem VPCs em sua própria conta da AWS.

  • Um processo de aprovação para criar uma nova VPC, no qual a VPC é configurada e protegida de maneira bem documentada pelas equipes internas de segurança da informação ou engenharia de nuvem.

Os benefícios incluem:

  • Nível de privilégio inferior: você mantém mais controle de sua própria conta da AWS. E você não precisa conceder ao Databricks tantas permissões por meio da função IAM entre contas quanto faz para uma VPC gerenciada pelo Databricks. Por exemplo, não há necessidade de permissão para criar VPCs. Esse conjunto limitado de permissões pode facilitar a obtenção de aprovação para usar o Databricks em sua pilha de plataforma.

  • Operações de rede simplificadas: melhor utilização do espaço de rede. Ou então, configure sub-redes menores para um workspace, em comparação com o default CIDR /16. E não há necessidade de configurações complexas de emparelhamento da VPC que podem ser necessárias com outras soluções.

  • Consolidação de VPCs: vários workspaces do Databricks podem compartilhar um único plano de compute clássico VPC, geralmente preferido para cobrança e gerenciamento de instâncias.

  • Limitação de conexões de saída: por default, o plano de compute clássico não limita as conexões de saída dos workers do Databricks Runtime. Para workspaces configurados para usar uma customer-managed VPC, você pode usar um firewall de saída ou dispositivo proxy para limitar o tráfego de saída a uma lista de fontes de dados internas ou externas permitidas.

VPC gerenciada pelo cliente

Para aproveitar uma VPC gerenciada pelo cliente, você deve especificar uma VPC ao criar o workspace do Databricks pela primeira vez. Você não pode mover um workspace existente com uma VPC gerenciada pelo Databricks para usar uma VPC gerenciada pelo cliente. Pode, no entanto, mover um workspace existente com uma VPC gerenciada pelo cliente de uma VPC para outra, atualizando o objeto de configuração de rede da configuração do workspace. Consulte Atualizar um workspace em execução ou com falha.

Para implantar um workspace em sua própria VPC, você deve:

  1. Criar a VPC seguindo os requisitos enumerados em Requisitos da VPC.

  2. Referenciar sua configuração de rede da VPC com o Databricks ao criar o workspace.

    Você deve fornecer a ID da VPC, as IDs da sub-rede e a ID do grupo de segurança ao registrar a VPC no Databricks.

Requisitos da VPC

Sua VPC deve atender aos requisitos descritos nesta seção para hospedar um workspace do Databricks.

Região da VPC

Para ver uma lista de regiões da AWS compatíveis com VPC gerenciado pelo cliente, consulte Recursos com disponibilidade regional limitada.

Dimensionamento da VPC

É possível compartilhar uma VPC com vários workspaces em uma única conta da AWS. No entanto, o Databricks recomenda o uso de sub-redes e grupos de segurança exclusivos para cada workspace. Certifique-se de dimensionar sua VPC e sub-redes adequadamente. O Databricks atribui dois endereços IP por nó, um para tráfego de gerenciamento e outro para aplicações Apache Spark. O número total de instâncias para cada sub-rede é igual à metade do número de endereços IP disponíveis. Saiba mais em Sub-redes.

Intervalos de endereços IP da VPC

O Databricks não limita as máscaras de rede para a VPC do workspaces mas cada sub-rede do workspace deve ter uma máscara de rede entre /17 e /26. Isso significa que, se seu workspace tiver duas sub-redes e ambas tiverem uma máscara de rede de /26, então a máscara de rede para sua VPC do workspace deverá ser /25 ou menor.

Importante

Se você configurou blocos de CIDR secundários para sua VPC, certifique-se de que as sub-redes do workspace do Databricks estejam configuradas com o mesmo bloco de CIDR da VPC.

DNS

A VPC deve ter hostnames DNS e resolução de DNS habilitados.

Sub-redes

O Databricks deve ter acesso a pelo menos duas sub-redes para cada workspace, com cada sub-rede em uma zona de disponibilidade diferente. Não é possível especificar mais de uma sub-rede de workspace do Databricks por zona de disponibilidade em Criar chamada da API de configuração da rede. É possível ter mais de uma sub-rede por zona de disponibilidade como parte de sua configuração de rede, mas só é possível escolher uma sub-rede por zona de disponibilidade para o workspace do Databricks.

Você pode optar por compartilhar uma sub-rede em vários workspaces ou ambas as sub-redes entre workspaces. Por exemplo, você pode ter dois workspaces que compartilham o mesmo VPC. Um workspace pode usar sub-redes A e B e outros workspaces podem usar sub-redes A e C. Se você planeja compartilhar sub-redes entre vários workspaces, dimensione seu VPC e sub-redes para que sejam grandes o suficiente para escalar com o uso.

O Databricks atribui dois endereços IP por nó, um para tráfego de gerenciamento e outro para aplicativos Spark. O número total de instâncias para cada sub-rede é igual à metade do número de endereços IP disponíveis.

Cada sub-rede deve ter uma máscara de rede entre /17 e /26.

Requisitos adicionais de sub-rede

  • As sub-redes devem ser privadas.

  • As sub-redes devem ter acesso de saída à rede pública por meio de um gateway NAT e um gateway da Internet ou outra infraestrutura semelhante de dispositivo gerenciado pelo cliente.

  • O gateway NAT deve ser configurado em sua própria sub-rede que roteia o tráfego quad-zero (0.0.0.0/0) para um gateway da Internet ou outra infraestrutura de dispositivo gerenciado pelo cliente.

Importante

Os workspaces devem ter acesso de saída da VPC para a rede pública. Se você configurar listas de acesso IP, essas redes públicas deverão ser adicionadas a uma lista de permissões. Consulte Configurar listas de acesso IP para workspaces.

Tabela de roteamento de sub-redes

A tabela de roteamento para sub-redes do workspace deve ter tráfego quad-zero (0.0.0.0/0) direcionado ao dispositivo de rede apropriado. O tráfego quad-zero deve ter como alvo um gateway NAT ou seu próprio dispositivo NAT gerenciado ou dispositivo proxy.

Importante

O Databricks exige que as sub-redes adicionem 0.0.0.0/0 à lista de permissões. Essa regra deve ser priorizada. Para controlar o tráfego de saída, use um firewall de saída ou um dispositivo proxy para bloquear a maior parte do tráfego, mas autorize os URLs aos quais o Databricks precisa se conectar. Consulte Configurar um firewall e acesso de saída.

Esta é apenas uma diretriz básica. Seus requisitos de configuração podem ser diferentes. Em caso de dúvidas, entre em contato com sua equipe de conta do Databricks.

Grupos de segurança

Um workspace do Databricks deve ter acesso a pelo menos um grupo de segurança da AWS e no máximo cinco grupos de segurança. Você pode reutilizar grupos de segurança existentes em vez de criar novos. No entanto, o Databricks recomenda o uso de sub-redes e grupos de segurança exclusivos para cada workspace.

Os grupos de segurança devem ter as seguintes regras:

Egresso (saída):

  • Autorizar todo o acesso de TCP e UDP ao grupo de segurança do workspace (para tráfego interno)

  • Autorizar o acesso de TCP a 0.0.0.0/0 para estas portas:

    • 443: para a infraestrutura do Databricks, fontes de dados em nuvem e repositórios de bibliotecas

    • 3306: para o metastore

    • 6666: para conectividade de cluster segura. Isso será necessário somente se você usar o PrivateLink.

    • 2443: compatível com criptografia FIPS. Necessário apenas se você habilitar o perfil de segurança de conformidade.

    • 8443: para chamadas internas do plano de computação do Databricks para a API do plano de controle do Databricks.

    • 8444: para registro do Unity Catalog e transmissão de dados de linhagem para o Databricks.

    • 8445 a 8451: Possibilidade de extensão futura.

Ingresso (entrada): obrigatório para todos os workspaces (podem ser regras separadas ou combinadas em uma):

  • Permitir TCP em todas as portas quando a origem do tráfego usar o mesmo grupo de segurança

  • Permitir UDP em todas as portas quando a origem do tráfego usar o mesmo grupo de segurança

ACLs de rede em nível da sub-rede

As ACLs de rede em nível de sub-rede não devem negar a entrada ou a saída de nenhum tráfego. O Databricks valida as seguintes regras ao criar o workspace:

Egresso (saída):

  • Autorizar todo o tráfego para CIDR da VPC do workspace para tráfego interno

    • Autorizar o acesso de TCP a 0.0.0.0/0 para estas portas:

      • 443: para a infraestrutura do Databricks, fontes de dados em nuvem e repositórios de bibliotecas

      • 3306: para o metastore

      • 6666: necessário somente se você usar o PrivateLink

Importante

Se você configurar as regras ALLOW ou DENY adicionais para tráfego de saída, defina as regras exigidas pelo Databricks com a prioridade mais alta (os números de regra mais baixos), para que tenham precedência.

Ingresso (entrada):

  • ALLOW ALL from Source 0.0.0.0/0. Esta regra deve ser priorizada.

Observação

O Databricks exige ACLs de rede em nível de sub-rede para adicionar 0.0.0.0/0 à sua lista de permissões. Para controlar o tráfego de saída, use um firewall de saída ou um dispositivo proxy para bloquear a maior parte do tráfego, mas autorize os URLs aos quais o Databricks precisa se conectar. Consulte Configurar um firewall e acesso de saída.

Criar uma VPC

Para criar VPCs, é possível usar várias ferramentas:

Para usar o Console da AWS, as instruções básicas para criar e configurar uma VPC e objetos relacionados estão listadas abaixo. Para obter instruções completas, consulte a documentação da AWS.

Observação

Essas instruções básicas podem não se aplicar a todas as organizações. Seus requisitos de configuração podem ser diferentes. Esta seção não cobre todas as formas possíveis de configurar NATs, firewalls ou outras infraestruturas de rede. Se você tiver dúvidas, entre em contato com a equipe de contas da Databricks antes de prosseguir.

  1. Acessar a página de VPCs na AWS.

  2. Veja o seletor de regiões no canto superior direito. Se necessário, mude para a região de seu workspace.

  3. No canto superior direito, clique no botão laranja Criar VPC.

    criar novo editor de VPCs

  4. Clique em VPC e mais.

  5. Na Geração automática de tag de nome, digite um nome para seu workspace. A Databricks recomenda incluir a região no nome.

  6. É possível alterar o intervalo de endereços da VPC, se você desejar.

  7. Para sub-redes públicas, clique em 2. Essas sub-redes não são usadas diretamente pelo seu workspace do Databricks, mas são necessárias para habilitar NATs nesse editor.

  8. Para sub-redes privadas, clique em 2 para o mínimo de sub-redes de workspaces. Você pode adicionar mais, se desejar.

    Seu workspace do Databricks precisa de pelo menos duas sub-redes privadas. Para redimensioná-las, clique em Personalizar blocos CIDR de sub-rede.

  9. Para gateways NAT, clique em In 1 AZ.

  10. Certifique-se de que os seguintes campos na parte inferior estejam ativados: Ativar hostnames de DNS e Ativar resolução de DNS.

  11. Clique em Criar VPC.

  12. Ao visualizar sua nova VPC, clique nos itens de navegação à esquerda para atualizar as configurações relacionadas na VPC. Para facilitar a localização de objetos relacionados, no campo Filtrar por VPC, selecione sua nova VPC.

  13. Clique em Sub-redes e selecione as sub-redes privadas rotuladas como 1 e 2, que são as que você usará para configurar suas principais sub-redes de workspace. Modifique as sub-redes conforme especificado nos requisitos de VPC.

    Se você criou uma sub-rede privada extra para usar com o PrivateLink, configure a sub-rede privada 3 conforme especificado em Ativar conectividade privada usando o AWS PrivateLink.

  14. Clique em Grupos de segurança e modifique o grupo de segurança conforme especificado em Grupos de segurança.

    Se você usar a conectividade PrivateLink de back-end, crie um grupo de segurança adicional com regras de entrada e saída, conforme especificado no artigo PrivateLink na seção Etapa 1: configurar objetos de rede da AWS.

  15. Clique em ACLs de rede e modifique as ACLs de rede, conforme especificado em ACLs de rede em nível de sub-rede.

  16. Escolha se deseja executar as configurações opcionais especificadas posteriormente neste artigo.

  17. Registre sua VPC com o Databricks para criar uma configuração de rede utilizando o console da conta ou a API da conta.

Atualização de CIDRs

Pode ser necessário, posteriormente, atualizar os CIDRs de sub-rede que se sobrepõem às sub-redes originais.

Para atualizar os CIDRs e outros objetos de workspaces:

  1. Encerre todos os clusters em execução (e outros recursos de computação) em execução nas sub-redes que precisam ser atualizadas.

  2. Utilizando o Console da AWS, exclua as sub-redes a serem atualizadas.

  3. Recrie as sub-redes com intervalos de CIDR atualizados.

  4. Atualize a associação da tabela de roteamento para as duas novas sub-redes. É possível reutilizar aquelas em cada zona de disponibilidade para as sub-redes existentes.

    Importante

    Se você pular essa etapa ou configurar incorretamente as tabelas de roteamento, o cluster poderá falhar ao ser iniciado.

  5. Crie um novo objeto de configuração de rede com as novas sub-redes.

  6. Atualize o workspace que usará esse objeto de configuração de rede recém-criado

Configurar um firewall e acesso de saída

Você deve usar um firewall de saída ou um dispositivo proxy para bloquear a maior parte do tráfego, mas autorize os URLs aos quais o Databricks precisa se conectar:

  • Se o firewall ou dispositivo proxy estiver na mesma VPC que a VPC do workspace do Databricks, roteie o tráfego e o configure para permitir as seguintes conexões.

  • Se o firewall ou dispositivo proxy estiver em outra VPC ou em uma rede on-premises, roteie 0.0.0.0/0 para essa VPC ou rede primeiro e configure o dispositivo proxy para permitir as seguintes conexões.

Importante

A Databricks recomenda enfaticamente que você especifique destinos como nomes de domínio em sua infraestrutura de egresso, em vez de endereços IP.

Permita as seguintes conexões de saída. Para cada tipo de conexão, siga o link para obter endereços IP ou domínios para a região de seu workspace.

  • Aplicativo da web do Databricks: obrigatório. Também usado para chamadas de API REST para seu workspace.

    Endereços do plano de controle do Databricks

  • Relé de conectividade segura de cluster (SCC) da Databricks: necessário para a conectividade segura do cluster.

    Endereços do plano de controle do Databricks

  • URL global do AWS S3: obrigatório pelo Databricks para acessar o bucket raiz do S3. Use s3.amazonaws.com:443, independentemente da região.

  • URL regional do AWS S3: opcional. Se o senhor usar buckets do S3 que possam estar em outras regiões, também deverá permitir o endpoint regional do S3. Embora a AWS forneça um domínio e uma porta para um endpoint regional (s3.<region-name>.amazonaws.com:443), a Databricks recomenda que você use um endpoint da VPC para que esse tráfego passe pelo túnel privado pelo backbone de rede da AWS. Consulte (Recomendado) Configurar endpoints regionais.

  • URL global do AWS STS: Obrigatório. Use o seguinte endereço e porta, independentemente da região: sts.amazonaws.com:443

  • URL regional do AWS STS: obrigatório devido à mudança esperada para o endpoint regional. Use um endpoint da VPC. Consulte (Recomendado) Configurar endpoints regionais.

  • URL regional do AWS Kinesis: necessário. O endpoint do Kinesis é usado para capturar logs necessários para gerenciar e monitorar o software. Para ver o URL de sua região, consulte Endereços do Kinesis.

  • URL regional do RDS do metastore da tabela (por região do plano de computação): obrigatório se seu workspace do Databricks usar o Hive metastore.

    O Hive metastore está sempre na mesma região que seu plano de computação, mas pode estar em uma região diferente do plano de controle.

    Endereços RDS para Hive metastore legado

    Observação

    Em vez de usar o Hive metastore default, você pode optar por implementar sua própria instância de metastore de tabela e, nesse caso, você é responsável pelo roteamento de rede.

  • Infraestrutura do plano de controle: obrigatório. Utilizado pelo Databricks para infraestrutura de standby do Databricks para aumentar a estabilidade dos serviços do Databricks.

    Endereços do plano de controle do Databricks

Solucionar problemas de endpoints regionais

Se você seguiu as instruções acima e os endpoints da VPC não funcionarem conforme o esperado, como por exemplo, se suas fontes de dados estiverem inacessíveis ou se o tráfego estiver ignorando os endpoints, você pode usar uma das duas abordagens para adicionar compatibilidade com os endpoints regionais para S3 e STS em vez de usar endpoints da VPC.

  1. Adicione a variável de ambiente AWS_REGION na configuração do cluster e defina-a para sua região da AWS. Para habilitá-la em todos os clusters, use políticas de cluster. Talvez você já tenha configurado essa variável de ambiente para usar montagens DBFS.

  2. Adicione a configuração necessária do Apache Spark. Adote exatamente uma das seguintes abordagens:

    • Em cada notebook de origem:

      %scala
spark.conf.set("fs.s3a.stsAssumeRole.stsEndpoint", "https://sts.<region>.amazonaws.com")
spark.conf.set("fs.s3a.endpoint", "https://s3.<region>.amazonaws.com")

      %python
spark.conf.set("fs.s3a.stsAssumeRole.stsEndpoint", "https://sts.<region>.amazonaws.com")
spark.conf.set("fs.s3a.endpoint", "https://s3.<region>.amazonaws.com")

    • Ou então, na configuração do Apache Spark para o cluster*:

      spark.hadoop.fs.s3a.endpoint https://s3.<region>.amazonaws.com
spark.hadoop.fs.s3a.stsAssumeRole.stsEndpoint https://sts.<region>.amazonaws.com

  3. Se você limitar o egresso do plano de computação clássico usando um firewall ou dispositivo de Internet, adicione esses endereços de endpoints regionais à sua lista de permissões.

Para definir esses valores para todos os clusters, configure os valores como parte da sua política de cluster.

(Opcional) Acesse o S3 usando perfis de instâncias

Para acessar montagens do S3 usando perfis de instâncias, defina as seguintes configurações do Spark:

  • Em cada notebook de origem:

    %scala
spark.conf.set("fs.s3a.stsAssumeRole.stsEndpoint", "https://sts.<region>.amazonaws.com")
spark.conf.set("fs.s3a.endpoint", "https://s3.<region>.amazonaws.com")

    %python
spark.conf.set("fs.s3a.stsAssumeRole.stsEndpoint", "https://sts.<region>.amazonaws.com")
spark.conf.set("fs.s3a.endpoint", "https://s3.<region>.amazonaws.com")

  • Ou na configuração do Apache Spark para o cluster:

    spark.hadoop.fs.s3a.endpoint https://s3.<region>.amazonaws.com
spark.hadoop.fs.s3a.stsAssumeRole.stsEndpoint https://sts.<region>.amazonaws.com

Para definir esses valores para todos os clusters, configure os valores como parte da sua política de cluster.

Aviso

Para o serviço S3, há limitações para aplicar configurações de endpoints regionais adicionais em nível de notebook ou de cluster. Especificamente, o acesso ao S3 entre regiões é bloqueado, mesmo que a URL global do S3 seja permitida em seu firewall de egresso ou proxy. Se sua implantação do Databricks exigir acesso S3 entre regiões, é importante que você não aplique a configuração do Spark em nível de notebook ou de cluster.

(Opcional) Restringir acesso aos buckets do S3

A maioria das leituras e gravações no S3 são independentes no plano de computação. No entanto, algumas operações de gerenciamento se originam do plano de controle, que é gerenciado pela Databricks. Para limitar o acesso aos buckets do S3 a um conjunto específico de endereços IP de origem, crie uma política de bucket do S3. Na política de bucket, inclua os endereços IP na lista aws:SourceIp . Se você usa um endpoint de VPC, permita o acesso a ele adicionando-o ao aws:sourceVpce da política. A Databricks usa IDs de VPC para acessar buckets S3 na mesma região que o plano de controle da Databricks e IPs NAT para acessar buckets S3 em regiões diferentes do plano de controle.

Para mais informações sobre policies de bucket do S3, consulte os exemplos de policies de bucket na documentação do Amazon S3. Exemplos funcionais de policies de bucket também estão incluídos neste tópico.

Requisitos para políticas de buckets

Sua política de buckets deve atender a esses requisitos para garantir que os clusters sejam iniciados corretamente e que você possa se conectar a eles:

Observação

Ao implantar um novo workspace com restrições de políticas de buckets do S3, você deve permitir o acesso ao NAT-IP do ambiente de controle para uma região us-west ; caso contrário, a implantação falhará. Depois que o workspace for implantado, você poderá remover as informações do us-west e atualizar o NAT-IP do painel de controle para refletir sua região.

IPs e buckets de armazenamento necessários

Para os endereços IP e domínios necessários para configurar políticas de buckets do S3 e políticas de endpoints de VPC para restringir o acesso aos buckets do S3 de seu workspace, consulte IPs de saída do plano de controle do Databricks.

Exemplo de políticas de buckets

Esses exemplos usam texto de espaço reservado para indicar onde especificar os endereços IP recomendados e os buckets de armazenamento necessários. Revise os requisitos para garantir que seus clusters sejam iniciados corretamente e que você possa se conectar a eles.

Restrinja o acesso ao plano de controle do Databricks, ao plano de computação e aos IPs confiáveis:

Essa política de buckets do S3 usa uma condição Deny para permitir seletivamente o acesso a partir do plano de controle, do gateway NAT e dos endereços IP da VPN corporativa que você especificar. Substitua o texto do espaço reservado por valores para seu ambiente. É possível adicionar qualquer número de endereços IP à política. Crie uma política por bucket do S3 que você deseja proteger.

Importante

Se você usa endpoints da VPC, essa política não estará completa. Consulte Restringir o acesso ao plano de controle do Databricks, aos endpoints da VPC e aos IPs confiáveis.

{
  "Sid": "IPDeny",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::<S3-BUCKET>",
    "arn:aws:s3:::<S3-BUCKET>/*"
  ],
  "Condition": {
    "NotIpAddress": {
      "aws:SourceIp": [
        "<CONTROL-PLANE-NAT-IP>",
        "<DATA-PLANE-NAT-IP>",
        "<CORPORATE-VPN-IP>"
      ]
    }
  }
}

Restringir o acesso ao plano de controle do Databricks, aos endpoints da VPC e aos IPs confiáveis:

Se você usa um endpoint de VPC para acessar o S3, deverá adicionar uma segunda condição à política. Essa condição permite o acesso de seu endpoint de VPC e da ID de VPC adicionando-os à lista aws:sourceVpce.

Esse bucket permite seletivamente o acesso a partir de seu endpoint da VPC e dos endereços IP do plano de controle e da VPN corporativa que você especificar.

Ao usar endpoints de VPC, você pode usar uma política de endpoints de VPC em vez de uma política de buckets S3. Uma política de VPCE deve permitir acesso ao seu bucket S3 raiz e ao bucket de artefatos, logs e conjuntos de dados compartilhados necessários para sua região. Para obter os endereços IP e domínios de suas regiões, consulte Endereços IP e domínios para serviços e ativos do Databricks.

Substitua o texto do espaço reservado por valores para seu ambiente.

{
  "Sid": "IPDeny",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::<S3-BUCKET>",
    "arn:aws:s3:::<S3-BUCKET>/*"
  ],
  "Condition": {
    "NotIpAddressIfExists": {
      "aws:SourceIp": [
        "<CONTROL-PLANE-NAT-IP>",
        "<CORPORATE-VPN-IP>"
      ]
    },
    "StringNotEqualsIfExists": {
      "aws:sourceVpce": "<VPCE-ID>",
      "aws:SourceVPC": "<VPC-ID>"
    }
  }
}