Configurar uma VPC gerenciada pelo cliente

Visão geral

Por default, os clusters são criados em um único AWS VPC (nuvens virtuais privadas) que o Databricks cria e configura em sua account AWS. Opcionalmente, você pode criar seu espaço de trabalho do Databricks em sua própria VPC, um recurso conhecido como VPC gerenciado pelo cliente. Você pode usar uma VPC gerenciada pelo cliente para exercer mais controle sobre suas configurações de rede para estar em conformidade com padrões específicos de segurança e governança de nuvens que sua organização pode exigir. Para configurar seu workspace para usar o AWS PrivateLink para qualquer tipo de conexão, seu workspace deve usar uma VPC gerenciada pelo cliente.

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 um novo VPC, no qual o VPC é configurado e protegido 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 mais baixo: você mantém mais controle da 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 Databricks em sua pilha de plataforma.

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

  • Consolidação de VPCs: Vários espaços de trabalho do Databricks podem compartilhar um único VPC de plano clássico compute, que geralmente é preferido para faturamento e gerenciamento de instâncias.

  • Limitar as conexões de saída: Por default, o plano clássico compute não limita as conexões de saída do Databricks Runtime worker. Para o espaço de trabalho configurado para usar uma VPC gerenciada pelo cliente, o senhor pode usar um firewall de saída ou um dispositivo proxy para limitar o tráfego de saída a uma lista de fontes de dados internas ou externas permitidas.

VPC gerenciado pelo cliente

Para aproveitar uma VPC gerenciada pelo cliente, você deve especificar uma VPC ao criar o Databricks workspace 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 o VPC seguindo os requisitos enumerados em Requisitos do VPC.

  2. Referenciar sua configuração de rede VPC com Databricks quando 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

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

Região da VPC

Para ver uma lista de regiões da AWS compatíveis com VPC gerenciada pelo cliente, consulte Nuvens e regiões do Databricks.

Dimensionamento de VPC

Você pode compartilhar uma VPC com vários workspace em uma única account da AWS. No entanto, a Databricks recomenda a utilização de sub-redes e grupos de segurança exclusivos para cada workspace. Certifique-se de dimensionar sua VPC e sub-redes de acordo. O Databricks atribui dois endereços IP por nó, um para gerenciamento de tráfego 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 o workspace VPC, mas cada sub-rede do workspace deve ter uma máscara de rede entre /17 e /26. Isso significa que, se o seu workspace tiver duas sub-redes e ambas tiverem uma máscara de rede de /26, a máscara de rede para seu workspace VPC deverá ser /25 ou menor.

Importante

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

DNS

A VPC deve ter nomes de host 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. Você não pode especificar mais de uma sub-rede de workspace do Databricks por zona de disponibilidade na chamada de API de configuração de rede Create. Você pode ter mais de uma sub-rede por zona de disponibilidade como parte de sua configuração de rede, mas pode escolher somente uma sub-rede por zona de disponibilidade para o Databricks workspace.

Você pode optar por compartilhar uma sub-rede em vários espaços de trabalho ou ambas as sub-redes em vários espaços de trabalho. Por exemplo, você pode ter dois espaços de trabalho que compartilham a mesma VPC. Uma workspace pode usar as sub-redes A e B e outra área de trabalho pode usar as sub-redes A e C. Se você planeja compartilhar sub-redes em vários espaços de trabalho, dimensione sua VPC e suas sub-redes para que sejam grandes o suficiente para serem escalonadas 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 Internetou 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

O espaço de trabalho deve ter acesso de saída da VPC para a rede pública.

Tabela de roteamento de sub-rede

A tabela de rotas para as sub-redes workspace deve ter tráfego quad-zero (0.0.0.0/0) que tenha como alvo o dispositivo de rede apropriado. O tráfego quad-zero deve ser direcionado a um gateway NAT ou ao seu próprio dispositivo NAT gerenciável ou dispositivo proxy.

Importante

A Databricks exige que as sub-redes adicionem 0.0.0.0/0 à sua 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 permita 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 account 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, a Databricks recomenda a utilização de sub-redes e grupos de segurança exclusivos para cada workspace.

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

Transferência (saída):

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

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

Transferência (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 no nível da sub-rede

As ACLs de rede no nível da 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:

Transferência (saída):

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

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

      • 443: para infraestrutura 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 regras ALLOW ou DENY adicionais para tráfego de saída, defina as regras exigidas pelo Databricks para a prioridade mais alta (os números de regra mais baixos), para que tenham precedência.

Entrada (entrada):

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

Observação

O Databricks requer 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 permita os URLs aos quais o Databricks precisa se conectar. Consulte Configurar um firewall e acesso de saída.

Criar uma VPC

Para criar VPCs você pode usar várias ferramentas:

Para usar o Console 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

Estas 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 tiver dúvidas, entre em contato com sua equipe account do Databricks antes de continuar.

  1. Acesse 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 do seu workspace.

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

    criar novo editor de VPC

  4. Clique em VPC e mais.

  5. Na geração automática de marca de nome, digite um nome para sua área de trabalho. A Databricks recomenda incluir a região no nome.

  6. Para o intervalo de endereços VPC, altere-o opcionalmente, se desejar.

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

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

    O seu workspace Databricks precisa de pelo menos duas sub-redes privadas. Para redimensioná-los, clique em Personalizar blocos CIDR de sub-rede.

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

  10. É importante que os seguintes campos na parte fundo estejam ativados: Ativar nomes de host DNS e Ativar resolução DNS.

  11. Clique em Criar VPC.

  12. Ao visualizar seu novo VPC, clique nos itens de navegação à esquerda para atualizar as configurações relacionadas no VPC. Para facilitar a localização de objetos relacionados, no campo Filter by VPC , selecione seu novo VPC.

  13. Clique em Sub-redes e no que a AWS chama de rótulos de sub-redes privadas 1 e 2, que são os que você usará para configurar as principais sub-redes do seu workspace . Modifique as sub-redes conforme especificado em Requisitos de VPC.

    Se você criou uma sub-rede privada extra para usar com PrivateLink, configure a sub-rede privada 3 conforme especificado em Ativar 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 Passo 1: configurar objetos de rede da AWS.

  15. Clique em Network ACLs e modifique as network ACLs conforme especificado em Subnet-level network ACLs.

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

  17. Registre seu VPC com Databricks para criar uma configuração de rede utilizando o console de conta ou a API de 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 do workspace:

  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 AWS, exclua as sub-redes a serem atualizadas.

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

  4. Atualize a associação da tabela de roteamento para as duas novas sub-redes. Você pode reutilizar as de cada zona de disponibilidade para sub-redes existentes.

    Importante

    Se você pular esta passo 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 a usar esse objeto de configuração de rede recém-criado

Configurar um firewall e acesso de saída

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

  • Se o dispositivo de firewall ou proxy estiver no mesmo VPC que o VPC do Databricks workspace, 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 local, encaminhe 0.0.0.0/0 para essa VPC ou rede primeiro e configure o dispositivo proxy para autorizar as conexões seguintes.

Importante

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

Permitir 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 sua região de 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 de clusters seguros (SCC) do Databricks: Necessário para a conectividade segura de clusters.

    Endereços do plano de controle do Databricks

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

  • URL regional AWS S3: opcional. Se você 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 VPC para que esse tráfego passe pelo túnel privado pelo backbone da rede AWS. Consulte (Recomendado) Configurar endpointregional.

  • 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 endpoint regional. Use um endpoint VPC. Consulte (Recomendado) Configurar endpointregional.

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

  • URL regional RDS do metastore de tabela (por compute região do plano ): necessário se o seu do Databricks workspace usar o default Hive metastore.

    O Hive metastore está sempre na mesma região que o seu plano compute , mas pode estar numa região diferente do plano de controlo.

    Endereços RDS para Hive metastore

    Observação

    Em vez de usar o default Hive metastore, 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. Usado pelo Databricks para infraestrutura standby do Databricks para melhorar a estabilidade do serviço Databricks.

    Endereços do plano de controle do Databricks

Solucionar problemas endpointregional

Se você seguiu as instruções acima e o VPC endpoint não funcionar conforme o esperado, por exemplo, se sua fonte de dados estiver inacessível ou se o tráfego estiver ignorando o endpoint, você poderá usar uma das duas abordagens para adicionar suporte ao endpoint regional para S3 e STS em vez de usar endpoint VPC.

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

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

    • Em cada Notebookde 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")

    • Alternativamente, na configuração do Apache Spark para os clusters*:

      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 a saída do plano compute clássico usando um firewall ou um dispositivo de Internet, adicione esses endereços de endpoint regionais à sua lista de permissões.

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

(Opcional) Acesse o S3 usando instance profile

Para acessar montagens do S3 usando instance profile, 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 os clusters:

    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 como parte de sua política de cluster.

Aviso

Para o serviço S3, há limitações para a aplicação de configurações adicionais de endpoint regional no nível de Notebook ou clusters . Notavelmente, o acesso ao S3 entre regiões é bloqueado, mesmo que a URL global do S3 seja permitida em seu firewall ou proxy de saída. Se a sua implantação do Databricks exigir acesso S3 entre regiões, é importante que você não aplique a configuração do Spark no nível do Notebook ou clusters .

(Opcional) Restringir o acesso aos buckets S3

A maioria das leituras e gravações no S3 são independentes no plano compute . Porém, algumas operações de gerenciamento originam-se do plano de controle, que é gerenciado pelo Databricks. Para limitar o acesso aos buckets do S3 a um conjunto especificado 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ê usar um VPC endpoint, permita acesso a ele adicionando-o ao aws:sourceVpce da política.

Para obter mais informações sobre as políticas de bucket do S3, consulte os exemplos de políticas de bucket na documentação do Amazon S3. Exemplos de políticas de balde em funcionamento também estão incluídos neste tópico.

Requisitos para políticas de bucket

Sua política de bucket deve atender a estes requisitos para garantir que seus clusters comecem corretamente e que você possa se conectar a eles:

Observação

Ao implementar um novo workspace com restrições de política de bucket S3, você deve permitir acesso ao plano de controle NAT-IP 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 us-west e atualizar o NAT-IP do plano de controle para refletir sua região.

IPs e buckets de armazenamento necessários

Para obter os endereços IP e os domínios necessários para configurar as políticas de bucket S3 e as políticas VPC endpoint para restringir o acesso aos buckets workspace's S3, consulte Saída do plano de controle Databricks .

Exemplos de políticas de bucket

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

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

Essa política de bucket do S3 usa uma condição Deny para permitir seletivamente o acesso do plano de controle, do gateway NAT e dos endereços IP de VPN corporativos especificados. Substitua o texto do espaço reservado pelos valores do seu ambiente. Você pode adicionar qualquer número de endereços IP à política. Crie uma política por bucket S3 que você deseja proteger.

Importante

Se você usar o VPC endpoint, esta política não estará completa. Consulte Restringir o acesso ao plano de controle do Databricks, endpoint 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>"
      ]
    }
  }
}

Restrinja o acesso ao plano de controle do Databricks, endpoint VPC e aos IPs confiáveis:

Se você usar um VPC endpoint para acessar o S3, deverá adicionar uma segunda condição à política. Esta condição permite o acesso do seu VPC endpoint adicionando-o à lista aws:sourceVpce.

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

Ao usar o VPC endpoint, você pode usar uma política de VPC endpoint em vez de uma política de bucket S3. Uma política VPCE deve permitir acesso ao bucket raiz do S3 e também ao artefato, logs e ao bucket dataset compartilhado necessários para sua região. Você pode aprender sobre as políticas do VPC Endpoint na documentação da AWS.

Substitua o texto do espaço reservado pelos valores do 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>"
    }
  }
}