Segurança e permissões do Dataflow

É possível executar pipelines do Dataflow localmente ou em recursos gerenciados do Google Cloud usando o serviço gerenciado do Dataflow. Seja em execução local ou na nuvem, o pipeline e os workers deles contam com um sistema de permissões que mantém a segurança do acesso a arquivos e recursos do pipeline. As permissões do Dataflow são atribuídas de acordo com o papel usado para acessar os recursos do pipeline. Neste documento, explicamos os seguintes conceitos:

  • Como fazer upgrade de VMs do Dataflow
  • Papéis e permissões necessários para executar pipelines locais e do Google Cloud
  • Papéis e permissões necessários para acessar recursos de pipeline
  • Tipos de dados usados em um serviço do Dataflow e na segurança de dados

Antes de começar

Saiba mais sobre os identificadores de projetos do Google Cloud na visão geral do Google Cloud. Esses identificadores incluem o nome, o ID e o número do projeto.

Fazer upgrade e corrigir VMs do Dataflow

O Dataflow usa o Container-Optimized OS. Portanto, os processos de segurança do Container-Optimized OS também se aplicam ao Dataflow.

Os pipelines em lote têm limite de tempo e não precisam de manutenção. Quando um novo pipeline em lote é iniciado, a imagem mais recente do Dataflow é usada.

Para pipelines de streaming, se um patch de segurança for necessário imediatamente, o Google Cloud notificará você usando boletins de segurança. Em pipelines de streaming, recomendamos que você use a opção --update para reiniciar seu job com a imagem mais recente do Dataflow.

As imagens de contêiner do Dataflow estão disponíveis no Console do Google Cloud.

Segurança e permissões para pipelines locais

Quando você executa localmente, o pipeline do Apache Beam é executado como a conta do Google Cloud que você configurou com o executável da Google Cloud CLI. Portanto, execute operações do SDK do Apache Beam localmente e sua conta do Google Cloud terá acesso aos mesmos arquivos e recursos.

Para listar a conta do Google Cloud selecionada como padrão, execute o comando gcloud config list.

Os pipelines locais podem enviar dados para destinos locais, como arquivos locais, ou para destinos na nuvem, como o Cloud Storage ou o BigQuery. Se o pipeline executado localmente gravar arquivos em recursos baseados em nuvem, como o Cloud Storage, ele usará as credenciais da conta do Google Cloud e o projeto do Google Cloud que você configurou como padrão da Google Cloud CLI. Para instruções sobre como autenticar usando as credenciais da sua conta do Google Cloud, consulte o guia de início rápido da linguagem que você está usando: Guia de início rápido do Java, Guia de início rápido do Python ou Guia de início rápido do Go.

Segurança e permissões para pipelines no Google Cloud

Quando você executa o pipeline, o Dataflow usa duas contas de serviço para gerenciar a segurança e as permissões:

  • A conta de serviço do Dataflow. O serviço Dataflow usa a conta como parte da solicitação de criação do job, por exemplo, para verificar a cota do projeto e criar instâncias de worker em seu nome. O Dataflow também usa a conta de serviço do Dataflow durante a execução do job para gerenciá-lo. Essa conta também é conhecida como agente de serviço do Dataflow.

  • A conta de serviço do worker. As instâncias de worker usam a conta de serviço do worker para acessar recursos de entrada e saída depois que você envia seu job. Por padrão, os workers usam a conta de serviço padrão do Compute Engine associada ao seu projeto como a conta de serviço do worker. Como prática recomendada, recomendamos que você especifique uma conta de serviço gerenciada pelo usuário em vez de usar a conta de serviço de worker padrão.

Para representar a conta de serviço, a conta que inicia o pipeline precisa ter o seguinte papel: iam.serviceAccounts.actAs.

Dependendo de outras permissões de projeto, a conta de usuário também pode precisar do papel roles/dataflow.developer. Se você é proprietário ou editor de um projeto, já tem as permissões contidas no papel roles/dataflow.developer.

Práticas recomendadas

  • Quando possível, para a conta de serviço do worker, especifique uma conta de serviço gerenciada pelo usuário em vez de usar a padrão.
  • Ao conceder permissões em recursos, conceda o papel que contém as permissões mínimas necessárias para a tarefa. É possível criar um papel personalizado que inclua apenas as permissões necessárias.
  • Ao conceder papéis para acessar recursos, use o nível de recurso mais baixo possível. Por exemplo, em vez de conceder o papel roles/bigquery.dataEditor em um projeto ou pasta, conceda o papel na tabela do BigQuery.
  • Crie um bucket de propriedade do projeto para usar como bucket de preparo do Dataflow. As permissões de bucket padrão permitem que o Dataflow use o bucket para preparar os arquivos executáveis do pipeline.

Conta de serviço do Dataflow

Todos os projetos que usaram o recurso Dataflow Job têm uma conta de serviço do Dataflow, também conhecida como agente de serviço do Dataflow, que tem o seguinte e-mail:

service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com

Essa conta de serviço é criada e gerenciada pelo Google e atribuída ao seu projeto automaticamente após o primeiro uso do recurso Dataflow Job.

Como parte da execução do pipeline do Dataflow, o serviço do Dataflow manipula recursos em seu nome. Por exemplo, ele cria mais VMs. Quando você executa o pipeline no serviço do Dataflow, ele usa essa conta de serviço.

Essa conta recebe o papel de agente de serviço do Dataflow no projeto. Ele tem as permissões necessárias para executar um job do Dataflow no projeto, incluindo a inicialização de workers do Compute Engine. A conta é usada exclusivamente pelo serviço Dataflow e é específica para seu projeto.

É possível analisar as permissões da conta de serviço do Dataflow no Console do Google Cloud ou na Google Cloud CLI.

Console

  1. Acesse a página Papéis.

    Acessar "Papéis"

  2. Se aplicável, selecione o projeto.

  3. Na lista, clique no título Agente de serviço do Cloud Dataflow. Será aberta uma página com a lista de permissões atribuídas à conta de serviço do Dataflow.

CLI da gcloud

Veja as permissões da conta de serviço do Dataflow:

gcloud iam roles describe roles/dataflow.serviceAgent

Como os serviços do Google Cloud esperam ter acesso de leitura e gravação ao projeto e aos recursos dele, é recomendável não alterar as permissões padrão estabelecidas automaticamente para seu projeto. Se uma conta do serviço Dataflow perder permissões para um projeto, o Dataflow não poderá iniciar as VMs ou executar outras tarefas de gerenciamento.

Se você remover as permissões da conta de serviço da política de gerenciamento de identidade e acesso (IAM), a conta permanecerá presente, porque ela pertence ao serviço Dataflow.

Conta de serviço do worker

As instâncias do Compute Engine executam as operações de SDK do Apache Beam na nuvem. Esses workers usam a conta de serviço do worker do projeto para acessar os arquivos e outros recursos associados ao pipeline. A conta de serviço do worker é usada como a identidade para todas as VMs de workers, e todas as solicitações originadas da VM usam a conta de serviço do worker. Essa conta de serviço também é usada para interagir com recursos como buckets do Cloud Storage e tópicos do Pub/Sub.

  • Para que a conta de serviço do worker possa executar um job, ela precisa ter o papel roles/dataflow.worker.
  • Para que a conta de serviço do worker possa criar ou examinar um job, ela precisa ter o papel roles/dataflow.admin.

Além disso, quando os pipelines do Apache Beam acessam os recursos do Google Cloud, é preciso conceder os papéis necessários à conta de serviço do worker do projeto do Dataflow. A conta de serviço do worker precisa ter acesso aos recursos durante a execução do job do Dataflow. Por exemplo, se o job for gravado no BigQuery, sua conta de serviço também precisará ter pelo menos o papel roles/bigquery.dataEditor na tabela do BigQuery. Veja alguns exemplos de recursos:

Conta de serviço de worker padrão

Por padrão, os workers usam a conta de serviço padrão do Compute Engine do seu projeto como a conta de serviço do worker. Essa conta de serviço tem o seguinte e-mail:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Essa conta de serviço é criada automaticamente quando você ativa a API Compute Engine para o projeto na Biblioteca de APIs no console do Google Cloud.

Embora seja possível usar a conta de serviço padrão do Compute Engine como a conta de serviço do worker do Dataflow, recomendamos criar uma conta de serviço do worker do Dataflow dedicada que tenha apenas as funções e permissões necessárias.

Dependendo da configuração da política da organização, a conta de serviço padrão pode receber automaticamente o papel de Editor no projeto. É altamente recomendável desativar a concessão automática de papéis aplicando a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts. Se você criou a organização após 3 de maio de 2024, essa restrição será aplicada por padrão.

Se você desativar a concessão automática de papéis, precisará decidir quais papéis conceder às contas de serviço padrão e, em seguida, conceder esses papéis por conta própria.

Se a conta de serviço padrão já tiver o papel de Editor, recomendamos que você o substitua por papéis menos permissivos. Para modificar com segurança os papéis da conta de serviço, use o Simulador de política para ver o impacto da alteração e, em seguida, conceda e revogue os papéis apropriados.

Especificar uma conta de serviço do controlador gerenciada pelo usuário

Se você quiser criar e usar recursos com controle de acesso minucioso, crie uma conta de serviço gerenciada pelo usuário. Use essa conta como a conta de serviço do worker.

  1. Se você ainda não tiver uma conta de serviço gerenciada pelo usuário, crie uma conta de serviço.

  2. Defina os papéis do IAM necessários para sua conta de serviço.

    • Para que a conta de serviço do worker possa executar um job, ela precisa ter o papel roles/dataflow.worker.
    • Para que a conta de serviço do worker possa criar ou examinar um job, ela precisa ter o papel roles/dataflow.admin.
    • Como alternativa, crie um papel personalizado do IAM com as permissões necessárias. Para ver uma lista das permissões necessárias, consulte Papéis.
    • A conta de serviço pode precisar de outros papéis para usar os recursos do Google Cloud exigidos pelo job, como BigQuery, Pub/Sub ou gravação no Cloud Storage. Por exemplo, se o job fizer leituras no BigQuery, sua conta de serviço também precisará ter pelo menos o papel roles/bigquery.dataViewer na tabela do BigQuery.
    • Além disso, verifique se a sua conta de serviço gerenciada pelo usuário tem acesso de leitura e gravação aos locais temporários e de preparo especificados no job do Dataflow.
    • Para representar a conta de serviço, sua conta de usuário precisa ter a permissão iam.serviceAccounts.actAs.

  3. No projeto que contém a conta de serviço do worker gerenciada pelo usuário, a conta de serviço do Dataflow (service-PROJECT_NUMBER@dataflow-service-producer-prod.iam.gserviceaccount.com) e o agente de serviço do Compute Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) precisa ter os papéis a seguir. PROJECT_NUMBER é o ID do projeto em que o job do Dataflow é executado. As duas contas são agentes de serviço.

    No projeto em que o job do Dataflow é executado, as contas têm esses papéis por padrão. Se a conta de serviço do worker gerenciada pelo usuário e o job estiverem em projetos diferentes, conceda também esses papéis às contas de serviço gerenciadas pelo Google usadas pela conta de serviço do worker gerenciada pelo usuário. Para conceder esses papéis, siga as etapas na seção Conceder um único papel na página "Gerenciar acesso a contas de serviço".

  4. Quando a conta de serviço do worker gerenciado pelo usuário e o job estiverem em projetos diferentes, verifique se a restrição booleana iam.disableCrossProjectServiceAccountUsage não é aplicada ao projeto que tem a conta de serviço gerenciada pelo usuário. Para mais informações, consulte Ativar a vinculação de contas de serviço entre projetos.

  5. Ao executar o job do pipeline, especifique sua conta de serviço.

    Java

    Use a opção --serviceAccount e especifique a conta de serviço ao executar o job do pipeline na linha de comando: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Use a opção --service-account-email e especifique a conta de serviço ao executar o job do pipeline como um modelo Flex: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Python

    Use a opção --service_account_email e especifique a conta de serviço ao executar o job do pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Go

    Use a opção --service_account_email e especifique a conta de serviço ao executar o job do pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

Acesse uma lista das contas de serviço associadas ao seu projeto na página Permissões no Console do Google Cloud.

A conta de serviço gerenciada pelo usuário pode estar no mesmo projeto do seu job ou em um projeto diferente. Se a conta de serviço e o job estiverem em projetos diferentes, configure a conta de serviço antes de executar o job.

Adicionar papéis

Para adicionar papéis ao projeto, siga as etapas abaixo.

Console

  1. No Console do Google Cloud, abra a página IAM.

    Acessar IAM

  2. Selecione o projeto.

  3. Na linha que contém a conta de usuário, clique em Editar principal e, em seguida, clique em Adicionar outro papel.

  4. Na lista suspensa, selecione o papel Usuário da conta de serviço.

  5. Na linha que contém a conta de serviço do worker, clique em Editar principal e, em seguida, clique em Adicionar outro papel.

  6. Na lista suspensa, selecione o papel Worker do Dataflow.

  7. Se a conta de serviço do worker precisar do papel Administrador do Dataflow, repita para Administrador do Dataflow.

  8. Repita essas etapas para todos os papéis exigidos pelos recursos usados no job e clique em Salvar.

    Para mais informações sobre como conceder papéis, consulte Conceder um papel do IAM usando o console.

CLI da gcloud

  1. Atribua o papel roles/iam.serviceAccountUser à sua conta de usuário. Execute este comando:

    gcloud projects add-iam-policy-binding PROJECT_ID --member="user:EMAIL_ADDRESS --role=roles/iam.serviceAccountUser
    • Substitua PROJECT_ID pela ID do seu projeto.
    • Substitua EMAIL_ADDRESS pelo endereço de e-mail da conta de usuário.

  2. Conceda papéis à conta de serviço do worker. Execute o comando a seguir para o papel roles/dataflow.worker do IAM e todos os papéis exigidos pelos recursos usados no job. Se a conta de serviço do worker precisar do papel de administrador do Dataflow, repita para o papel roles/dataflow.admin do IAM. Este exemplo usa a conta de serviço padrão do Compute Engine, mas recomendamos o uso de uma conta de serviço gerenciada pelo usuário.

    gcloud projects add-iam-policy-binding PROJECT_ID --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE
    • Substitua PROJECT_ID pela ID do seu projeto.
    • Substitua PROJECT_NUMBER pelo número do projeto. Para encontrar o número do projeto, consulte Identificar projetos ou use o comando gcloud projects describe.
    • Substitua SERVICE_ACCOUNT_ROLE por cada papel individual.

Acessar recursos do Google Cloud

Seus pipelines do Apache Beam podem acessar recursos do Google Cloud no mesmo projeto do Google Cloud ou em outros projetos. Esses recursos incluem:

Para garantir que o pipeline do Apache Beam possa acessar esses recursos, você talvez precisará usar os mecanismos de controle de acesso desses recursos para conceder acesso explicitamente à conta de serviço do worker do projeto do Dataflow.

Se você usa os recursos do Assured Workloads com o Dataflow, como Regiões e suporte da UE com controles de soberania, todos os conectores do Cloud Storage, do BigQuery, do Pub/Sub, de E/S e outros recursos acessados pelo pipeline precisam estar localizados no projeto ou pasta do Assured Workloads da organização.

Se você estiver usando uma conta de serviço de worker gerenciada pelo usuário ou acessando recursos em outros projetos, outras ações poderão ser necessárias. Nos exemplos a seguir, pressupomos que a conta de serviço padrão do Compute Engine seja usada, mas também é possível usar uma conta de serviço de worker gerenciada pelo usuário.

Acessar repositórios do Artifact Registry

Ao usar contêineres personalizados com o Dataflow, é possível fazer upload de artefatos para um repositório do Artifact Registry.

Para usar o Artifact Registry com o Dataflow, é preciso conceder pelo menos acesso de gravador do Artifact Registry (role/artifactregistry.writer) à conta de serviço do worker. que executa o job do Dataflow.

Todo o conteúdo do repositório é criptografado usando chaves de propriedade do Google e gerenciadas pelo Google ou chaves de criptografia gerenciadas pelo cliente. O Artifact Registry usa chaves de propriedade e gerenciadas pelo Google por padrão, e nenhuma configuração é necessária para essa opção.

Acessar buckets do Cloud Storage

Para permitir que seu projeto do Dataflow acesse um bucket do Cloud Storage, torne o bucket acessível à conta de serviço do worker do projeto do Dataflow. No mínimo, sua conta de serviço precisa de permissões de leitura e gravação para o bucket e o conteúdo dele. Use as permissões do IAM para o Cloud Storage para conceder o acesso necessário.

Para conceder à conta de serviço de worker as permissões necessárias para ler e gravar em um bucket, use o comando gcloud storage buckets add-iam-policy-binding. Esse comando adiciona a conta de serviço do projeto do Dataflow a uma política no nível do bucket.

gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member="serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com" --role=SERVICE_ACCOUNT_ROLE

Substitua:

  • BUCKET_NAME: o nome do bucket do Cloud Storage
  • PROJECT_NUMBER: o número do projeto do Dataflow. Para encontrar o número do projeto, consulte Identificar projetos ou use o comando gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE: o papel do IAM, por exemplo storage.objectViewer

Para recuperar uma lista dos buckets do Cloud Storage em um projeto do Google Cloud, use o comando gcloud storage buckets list:

gcloud storage buckets list --project= PROJECT_ID

Substitua PROJECT_ID pelo código do projeto.

A menos que você esteja restrito por políticas da organização que limitam o compartilhamento de recursos, é possível acessar um bucket que reside em um projeto diferente do pipeline do Dataflow. Para mais informações sobre restrições de domínio, consulte Como restringir identidades por domínio.

Se você não tiver um bucket, crie um novo. Em seguida, conceda à conta de serviço de worker as permissões necessárias para ler e gravar no bucket.

Você também pode definir as permissões do bucket no console do Google Cloud. Para mais informações, consulte Como definir as permissões de bucket.

O Cloud Storage oferece dois sistemas para conceder aos usuários permissão de acesso aos buckets e objetos: IAM e Listas de controle de acesso (ACLs). Na maioria dos casos, o IAM é o método recomendado para controlar o acesso aos recursos.

  • O IAM controla a permissão em todo o Google Cloud e permite que você conceda permissões nos níveis do bucket e do projeto. Para conferir uma lista de papéis do IAM associados ao Cloud Storage e as permissões contidas em cada um deles, consulte Papéis do IAM para o Cloud Storage. Se você precisar de mais controle sobre as permissões, crie um papel personalizado.

  • Se você usar ACLs para controlar o acesso, verifique se as permissões da conta de serviço do worker são consistentes com as configurações do IAM. Devido à inconsistência entre as políticas do IAM e da ACL, o bucket do Cloud Storage pode ficar inacessível nos jobs do Dataflow quando ele for migrado do acesso detalhado para o acesso uniforme no nível do bucket. Para mais informações, consulte Orientação para erros comuns.

Acessar conjuntos de dados do BigQuery

É possível usar a API BigQueryIO para acessar conjuntos de dados do BigQuery, no mesmo projeto em que você está usando o Dataflow ou em um projeto diferente. Para o coletor e a origem do BigQuery operarem corretamente, as duas contas a seguir precisam ter acesso a todos os conjuntos de dados do BigQuery que o job do Dataflow lê ou grava:

Pode ser necessário configurar o BigQuery para conceder acesso explicitamente a essas contas. Consulte Controle de acesso ao BigQuery para mais informações sobre como conceder acesso aos conjuntos de dados do BigQuery usando a página do BigQuery ou a API do BigQuery.

Entre as permissões obrigatórias do BigQuery, a permissão bigquery.datasets.get do IAM é exigida pelo pipeline para acessar um conjunto de dados do BigQuery. A maioria dos papéis de IAM do BigQuery costuma incluir a permissão bigquery.datasets.get, mas o papel roles/bigquery.jobUser é uma exceção.

Acessar tópicos e assinaturas do Pub/Sub

Para acessar um tópico ou assinatura do Pub/Sub, use os recursos de gerenciamento de identidade e acesso do Pub/Sub para configurar permissões para o worker conta de serviço.

As permissões dos seguintes papéis do Cloud Pub/Sub são relevantes:

  • O roles/pubsub.subscriber é obrigatório para consumir dados.
  • roles/pubsub.editor é obrigatório para criar uma assinatura do Pub/Sub.
  • roles/pubsub.viewer é recomendado para que o Dataflow possa consultar as configurações dos tópicos e das assinaturas. Essa configuração tem dois benefícios:
    • O Dataflow pode verificar se há configurações sem suporte em assinaturas que podem não funcionar como esperado.
    • Se a assinatura não usar o prazo de confirmação padrão de 10 segundos, o desempenho vai melhorar. O Dataflow amplia repetidamente o prazo de confirmação de uma mensagem enquanto ela está sendo processada pelo pipeline. Sem as permissões pubsub.viewer, o Dataflow não pode consultar o prazo de confirmação e, portanto, precisa assumir um prazo padrão. Essa configuração faz com que o Dataflow emita mais solicitações modifyAckDeadline do que o necessário.
    • Se o VPC Service Controls estiver ativado no projeto que tem a assinatura ou o tópico, as regras de entrada baseadas em endereço IP não permitirão que o Dataflow consulte as configurações. Nesse caso, é necessária uma regra de entrada baseada na conta de serviço do worker.

Para mais informações e alguns exemplos de código que demonstram como usar os recursos de gerenciamento de identidade e acesso do Pub/Sub, consulte Exemplo de caso de uso: comunicação entre projetos.

Acessar o Firestore

Para acessar um banco de dados do Firestore (no modo nativo ou no Datastore), adicione sua conta de serviço de worker do Dataflow (por exemplo, PROJECT_NUMBER-compute@developer.gserviceaccount.com) como editor do projeto proprietário do banco de dados, ou use um papel do Datastore mais restritivo, como roles/datastore.viewer. Além disso, ative a API Firestore em ambos os projetos da Biblioteca de APIs no Console do Google Cloud.

Acessar imagens de projetos com uma política de imagens confiáveis

Se você tiver uma política de imagem confiável configurada para o projeto e sua imagem de inicialização estiver localizada em outro projeto, verifique se a política de imagem confiável está configurada para ter acesso à imagem. Por exemplo, se você estiver executando um job do Dataflow com modelo, verifique se o arquivo de política inclui acesso ao projeto dataflow-service-producer-prod. Este projeto do Google Cloud contém as imagens para jobs de modelo.

Acesso e segurança dos dados

O serviço Dataflow funciona com dois tipos de dados:

  • Dados de usuário final. Esses dados são processados por um pipeline do Dataflow. Um pipeline típico lê dados de uma ou mais fontes, implementa transformações dos dados e grava os resultados em um ou mais coletores. Todas as origens e coletores são serviços de armazenamento que não são gerenciados diretamente pelo Dataflow.

  • Dados operacionais. Esses dados incluem todos os metadados necessários para gerenciar um pipeline do Dataflow. Esses dados incluem metadados fornecidos pelo usuário, como nome de job ou opções de pipeline, e metadados gerados pelo sistema, como ID do job.

O serviço Dataflow usa vários mecanismos de segurança para manter a segurança e a privacidade dos dados. Esses mecanismos se aplicam aos seguintes cenários:

  • Envio de um pipeline para o serviço
  • Avaliação de um pipeline
  • Solicitação de acesso à telemetria e métricas durante e após a execução de um pipeline
  • Uso de um serviço do Dataflow, como o Shuffle ou o Streaming Engine

Localidade dos dados

Todo o processamento de dados principal do serviço do Dataflow acontece na região especificada no código do pipeline. Se uma região não for especificada, a região padrão us-central1 será usada. Se você especificar essa opção no código do pipeline, o job de pipeline poderá ler e gravar de fontes e coletores em outras regiões. No entanto, o processamento de dados real ocorre apenas na região especificada para executar as VMs do Dataflow.

A lógica do pipeline é avaliada nas instâncias de VM do worker individual. Especifique a zona em que essas instâncias e a rede privada usada para se comunicarem estão localizadas. Os cálculos complementares para a plataforma dependem de metadados, como locais do Cloud Storage ou tamanhos de arquivo.

O Dataflow é um serviço regional. Para mais informações sobre localidade e regiões dos dados, consulte Regiões do Dataflow.

Dados em um envio de pipeline

As permissões do IAM para seu projeto do Google Cloud controlam o acesso ao serviço do Dataflow. Quaisquer diretores que tenham direitos de editor ou de proprietário do projeto poderão enviar pipelines ao serviço. Para enviar pipelines, faça a autenticação usando a Google Cloud CLI. Depois da autenticação, os pipelines são enviados usando o protocolo HTTPS. Veja instruções sobre como autenticar usando as credenciais da sua conta do Google Cloud no guia de início rápido da linguagem que você está usando.

Dados em uma avaliação de pipeline

Como parte da avaliação de um pipeline, os dados temporários podem ser gerados e armazenados localmente nas instâncias de VM do worker ou no Cloud Storage. Os dados temporários são criptografados em repouso e não são mantidos após a conclusão da avaliação do pipeline. Esses dados também podem ser armazenados no serviço Shuffle ou no Streaming Engine (se você tiver optado pelo serviço) na mesma região especificada no pipeline do Dataflow.

Java

Por padrão, as VMs do Compute Engine são excluídas quando o job do Dataflow é concluído, independentemente de êxito ou falha. Consequentemente, o Disco permanente e os dados intermediários que podem estar armazenados nele são excluídos. Os dados intermediários armazenados no Cloud Storage podem ser encontrados em sublocações do caminho do Cloud Storage fornecido como --stagingLocation ou --tempLocation. Se você gravar a saída de um arquivo do Cloud Storage, serão criados arquivos temporários no local da saída antes da finalização da operação de gravação.

Python

Por padrão, as VMs do Compute Engine são excluídas quando o job do Dataflow é concluído, independentemente de êxito ou falha. Consequentemente, o Disco permanente e os dados intermediários que podem estar armazenados nele são excluídos. Os dados intermediários armazenados no Cloud Storage podem ser encontrados em sublocações do caminho do Cloud Storage fornecido como --staging_location ou --temp_location. Se você gravar a saída de um arquivo do Cloud Storage, serão criados arquivos temporários no local da saída antes da finalização da operação de gravação.

Go

Por padrão, as VMs do Compute Engine são excluídas quando o job do Dataflow é concluído, independentemente de êxito ou falha. Consequentemente, o Disco permanente e os dados intermediários que podem estar armazenados nele são excluídos. Os dados intermediários armazenados no Cloud Storage podem ser encontrados em sublocações do caminho do Cloud Storage fornecido como --staging_location ou --temp_location. Se você gravar a saída de um arquivo do Cloud Storage, serão criados arquivos temporários no local da saída antes da finalização da operação de gravação.

Dados em registros de pipeline e telemetria

As informações armazenadas no Cloud Logging são basicamente geradas pelo código do programa do Dataflow. O serviço Dataflow também gera dados de aviso e de erro no Cloud Logging, mas esses são os únicos dados intermediários que o serviço adiciona aos registros. O Cloud Logging é um serviço global.

Os dados de telemetria e as métricas associadas são criptografados em repouso, e o acesso a esses dados é controlado pelas permissões de leitura do seu projeto do Google Cloud.

Dados nos serviços do Dataflow

Se você usa o Dataflow Shuffle ou o Dataflow Streaming para o pipeline, não especifique as opções de pipeline de zona. Em vez disso, especifique a região e defina o valor como uma das regiões em que o Shuffle ou o Streaming está disponível. O Dataflow seleciona automaticamente a zona na região que você especificar. Os dados do usuário final em trânsito permanecem nas VMs de worker e na mesma zona. Esses jobs do Dataflow ainda podem ler e gravar em origens e coletores que estão fora da zona de VM. Os dados em trânsito também podem ser enviados para os serviços Dataflow Shuffle ou Dataflow Streaming, mas os dados sempre permanecem na região especificada no código do pipeline.

Recomendamos que você use os mecanismos de segurança disponíveis nos recursos de nuvem subjacentes do pipeline. Esses mecanismos incluem recursos de segurança dos dados das origens e coletores, como BigQuery e Cloud Storage. Não é indicado misturar níveis de confiança diferentes em um único projeto.