Configurar regras de firewall e acesso à Internet

Neste documento, explicamos como concluir as seguintes tarefas:

• Configurar instâncias de máquina virtual (VM) do Dataflow para acesso à Internet
• Use tags para proteger a rede da VM de worker.
• Defina regras de firewall para a rede associada aos jobs do Dataflow.

Neste documento, você precisa ter conhecimento básico das redes do Google Cloud . Para definir uma rede para o job do Dataflow, consulte Especificar a rede e a sub-rede. Para mais informações sobre como solucionar problemas de rede, consulte Resolver problemas de rede do Dataflow.

Observação: a rede default tem configurações que permitem a execução de jobs do Dataflow. No entanto, outros serviços também podem usar essa rede. Certifique-se de que as alterações na rede default sejam compatíveis com todos os seus serviços. Se preferir, crie uma rede separada para o Dataflow.

Acesso às APIs do Google Cloud para o Dataflow

As máquinas virtuais (VMs) de worker do Dataflow precisam acessar as APIs e os serviços doGoogle Cloud . O conjunto de endpoints dependentes do Google Cloud pode mudar ao longo do tempo, mas todos são compatíveis com o VPC Service Controls. Use um dos seguintes métodos para configurar o acesso às APIs do Google Cloud :

• Configure Acesso privado do Google. Com o Acesso privado do Google, as VMs que têm apenas endereços IP internos podem acessar endereços IP para Google Cloud e serviços.

• Configure um endereço IP de endpoint do Private Service Connect para acessar as APIs e os serviços do Google Cloud .

• Configure VMs de worker com endereços IP externo.

Por padrão, as regras de firewall e as configurações de DNS permitem o acesso às APIs doGoogle Cloud . No entanto, talvez você esteja restringindo ativamente o acesso a um subconjunto de APIs do Google Cloud , como se estivesse usando o VPC Service Controls. Nesse caso, forneça acesso, no mínimo, a restricted.googleapis.com. Se você estiver usando o Private Service Connect, forneça acesso ao pacote vpc-sc. Fornecer acesso a domínios mais permissivos, como private.googleapis.com, também fornece a funcionalidade necessária.

Para permitir o acesso às APIs necessárias do Google Cloud por um determinado domínio, seu ambiente precisa atender aos seguintes requisitos:

• As regras de firewall precisam permitir a saída para todos os intervalos de endereços no domínio escolhido.

• O DNS precisa resolver *.googleapis.com para o domínio escolhido.

Por exemplo, se as regras de firewall limitarem a saída ao intervalo de endereços restricted.googleapis.com, *.googleapis.com precisará ser resolvido para endereços dentro desse intervalo. Para mais informações, consulte Configurar o DNS para googleapis.com.

Da mesma forma, se você estiver usando o Private Service Connect, será necessário criar registros DNS para o domínio padrão googleapis.com para garantir o acesso a pelo menos todos os serviços no pacote vpc-sc.

Acesso à Internet para o Dataflow

Dependendo do caso de uso, as VMs também podem precisar de acesso a recursos fora do Google Cloud. Use um dos seguintes métodos para configurar o acesso à Internet para o Dataflow:

• Configure VMs de worker com um endereço IP externo para que atendam aos requisitos de acesso à Internet.

• Configure uma solução NAT, como o Cloud NAT. Essa opção é para executar jobs que acessam APIs e serviços fora do Google Cloud que exigem acesso à Internet. Por exemplo, os jobs do SDK do Python podem exigir acesso ao índice de pacote do Python (PyPI) para fazer o download das dependências dos pipelines. Nesse caso, configure VMs de worker com endereços IP externos ou use o Cloud NAT. Também é possível fornecer dependências de pipeline do Python durante o envio do job. Por exemplo, é possível usar contêineres personalizados para fornecer dependências de pipeline do Python, o que elimina a necessidade de acessar o PyPI no ambiente de execução.

  Para mais informações, consulte Como gerenciar dependências de pipeline do Python na documentação do Apache Beam.

Desative o endereço IP externo

Por padrão, o Dataflow atribui endereços IP externos e internos aos workers. Quando você desativa os endereços IP externo, o job do Dataflow só pode acessar recursos nos seguintes locais:

• outra instância na mesma rede VPC;
• Uma rede VPC compartilhada
• Uma rede com Peering de rede VPC habilitado

Sem endereços IP externos, ainda é possível executar tarefas administrativas e de monitoramento. Você pode acessar seus workers usando o SSH por meio das opções listadas na lista anterior. No entanto, o pipeline não pode acessar a Internet e os hosts da Internet não podem acessar seus workers do Dataflow.

Ao não usar endereços IP externo, você pode proteger melhor sua infraestrutura de processamento de dados. Também é possível reduzir o número de endereços IP externo consumidos em relação à cota do projeto Google Cloud.

Se você desativar os endereços IP externo, os jobs do Dataflow não poderão acessar APIs e serviços fora do Google Cloud que exigem acesso à Internet.

Para desativar endereços IP externos, siga um destes procedimentos:

Java

1. Ative o Acesso privado do Google para sua rede ou sub-rede.
2. Nos parâmetros do job do Dataflow, especifique --usePublicIps=false e --network=NETWORK-NAME ou --subnetwork=SUBNETWORK-NAME.

   Dependendo do que você escolher, substitua um destes procedimentos:

   • NETWORK-NAME: o nome da sua rede do Compute Engine
   • SUBNETWORK-NAME: o nome da sub-rede do Compute Engine.

Python

1. Para preparar todas as dependências de pacote do Python, siga as instruções de dependências do pipeline do Apache Beam.
2. Ative o Acesso privado do Google para sua rede ou sub-rede.

3. Nos parâmetros do job do Dataflow, especifique --no_use_public_ips e --network=NETWORK ou --subnetwork=SUBNETWORK.

   Dependendo do que você escolher, substitua um destes procedimentos:

   • NETWORK-NAME: o nome da sua rede do Compute Engine
   • SUBNETWORK-NAME: o nome da sub-rede do Compute Engine.

Go

1. Ative o Acesso privado do Google para sua rede ou sub-rede.

2. Nos parâmetros do job do Dataflow, especifique --no_use_public_ips e --network=NETWORK ou --subnetwork=SUBNETWORK.

   Dependendo do que você escolher, substitua um destes procedimentos:

   • NETWORK-NAME: o nome da sua rede do Compute Engine
   • SUBNETWORK-NAME: o nome da sub-rede do Compute Engine.

gcloud

1. Ative o Acesso privado do Google para sua rede ou sub-rede.

2. Ao iniciar o job do Dataflow, inclua a flag --disable-public-ips e especifique a flag --network ou --subnetwork. Use um dos seguintes comandos:

   • gcloud dataflow jobs run
   • gcloud dataflow flex-template run
   • gcloud dataflow yaml run

   O exemplo a seguir usa o comando gcloud dataflow jobs run:

   gcloud dataflow jobs run JOB_NAME \
       --gcs-location=gs://TEMPLATE_BUCKET/templates/TEMPLATE_NAME \
       --region=REGION \
       --staging-location=gs://TEMP_BUCKET/staging \
       --network=NETWORK_NAME \
       --subnetwork=SUBNETWORK_NAME \
       --disable-public-ips
   

   Substitua os seguintes valores:

   • JOB_NAME: um nome exclusivo para o job do Dataflow.
   • TEMPLATE_BUCKET e TEMPLATE_NAME: o bucket do Cloud Storage e o caminho para o arquivo de modelo.
   • REGION: a região do Dataflow em que você quer implantar o job, como us-central1.
   • TEMP_BUCKET: o bucket do Cloud Storage para arquivos temporários e binários.
   • NETWORK_NAME: o nome da rede VPC.
   • SUBNETWORK_NAME: o nome ou URL da sub-rede VPC.

API

1. Ative o Acesso privado do Google para sua rede ou sub-rede.

2. Ao iniciar o job ou modelo do Dataflow usando o método projects.locations.templates.launch da API REST do Dataflow, no objeto environment, defina o campo ipConfiguration como WORKER_IP_PRIVATE e especifique network ou subnetwork:

   POST https://dataflow.googleapis.com/v1b3/projects/PROJECT_ID/locations/REGION/templates:launch?gcsPath=gs://TEMPLATE_BUCKET/templates/TEMPLATE_NAME
   {
     "jobName": "JOB_NAME",
     "parameters": {
       "PARAM_KEY": "PARAM_VALUE"
     },
     "environment": {
       "tempLocation": "gs://TEMP_BUCKET/temp",
       "network": "NETWORK_NAME",
       "subnetwork": "SUBNETWORK_NAME",
       "ipConfiguration": "WORKER_IP_PRIVATE"
     }
   }
   

   Substitua os seguintes valores:

   • PROJECT_ID: o ID do projeto Google Cloud .
   • REGION: a região do Dataflow em que você quer implantar o job, como us-central1.
   • TEMPLATE_BUCKET e TEMPLATE_NAME: o bucket do Cloud Storage e o caminho para o arquivo de modelo.
   • JOB_NAME: um nome exclusivo para o job do Dataflow.
   • PARAM_KEY e PARAM_VALUE: todos os parâmetros de modelo exigidos pelo pipeline.
   • TEMP_BUCKET: o nome do bucket do Cloud Storage para arquivos temporários.
   • NETWORK_NAME: o nome da rede VPC.
   • SUBNETWORK_NAME: o URL ou caminho completo da sua sub-rede VPC.

   O campo ipConfiguration é do tipo WorkerIPAddressConfiguration e aceita os seguintes valores de tipo enumerado:

   • WORKER_IP_PRIVATE: os workers recebem apenas endereços IP internos. Os endereços IP públicos estão desativados. Requer o Acesso privado do Google.
   • WORKER_IP_PUBLIC: os workers recebem endereços IP públicos e internos.
   • WORKER_IP_UNSPECIFIED: usa a configuração padrão (os workers recebem endereços IP públicos e internos).

Usar tags para proteger a rede de VM de worker

Com as tags, é possível aplicar regras de firewall de rede a instâncias de VM específicas. Ao executar um job do Dataflow, é possível especificar tags para as VMs de worker do Dataflow que executam o job. Todas as regras de firewall para essas tags são aplicadas às VMs de worker do Dataflow.

O Dataflow é compatível com dois tipos de tags para rede de VMs:

• Tags seguras
• Tags de rede

Usar tags seguras com o Dataflow

As tags seguras, também chamadas de tags regidas pelo Identity and Access Management (IAM), são pares de chave-valor que você cria e gerencia no Resource Manager. Ao contrário das tags de rede, as tags seguras são compatíveis com o controle de acesso usando o IAM.

Os benefícios de usar tags seguras em vez de tags de rede incluem:

• As tags seguras impedem a modificação não autorizada de tags e as mudanças indesejadas resultantes nas regras de firewall.

• As políticas de firewall de rede global e regional são compatíveis com tags seguras. Ao usar tags seguras, é possível agrupar várias regras de firewall e atualizá-las simultaneamente, com as atualizações regidas pelos controles de acesso do IAM.

• As tags seguras são herdadas dos recursos pai na hierarquia do Google Cloud , o que permite definir tags em níveis mais altos, como o nível da organização. Para mais informações, consulte Herança de tags.

• Com as tags seguras, as regras de firewall de entrada podem incluir origens em redes VPC conectadas usando o peering de rede VPC. Para jobs do Dataflow, isso significa que uma regra de firewall pode incluir origens na rede de VM de worker e nas redes VPC com peering.

Para mais informações sobre as diferenças entre tags seguras e tags de rede, consulte Comparação entre tags e tags de rede.

Para aplicar tags seguras a um job do Dataflow, siga estas etapas:

1. Configurar tags seguras para as políticas de firewall. Para mais informações, consulte Configurar tags seguras.

2. Conceda o papel de Usuário de tag (roles/resourcemanager.tagUser) à conta de serviço do Dataflow no recurso (valores de tag). Para mais informações sobre as permissões necessárias, consulte Gerenciar tags em recursos.

3. Ao criar o job do Dataflow, use a opção de serviço use_vm_tags com o seguinte formato:

Java

--dataflowServiceOptions=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Python

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Go

--dataflow_service_options=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

gcloud

Use o comando gcloud dataflow jobs run com a opção additional-experiments. Se você estiver usando modelos flexíveis, use o comando gcloud dataflow flex-template run.

--additional-experiments=use_vm_tags=tagKeys/KEY1:tagValues/VALUE1;tagKeys/KEY2:tagValues/VALUE2

Usar tags de rede com o Dataflow

As tags de rede são atributos de texto que você pode definir em regras de firewall e anexar a VMs do Compute Engine. Ao contrário das tags seguras, as tags de rede são strings de texto. Elas não são um recurso gerenciado pelo Resource Manager.

Para aplicar tags de rede a um job do Dataflow, use o experimento use_network_tags, da seguinte maneira:

Java

--dataflowServiceOptions=use_network_tags=TAG_NAME

Python

--dataflow_service_options=use_network_tags=TAG_NAME

Go

--dataflow_service_options=use_network_tags=TAG_NAME

gcloud

Use o comando gcloud dataflow jobs run com a opção additional-experiments. Se você estiver usando modelos flexíveis, use o comando gcloud dataflow flex-template run.

--additional-experiments=use_network_tags=TAG_NAME

Especificar a tag de rede também adiciona a tag de rede padrão Dataflow às VMs do inicializador do modelo Flex.

Substitua TAG_NAME pelos nomes das tags. Se você adicionar mais de uma tag, separe cada uma com um ponto e vírgula (;), como mostrado no seguinte formato: TAG_NAME_1;TAG_NAME_2;TAG_NAME_3;....

Depois que um job é iniciado, não é possível adicionar mais tags de rede a ele.

O Dataflow sempre adiciona a tag de rede padrão dataflow a cada VM de worker que ele cria.

Consulte os limites que se aplicam às tags de rede.

Regras de firewall para o Dataflow

Com as regras de firewall, você permite ou rejeita o tráfego proveniente ou destinado às VMs. Se os jobs do Dataflow usarem o Dataflow Shuffle ou o Streaming Engine, você só precisará garantir que as regras de firewall permitam o acesso às APIs do Google Cloud . Caso contrário, você precisará configurar outras regras de firewall para que as VMs do Dataflow possam enviar e receber tráfego de rede na porta TCP 12345 para jobs de streaming e na porta TCP 12346 para jobs em lote. Um Proprietário do projeto, Editor ou administrador de segurança precisa criar as regras de firewall necessárias na rede VPC usada pelas VMs do Dataflow.

Antes de configurar regras de firewall para o Dataflow, leia os seguintes documentos:

• Visão geral das regras de firewall da VPC e Usar regras de firewall da VPC

• Visão geral das políticas de firewall hierárquicas e Usar políticas e regras de firewall hierárquicas

Ao criar regras de firewall para o Dataflow, especifique as tags de rede do Dataflow. Caso contrário, as regras de firewall serão aplicadas a todas as VMs na rede VPC.

Quando aplicável, as políticas de firewall hierárquicas são avaliadas primeiro, e essas regras têm prioridade sobre as regras de firewall da VPC. Se o job do Dataflow estiver em um projeto que faz parte de uma pasta ou organização em que as políticas de firewall hierárquicas são usadas, o papel compute.orgFirewallPolicyAdmin será necessário para fazer modificações na política.

Se você não criar tags de rede personalizadas ao executar o código do pipeline, as VMs do Dataflow vão usar a tag padrão dataflow. Na ausência de tags de rede personalizadas, crie as regras de firewall com a tag dataflow padrão.

Se você criar tags de rede personalizadas ao executar o código do pipeline, as VMs do Dataflow vão usar essas tags. Crie as regras de firewall com as tags personalizadas.

Algumas redes VPC, como a rede default criada automaticamente, incluem uma regra default-allow-internal que atende ao requisito de firewall do Dataflow.

Exemplo de regra de entrada de firewall

A regra de firewall de entrada permite que as VMs do Dataflow recebam pacotes umas das outras. É necessário sempre criar regras de firewall de permissão de entrada ou o tráfego sempre será bloqueado, mesmo que as regras de saída permitam esse tráfego.

No exemplo a seguir, uma regra de entrada de firewall é criada para o Dataflow, em que todas as VMs de worker têm a tag de rede padrão dataflow. Um proprietário do projeto, editor ou administrador de segurança pode usar o seguinte comando gcloud para criar uma regra de permissão de entrada que permita o tráfego nas portas TCP 12345 e 12346 de VMs com a tag de rede dataflow para outras VMs com a mesma tag:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_INGRESS \
    --action=allow \
    --direction=ingress \
    --network=NETWORK  \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --priority=PRIORITY_NUM \
    --rules tcp:12345-12346

Substitua:

• FIREWALL_RULE_NAME_INGRESS: um nome para a regra de firewall;

• NETWORK: o nome da rede usada pelas VMs de worker.

• CUSTOM_TAG: uma lista de tags de rede delimitada por vírgulas

  Esta é uma lista de diretrizes para o uso de tags de rede:

  • Se você omitir --target-tags, a regra se aplicará a todas as VMs na rede VPC.

  • Se você omitir --source-tags e todas as outras especificações de origem, será permitido o tráfego de qualquer origem.

  • Se você não tiver especificado tags de rede personalizadas e quiser que a regra seja específica para VMs do Dataflow, use dataflow como a tag de rede.

  • Se você especificou tags de rede personalizadas e quer que a regra seja específica para VMs do Dataflow, use suas tags de rede personalizadas.

• PRIORITY_NUM: a prioridade da regra de firewall

  Números menores têm prioridades mais altas, e 0 é a prioridade mais alta.

Exemplo de regra de saída de firewall

A regra de firewall de saída permite que as VMs do Dataflow enviem pacotes umas para as outras. Se você criou regras de firewall de negação de saída, talvez seja necessário criar regras de firewall de permissão de saída personalizadas na sua rede VPC.

Neste exemplo, uma regra de saída de firewall é criada para o Dataflow, em que todas as VMs de worker têm a tag de rede padrão dataflow. Um proprietário, editor ou administrador de segurança do projeto pode usar o seguinte comando gcloud para criar uma regra de permissão de saída que permite o tráfego das portas TCP 12345 e 12346 em VMs com a tag de rede dataflow para outras VMs com a mesma tag:

gcloud compute firewall-rules create FIREWALL_RULE_NAME_EGRESS \
    --network=NETWORK \
    --action=allow \
    --direction=egress \
    --target-tags=CUSTOM_TAG \
    --source-tags=CUSTOM_TAG \
    --destination-ranges=DESTINATION-RANGES\
    --priority=PRIORITY_NUM  \
    --rules tcp:12345-12346

Substitua:

• FIREWALL_RULE_NAME_EGRESS: um nome para a regra de firewall;

• NETWORK: o nome da rede usada pelas VMs de worker.

• CUSTOM_TAG: uma lista de tags de rede delimitada por vírgulas

  Esta é uma lista de diretrizes para o uso de tags de rede:

  • Se você omitir --target-tags, a regra se aplicará a todas as VMs na rede VPC.

  • Se você omitir --source-tags e todas as outras especificações de origem, será permitido o tráfego de qualquer origem.

  • Se você não tiver especificado tags de rede personalizadas e quiser que a regra seja específica para VMs do Dataflow, use dataflow como a tag de rede.

  • Se você especificou tags de rede personalizadas e quer que a regra seja específica para VMs do Dataflow, use suas tags de rede personalizadas.

• DESTINATION-RANGES: uma lista delimitada por vírgulas de CIDRs

  Inclua o intervalo de endereços IP primários da sub-rede selecionada.

• PRIORITY_NUM: a prioridade da regra de firewall

  Números menores têm prioridades mais altas, e 0 é a prioridade mais alta.

Para portas TCP específicas usadas pelo Dataflow, consulte o manifesto do contêiner do projeto. Esse manifesto especifica explicitamente as portas para mapear as portas do host no contêiner.

Acesso SSH às VMs de worker

O Dataflow não exige SSH. No entanto, o SSH é útil para a solução de problemas.

Se a VM de worker tiver um endereço IP externo, será possível se conectar à VM pelo console do Google Cloud ou da Google Cloud CLI. Para se conectar usando SSH, é preciso ter uma regra de firewall que permita conexões de entrada na porta TCP 22 pelo menos do endereço IP do sistema no qual você esteja executando gcloud ou do sistema que esteja executando o navegador da Web usado para acessar o console doGoogle Cloud .

Para visualizar a configuração de rede e a atividade, abra uma sessão SSH em um worker e execute iproute2. Para mais informações, consulte a página iproute2 no wiki da Linux Foundation.

Se você precisar se conectar a uma VM de worker que tenha apenas um endereço IP interno, consulte Escolha uma opção de conexão para VMs somente internas.

A seguir

• Saiba mais sobre os Testes de conectividade Os Testes de conectividade são uma ferramenta de diagnóstico que permite verificar a conectividade entre os endpoints da rede.
• Criar e executar testes de conectividade