Segurança e autorizações do fluxo de dados

Pode executar pipelines do Dataflow localmente ou em recursos geridos da Google Cloud Platform usando o executor do Dataflow. Quer execute pipelines localmente ou na nuvem, o pipeline e os respetivos trabalhadores usam um sistema de autorizações para manter o acesso seguro aos ficheiros e recursos do pipeline. As autorizações do fluxo de dados são atribuídas de acordo com a função usada para aceder aos recursos do pipeline. Este documento explica os seguintes conceitos:

  • Atualizar VMs do Dataflow
  • Funções e autorizações necessárias para executar pipelines locais e da Google Cloud Platform
  • Funções e autorizações necessárias para aceder a recursos de pipelines
  • Tipos de dados usados num serviço Dataflow e na segurança de dados

Antes de começar

Leia acerca dos identificadores de projetos da Google Cloud Platform na vista geral da Google Cloud Platform. Estes identificadores incluem o nome do projeto, o ID do projeto e o número do projeto.

Atualize e aplique patches às VMs do Dataflow

O Dataflow usa o SO otimizado para contentores. Os processos de segurança do SO otimizado para contentores também se aplicam ao Dataflow.

Os pipelines em lote estão limitados no tempo e não requerem manutenção. Quando é iniciada uma nova pipeline de processamento em lote, é usada a imagem mais recente do Dataflow.

Para pipelines de streaming, se for imediatamente necessário um patch de segurança, Google Cloud envia-lhe uma notificação através de boletins de segurança. Para pipelines de streaming, recomendamos que use a opção --update para reiniciar a tarefa com a imagem mais recente do Dataflow.

As imagens de contentores do Dataflow estão disponíveis na Google Cloud consola.

Ambiente de tempo de execução

Para o ambiente de tempo de execução do código do utilizador do pipeline, o Dataflow usa uma imagem do Apache Beam pré-criada ou um contentor personalizado, se tiver sido fornecido.

O utilizador para a execução do contentor é selecionado pelo serviço Dataflow. Os recursos do pipeline são atribuídos por tarefa. Não existe partilha de VMs nem de outros recursos entre pipelines.

O ciclo de vida do ambiente de tempo de execução está associado ao ciclo de vida do pipeline. É iniciado no início do pipeline e parado no término do pipeline. O ambiente de tempo de execução pode ser reiniciado uma ou mais vezes durante a execução do pipeline.

Segurança e autorizações para pipelines locais

Quando executa localmente, o pipeline do Apache Beam é executado como aGoogle Cloud conta que configurou com o executável da CLI do Google Cloud. As operações do SDK do Apache Beam são executadas localmente e a sua Google Cloud conta tem acesso aos mesmos ficheiros e recursos.

Para listar a Google Cloud conta que selecionou como predefinição, execute o comando gcloud config list.

Os pipelines locais podem gerar dados para destinos locais, como ficheiros locais, ou para destinos na nuvem, como o Cloud Storage ou o BigQuery. Se o pipeline executado localmente escrever ficheiros em recursos baseados na nuvem, como o Cloud Storage, usa as credenciais da sua conta e o projeto que configurou como predefinição da CLI do Google Cloud. Google Cloud Google Cloud Para ver instruções sobre como fazer a autenticação com as credenciais da sua conta, consulte o tutorial para o idioma que está a usar: Java, Python ou Go. Google Cloud

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

Quando executa o pipeline, o Dataflow usa duas contas de serviço para gerir a segurança e as autorizações:

  • A conta de serviço do Dataflow. O serviço Dataflow usa a conta de serviço do Dataflow como parte do pedido de criação de tarefas, por exemplo, para verificar a quota do projeto e criar instâncias de trabalho em seu nome. O Dataflow também usa a conta de serviço do Dataflow durante a execução da tarefa para gerir a tarefa. Esta conta também é conhecida como o agente do serviço Dataflow.

  • A conta de serviço do trabalhador. As instâncias de trabalho usam a conta de serviço do trabalhador para aceder aos recursos de entrada e saída depois de enviar o seu trabalho. Por predefinição, os trabalhadores usam a conta de serviço predefinida do Compute Engine associada ao seu projeto como a conta de serviço do trabalhador. Como prática recomendada, sugerimos que especifique uma conta de serviço gerida pelo utilizador em vez de usar a conta de serviço do trabalhador predefinida.

Para usar a identidade da conta de serviço, a conta que inicia o pipeline tem de ter a seguinte função: iam.serviceAccounts.actAs.

Consoante outras autorizações do projeto, a sua conta de utilizador também pode precisar da função roles/dataflow.developer. Se for proprietário ou editor de um projeto, já tem as autorizações incluídas na função roles/dataflow.developer.

Práticas recomendadas

  • Sempre que possível, para a conta de serviço do trabalhador, especifique uma conta de serviço gerida pelo utilizador em vez de usar a conta de serviço do trabalhador predefinida.
  • Ao conceder autorizações em recursos, atribua a função que contém as autorizações mínimas necessárias para a tarefa. Pode criar uma função personalizada que inclua apenas as autorizações necessárias.
  • Quando conceder funções para aceder a recursos, use o nível de recurso mais baixo possível. Por exemplo, em vez de conceder a função roles/bigquery.dataEditor num projeto ou numa pasta, conceda a função na tabela do BigQuery.
  • Crie um contentor pertencente ao seu projeto para usar como contentor de preparação para o Dataflow. As autorizações do contentor predefinidas permitem que o Dataflow use o contentor para preparar os ficheiros 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 o agente do serviço do Dataflow, que tem o seguinte email:

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

Esta conta de serviço é criada e gerida pela Google e atribuída automaticamente ao seu projeto na primeira utilização do recurso Dataflow Job.

Como parte da execução de pipelines do Dataflow, o Dataflow manipula recursos em seu nome. Por exemplo, cria VMs adicionais. Quando executa o pipeline com o Dataflow, esta conta de serviço é usada.

Esta conta tem a função de agente do serviço do Dataflow atribuída no projeto. Tem as autorizações necessárias para executar uma tarefa do Dataflow no projeto, incluindo o início de trabalhadores do Compute Engine. Esta conta é usada exclusivamente pelo Dataflow e é específica do seu projeto.

Pode rever as funções atribuídas à conta de serviço do Dataflow na Google Cloud consola ou na CLI Google Cloud.

Consola

  1. Aceda à página Funções.

    Aceda a Funções

  2. Se aplicável, selecione o seu projeto.

  3. Na lista, clique no título Agente do serviço Cloud Dataflow. É aberta uma página que apresenta as autorizações atribuídas à conta de serviço do Dataflow.

CLI gcloud

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

gcloud iam roles describe roles/dataflow.serviceAgent

Uma vez que os Google Cloud serviços esperam ter acesso de leitura e escrita ao projeto e aos respetivos recursos, recomendamos que não altere as autorizações predefinidas estabelecidas automaticamente para o seu projeto. Se uma conta de serviço do Dataflow perder autorizações para um projeto, o Dataflow não pode iniciar VMs nem realizar outras tarefas de gestão.

Se remover as autorizações da conta de serviço da política de gestão de identidade e de acesso (IAM), a conta permanece presente, porque é propriedade do serviço Dataflow.

Conta de serviço do trabalhador

As instâncias do Compute Engine executam operações do SDK Apache Beam na nuvem. Estes trabalhadores usam a conta de serviço do trabalhador do seu projeto para aceder aos ficheiros e a outros recursos associados ao pipeline. A conta de serviço do trabalhador é usada como a identidade para todas as VMs do trabalhador, e todos os pedidos que têm origem na VM usam a conta de serviço do trabalhador. Esta conta de serviço também é usada para interagir com recursos, como contentores do Cloud Storage e tópicos do Pub/Sub.

  • Para que a conta de serviço do trabalhador possa executar uma tarefa, tem de ter a função roles/dataflow.worker.
  • Para que a conta de serviço do trabalhador possa criar ou examinar uma tarefa, tem de ter a função roles/dataflow.admin.

Além disso, quando os seus pipelines do Apache Beam acedem a Google Cloud recursos, tem de conceder as funções necessárias à conta de serviço do trabalhador do seu projeto do Dataflow. A conta de serviço do trabalhador tem de conseguir aceder aos recursos enquanto executa a tarefa do Dataflow. Por exemplo, se a sua tarefa escrever no BigQuery, a sua conta de serviço também tem de ter, pelo menos, a função roles/bigquery.dataEditor na tabela do BigQuery. Alguns exemplos de recursos:

Conta de serviço do trabalhador predefinida

Por predefinição, os trabalhadores usam a conta de serviço predefinida do Compute Engine do seu projeto como a conta de serviço do trabalhador. Esta conta de serviço tem o seguinte email:

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Esta conta de serviço é criada automaticamente quando ativa a API Compute Engine para o seu projeto a partir da biblioteca de APIs na Google Cloud consola.

Embora possa usar a conta de serviço predefinida do Compute Engine como a conta de serviço do trabalhador do Dataflow, recomendamos que crie uma conta de serviço do trabalhador do Dataflow dedicada que tenha apenas as funções e as autorizações de que precisa.

Consoante a configuração da política da organização, a conta de serviço predefinida pode receber automaticamente a função de editor no seu projeto. Recomendamos vivamente que desative a concessão automática de funções aplicando a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts. Se tiver criado a sua organização após 3 de maio de 2024, esta restrição é aplicada por predefinição.

Se desativar a concessão automática de funções, tem de decidir que funções conceder às contas de serviço predefinidas e, em seguida, conceder estas funções.

Se a conta de serviço predefinida já tiver a função de editor, recomendamos que substitua a função de editor por funções menos permissivas.Para modificar as funções da conta de serviço em segurança, use o Simulador de políticas para ver o impacto da alteração e, em seguida, conceda e revogue as funções adequadas.

Especifique uma conta de serviço de worker gerida pelo utilizador

Se quiser criar e usar recursos com controlo de acesso detalhado, pode criar uma conta de serviço gerida pelo utilizador. Use esta conta como a conta de serviço de trabalho.

  1. Se não tiver uma conta de serviço gerida pelo utilizador, crie uma conta de serviço.

  2. Defina as funções IAM necessárias para a sua conta de serviço.

    • Para que a conta de serviço do trabalhador possa executar uma tarefa, tem de ter a função roles/dataflow.worker.
    • Para que a conta de serviço do trabalhador possa criar ou examinar uma tarefa, tem de ter a função roles/dataflow.admin.
    • Em alternativa, crie uma função do IAM personalizada com as autorizações necessárias. Para ver uma lista das autorizações necessárias, consulte o artigo Funções.
    • A sua conta de serviço pode precisar de funções adicionais para usar os recursos da Google Cloud Platform, conforme necessário para a sua tarefa, como o BigQuery, o Pub/Sub ou o Cloud Storage. Por exemplo, se a sua tarefa ler a partir do BigQuery, a sua conta de serviço também tem de ter, pelo menos, a função roles/bigquery.dataViewer na tabela do BigQuery.
    • Certifique-se de que a sua conta de serviço gerida pelo utilizador tem acesso de leitura e escrita às localizações de preparação e temporárias especificadas na tarefa do Dataflow.
    • Para se fazer passar pela conta de serviço, a sua conta de utilizador tem de ter a autorização iam.serviceAccounts.actAs.

  3. No projeto que contém a conta de serviço do trabalhador gerida pelo utilizador, 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) têm de ter as seguintes funções. PROJECT_NUMBER é o ID do projeto no qual a sua tarefa do Dataflow é executada. Ambas as contas são agentes de serviço.

    Suponha que a tarefa do Dataflow está a ser executada no projeto A e que a conta de serviço do trabalhador está alojada no projeto B. Certifique-se de que os agentes de serviço do projeto A têm as funções iam.serviceAccountTokenCreator e iam.serviceAccountUser no projeto B. No projeto em que a tarefa do Dataflow é executada, as contas têm estas funções por predefinição. Para conceder estas funções, siga os passos na secção Conceda uma única função na página Faça a gestão do acesso às contas de serviço.

  4. Quando a conta de serviço do trabalhador gerida pelo utilizador e a tarefa estão em projetos diferentes, certifique-se de que a restrição booleana iam.disableCrossProjectServiceAccountUsage não é aplicada ao projeto proprietário da conta de serviço gerida pelo utilizador. Para mais informações, consulte o artigo Ative a associação de contas de serviço a vários projetos.

  5. Quando executar a tarefa da pipeline, especifique a sua conta de serviço.

    Java

    Use a opção --serviceAccount e especifique a sua conta de serviço quando executar a tarefa da pipeline a partir da linha de comandos: --serviceAccount=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Use a opção --service-account-email e especifique a sua conta de serviço quando executar a tarefa da pipeline como um modelo flexível: --service-account-email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Python

    Use a opção --service_account_email e especifique a sua conta de serviço quando executar a tarefa da pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

    Go

    Use a opção --service_account_email e especifique a sua conta de serviço quando executar a tarefa da pipeline: --service_account_email=SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com

A conta de serviço gerida pelo utilizador pode estar no mesmo projeto que a sua tarefa ou num projeto diferente. Se a conta de serviço e a tarefa estiverem em projetos diferentes, tem de configurar a conta de serviço antes de executar a tarefa.

Adicione funções

Para adicionar funções no seu projeto, siga estes passos.

Consola

  1. Na Google Cloud consola, aceda à página IAM.

    Aceda ao IAM

  2. Selecione o seu projeto.

  3. Na linha que contém a sua conta de utilizador, clique em Editar principal, e, de seguida, clique em Adicionar outra função.

  4. Na lista pendente, selecione a função Utilizador da conta de serviço.

  5. Na linha que contém a sua conta de serviço de trabalhador, clique em Editar principal e, de seguida, clique em Adicionar outra função.

  6. Na lista pendente, selecione a função Dataflow Worker.

  7. Se a sua conta de serviço de trabalho precisar da função de administrador do Dataflow, repita o processo para o administrador do Dataflow.

  8. Repita o processo para todas as funções necessárias aos recursos usados no seu trabalho e, de seguida, clique em Guardar.

    Para mais informações sobre a concessão de funções, consulte o artigo Conceda uma função de IAM através da consola.

CLI gcloud

  1. Conceda a função roles/iam.serviceAccountUser à sua conta de utilizador. Execute o seguinte comando:

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

  2. Conceda funções à sua conta de serviço de trabalho. Execute o comando seguinte para a roles/dataflow.workerfunção do IAM e para todas as funções necessárias pelos recursos usados no seu trabalho. Se a sua conta de serviço de trabalho precisar da função de administrador do Dataflow, repita o processo para a roles/dataflow.adminfunção do IAM. Este exemplo usa a conta de serviço predefinida do Compute Engine, mas recomendamos que use uma conta de serviço gerida pelo utilizador.

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

Aceda a Google Cloud recursos

Os seus pipelines do Apache Beam podem aceder a Google Cloud recursos, quer no mesmo Google Cloud projeto ou noutros projetos. Estes recursos incluem:

Para garantir que o pipeline do Apache Beam pode aceder a estes recursos, tem de usar os respetivos mecanismos de controlo de acesso dos recursos para conceder explicitamente acesso à conta de serviço do trabalhador do seu projeto do Dataflow.

Se usar funcionalidades dos Assured Workloads com o Dataflow, como as regiões da UE e o apoio técnico com controlos de soberania, todos os conetores do Cloud Storage, BigQuery, Pub/Sub, I/O e outros recursos aos quais a sua pipeline acede têm de estar localizados no projeto ou na pasta dos Assured Workloads da sua organização.

Se estiver a usar uma conta de serviço de worker gerida pelo utilizador ou a aceder a recursos noutros projetos, pode ser necessária uma ação adicional. Os exemplos seguintes partem do princípio de que é usada a conta de serviço predefinida do Compute Engine, mas também pode usar uma conta de serviço de trabalhador gerida pelo utilizador.

Aceda a repositórios do Artifact Registry

Quando usa contentores personalizados com o Dataflow, pode carregar artefactos para um repositório do Artifact Registry.

Para usar o Artifact Registry com o Dataflow, tem de conceder, pelo menos, o acesso de gravação do Artifact Registry (role/artifactregistry.writer) à conta de serviço do trabalhador que executa a tarefa do Dataflow.

Todo o conteúdo do repositório é encriptado através de Google-owned and Google-managed encryption keys ou chaves de encriptação geridas pelo cliente. O Artifact Registry usa o Google-owned and Google-managed encryption keys por predefinição e não é necessária nenhuma configuração para esta opção.

Aceda a contentores do Cloud Storage

Para conceder ao seu projeto do Dataflow acesso a um contentor do Cloud Storage, torne o contentor acessível à conta de serviço do trabalhador do seu projeto do Dataflow. No mínimo, a conta de serviço precisa de autorizações de leitura e escrita para o contentor e o respetivo conteúdo. Pode usar as autorizações de IAM para o Cloud Storage para conceder o acesso necessário.

Para conceder à conta de serviço do trabalhador as autorizações necessárias para ler e escrever num contentor, use o comando gcloud storage buckets add-iam-policy-binding. Este comando adiciona a conta de serviço do seu projeto do Dataflow a uma política ao nível do contentor.

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

Substitua o seguinte:

  • BUCKET_NAME: o nome do seu contentor do Cloud Storage
  • PROJECT_NUMBER: o número do projeto do Dataflow. Para encontrar o número do projeto, consulte o artigo Identificar projetos ou use o comando gcloud projects describe.
  • SERVICE_ACCOUNT_ROLE: a função de IAM, por exemplo storage.objectViewer

Para obter uma lista dos contentores do Cloud Storage num Google Cloud projeto, use o comando gcloud storage buckets list:

gcloud storage buckets list --project= PROJECT_ID

Substitua PROJECT_ID pelo ID do projeto.

A menos que tenha restrições das políticas organizacionais que limitam a partilha de recursos, pode aceder a um contentor que reside num projeto diferente do seu pipeline do Dataflow. Para mais informações sobre restrições de domínio, consulte o artigo Restringir identidades por domínio.

Se não tiver um contentor, crie um novo contentor. Em seguida, conceda à conta de serviço do trabalhador as autorizações necessárias para ler e escrever no contentor.

Também pode definir autorizações de contentores a partir da Google Cloud consola. Para mais informações, consulte o artigo Definir autorizações de contentores.

O Cloud Storage oferece dois sistemas para conceder aos utilizadores acesso aos seus contentores e objetos: o IAM e as listas de controlo de acesso (ACLs). Na maioria dos casos, o IAM é o método recomendado para controlar o acesso aos seus recursos.

  • O IAM controla as autorizações em todo o Google Cloud e permite-lhe conceder autorizações ao nível do contentor e do projeto. Para ver uma lista das funções de IAM associadas ao Cloud Storage e as autorizações contidas em cada função, consulte o artigo Funções de IAM para o Cloud Storage. Se precisar de mais controlo sobre as autorizações, crie uma função personalizada.

  • Se usar ACLs para controlar o acesso, certifique-se de que as autorizações da conta de serviço do trabalhador são consistentes com as suas definições do IAM. Devido à inconsistência entre as políticas do IAM e da LCA, o contentor do Cloud Storage pode tornar-se inacessível aos seus trabalhos do Dataflow quando o contentor do Cloud Storage é migrado do acesso detalhado para o acesso uniforme ao nível do contentor. Para mais informações, consulte as orientações sobre erros comuns.

Aceda a conjuntos de dados do BigQuery

Pode usar a API BigQueryIO para aceder a conjuntos de dados do BigQuery, quer no mesmo projeto onde está a usar o Dataflow, quer num projeto diferente. Para que a origem e o destino do BigQuery funcionem corretamente, as duas contas seguintes têm de ter acesso a quaisquer conjuntos de dados do BigQuery a partir dos quais a tarefa do Dataflow lê ou para os quais escreve:

Pode ter de configurar o BigQuery para conceder acesso explicitamente a estas contas. Consulte o artigo Controlo de acesso do BigQuery para mais informações sobre como conceder acesso a conjuntos de dados do BigQuery através da página do BigQuery ou da API BigQuery.

Entre as autorizações necessárias do BigQuery, a autorização do IAM é necessária pelo pipeline para aceder a um conjunto de dados do BigQuery.bigquery.datasets.get Normalmente, a maioria das funções de IAM do BigQuery inclui a autorização bigquery.datasets.get, mas a função roles/bigquery.jobUser é uma exceção.

Aceda a tópicos e subscrições do Pub/Sub

Para aceder a um tópico ou a uma subscrição do Pub/Sub, use as funcionalidades de gestão de identidades e acessos do Pub/Sub para configurar autorizações para a conta de serviço do trabalhador.

As autorizações das seguintes funções do Pub/Sub são relevantes:

  • O roles/pubsub.subscriber é obrigatório para consumir dados.
  • O roles/pubsub.editor é obrigatório para criar uma subscrição do Pub/Sub.
  • roles/pubsub.viewer é recomendado para que o Dataflow possa consultar as configurações de tópicos e subscrições. Esta configuração tem duas vantagens:
    • O fluxo de dados pode verificar a existência de definições não suportadas em subscrições que podem não funcionar como esperado.
    • Se a subscrição não usar o prazo de confirmação predefinido de 10 segundos, o desempenho melhora. O Dataflow prolonga repetidamente o prazo de confirmação de uma mensagem enquanto esta está a ser processada pelo pipeline. Sem autorizações do pubsub.viewer, o Dataflow não consegue consultar o prazo de confirmação e, por isso, tem de assumir um prazo predefinido. Esta configuração faz com que o Dataflow emita mais pedidos de modifyAckDeadline do que o necessário.
    • Se os VPC Service Controls estiverem ativados no projeto proprietário da subscrição ou do tópico, as regras de entrada baseadas no endereço IP não permitem que o Dataflow consulte as configurações. Neste caso, é necessária uma regra de entrada baseada na conta de serviço do trabalhador.

Para mais informações e alguns exemplos de código que demonstram como usar as funcionalidades de gestão de identidades e acessos do Pub/Sub, consulte Exemplo de utilização: comunicação entre projetos.

Aceda ao Firestore

Para aceder a uma base de dados do Firestore (no modo nativo ou no modo Datastore), adicione a sua conta de serviço do trabalhador do Dataflow (por exemplo, PROJECT_NUMBER-compute@developer.gserviceaccount.com) como editor do projeto proprietário da base de dados ou use uma função do Datastore mais restritiva, como roles/datastore.viewer. Além disso, ative a API Firestore em ambos os projetos a partir da biblioteca de APIs na Google Cloud consola.

Aceda a imagens para projetos com uma política de imagem segura

Se tiver uma política de imagem segura configurada para o seu projeto e a imagem de arranque estiver localizada noutro projeto, certifique-se de que a política de imagem segura está configurada para ter acesso à imagem. Por exemplo, se estiver a executar uma tarefa do Dataflow baseada em modelos, certifique-se de que o ficheiro de políticas inclui acesso ao projeto dataflow-service-producer-prod. Este Google Cloud projeto contém as imagens para tarefas de modelos.

Acesso e segurança dos dados

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

  • Dados do utilizador final. Estes dados são processados por um pipeline do Dataflow. Um pipeline típico lê dados de uma ou mais origens, implementa transformações dos dados e escreve os resultados num ou mais destinos. Todas as origens e destinos são serviços de armazenamento que não são geridos diretamente pelo Dataflow.

  • Dados operacionais. Estes dados incluem todos os metadados necessários para gerir um pipeline do Dataflow. Estes dados incluem metadados fornecidos pelo utilizador, como o nome de uma tarefa ou opções de pipeline, e metadados gerados pelo sistema, como um ID da tarefa.

O serviço Dataflow usa vários mecanismos de segurança para manter os seus dados seguros e privados. Estes mecanismos aplicam-se aos seguintes cenários:

  • Enviar um pipeline para o serviço
  • Avaliar uma pipeline
  • Pedir acesso à telemetria e às métricas durante e após a execução de um pipeline
  • Usar um serviço do Dataflow, como o Shuffle ou o Streaming Engine

Localidade dos dados

Todo o processamento de dados principal do Dataflow ocorre na região especificada no código do pipeline. Se não for especificada uma região, é usada a região predefinida us-central1. Se especificar essa opção no código do pipeline, a tarefa do pipeline pode, opcionalmente, ler e escrever a partir de origens e destinos noutras 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 em instâncias de VMs de trabalho individuais. Pode especificar a zona onde estas instâncias e a rede privada através da qual comunicam estão localizadas. Os cálculos auxiliares para a plataforma dependem de metadados, como localizações do Cloud Storage ou tamanhos de ficheiros.

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

Dados num envio de pipeline

As autorizações IAM do seu Google Cloud projeto controlam o acesso ao serviço Dataflow. Todos os responsáveis que tenham direitos de editor ou proprietário no seu projeto podem enviar pipelines para o serviço. Para enviar pipelines, tem de se autenticar através da CLI do Google Cloud. Depois de se autenticar, os seus pipelines são enviados através do protocolo HTTPS. Para obter instruções sobre como fazer a autenticação com as credenciais da sua conta Google Cloud , consulte o início rápido para o idioma que está a usar.

Dados numa avaliação de pipeline

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

Java

Por predefinição, as VMs do Compute Engine são eliminadas quando a tarefa do Dataflow é concluída, independentemente de a tarefa ser bem-sucedida ou falhar. Consequentemente, o Persistent Disk associado e todos os dados intermédios que possam estar armazenados no mesmo são eliminados. Os dados intermédios armazenados no Cloud Storage podem ser encontrados em sublocalizações do caminho do Cloud Storage que fornece como --stagingLocation ou --tempLocation. Se estiver a escrever a saída num ficheiro do Cloud Storage, podem ser criados ficheiros temporários na localização de saída antes de a operação `write` ser finalizada.

Python

Por predefinição, as VMs do Compute Engine são eliminadas quando a tarefa do Dataflow é concluída, independentemente de a tarefa ser bem-sucedida ou falhar. Consequentemente, o Persistent Disk associado e todos os dados intermédios que possam estar armazenados no mesmo são eliminados. Os dados intermédios armazenados no Cloud Storage podem ser encontrados em sublocalizações do caminho do Cloud Storage que fornece como --staging_location ou --temp_location. Se estiver a escrever a saída num ficheiro do Cloud Storage, podem ser criados ficheiros temporários na localização de saída antes de a operação `write` ser finalizada.

Go

Por predefinição, as VMs do Compute Engine são eliminadas quando a tarefa do Dataflow é concluída, independentemente de a tarefa ser bem-sucedida ou falhar. Consequentemente, o Persistent Disk associado e todos os dados intermédios que possam estar armazenados no mesmo são eliminados. Os dados intermédios armazenados no Cloud Storage podem ser encontrados em sublocalizações do caminho do Cloud Storage que fornece como --staging_location ou --temp_location. Se estiver a escrever a saída num ficheiro do Cloud Storage, podem ser criados ficheiros temporários na localização de saída antes de a operação `write` ser finalizada.

Dados nos registos e na telemetria da pipeline

As informações armazenadas no Cloud Logging são geradas principalmente pelo código no seu programa Dataflow. O serviço Dataflow também pode gerar dados de aviso e erro no Cloud Logging, mas estes dados são os únicos dados intermédios que o serviço adiciona aos registos. O Cloud Logging é um serviço global.

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

Dados nos serviços do Dataflow

Se usar o Dataflow Shuffle ou o Dataflow Streaming para o seu pipeline, não especifique as opções de pipeline de zona. Em alternativa, especifique a região e defina o valor para uma das regiões onde o Shuffle ou o streaming estão disponíveis. O Dataflow seleciona automaticamente a zona na região que especificar. Os dados do utilizador final em trânsito permanecem nas VMs de trabalho e na mesma zona. Estas tarefas do Dataflow continuam a poder ler e escrever em origens e destinos que estão fora da zona da VM. Os dados em trânsito também podem ser enviados para os serviços Dataflow Shuffle ou Dataflow Streaming. No entanto, os dados permanecem sempre na região especificada no código do pipeline.

Recomendamos que use os mecanismos de segurança disponíveis nos recursos de nuvem subjacentes do seu pipeline. Estes mecanismos incluem as capacidades de segurança dos dados das origens e dos destinos de dados, como o BigQuery e o Cloud Storage. Também é melhor não misturar diferentes níveis de confiança num único projeto.