Segurança e permissões do Cloud Dataflow

Os pipelines do Dataflow podem ser executados localmente (para realizar testes em conjuntos de dados pequenos) 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. Veja nas seções a seguir os papéis e as permissões associados aos pipelines locais e na nuvem, as configurações padrão e as maneiras de verificar as permissões do seu projeto.

Antes de começar

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

Segurança e permissões para pipelines locais

Conta do Google Cloud Platform

Quando você executa localmente, o pipeline do Apache Beam é executado como a conta do Google Cloud que você configurou com o executável da ferramenta de linha de comando gcloud. Dessa forma, as operações de SDK do Apache Beam executadas no local têm acesso aos mesmos arquivos e recursos acessados pela conta do Google Cloud.

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

Observação: os pipelines locais podem enviar dados para destinos no mesmo lugar, 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 o padrão da ferramenta de linha de comando gcloud. 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.

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

Quando você executa seu 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 e a conta de serviço do controlador. O serviço Dataflow usa a conta de serviço do Dataflow como parte da solicitação de criação de jobs (por exemplo, verificar a cota do projeto e criar instâncias de worker em seu nome) e durante a execução do job para gerenciá-lo. As instâncias de worker usam a conta de serviço do controlador para acessar recursos de entrada e saída depois que você envia seu job.

Conta de serviço do Cloud Dataflow

Como parte da execução do pipeline do Dataflow, o serviço Dataflow manipula recursos em seu nome (por exemplo, criando VMs adicionais). Ao executar o pipeline no serviço do Dataflow, ele usa uma conta de serviço (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com). Essa conta é criada automaticamente junto com um projeto do Dataflow, recebe o papel de Agente de Serviços no projeto e as permissões para executar um job nele, incluindo iniciar os workers no Compute Engine. A conta é usada exclusivamente pelo serviço Dataflow e é específica para seu projeto.

É possível analisar as permissões das contas do serviço do Dataflow usando a ferramenta de linha de comando gcloud. Basta digitar o seguinte comando no seu shell ou terminal:

gcloud iam roles describe roles/dataflow.serviceAgent

Como os serviços do Google Cloud esperam ter acesso de leitura/gravação ao projeto e aos recursos, é recomendável não mudar as permissões padrão estabelecidas automaticamente para seu projeto. Se você remover as permissões da conta de serviço da política do Cloud Identity and Access Management (Cloud IAM), as contas continuarão presentes, porque são de propriedade do serviço Dataflow. Se uma conta de serviço do Dataflow perder permissões para um projeto, o Dataflow não poderá iniciar as VMs e executar outras tarefas de gerenciamento.

Prática recomendada: crie um bucket de propriedade do seu projeto para usar como bucket de teste para o Dataflow. Com isso, as permissões serão configuradas de maneira automática e correta para a preparação dos arquivos executáveis do pipeline.

Conta de serviço do controlador

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 controlador do projeto para acessar os arquivos e outros recursos do pipeline. O Dataflow também usa a conta de serviço do controlador para executar operações de "metadados", que não são executadas no cliente local nem nos workers do Compute Engine. Essas operações realizam tarefas como determinar tamanhos de entrada e acessar arquivos do Cloud Storage.

Conta de serviço do controlador padrão

Por padrão, os workers usam a conta de serviço do Compute Engine do projeto como a conta de serviço do controlador. Essa conta de serviço (<project-number>-compute@developer.gserviceaccount.com) é criada automaticamente quando você ativa a API Compute Engine para seu projeto na página APIs do Console do Google Cloud.

Além disso, a conta de serviço do Compute Engine associada a um projeto tem acesso aos buckets do Cloud Storage e aos recursos do projeto por padrão. Como a maioria dos workers do Compute Engine precisa ter acesso de leitura e gravação aos recursos do projeto, é recomendável não mudar as permissões padrão estabelecidas automaticamente para o projeto.

Você pode conferir uma lista das contas de serviço do seu projeto na página Permissões do Console do Cloud.

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

Se você quiser criar e usar recursos com acesso e controle mais detalhados, é possível usar uma conta de serviço do projeto do seu job como a conta de serviço do controlador gerenciada pelo usuário.

Se você não tiver uma conta de serviço gerenciada pelo usuário, será preciso criar uma conta de serviço que esteja no mesmo projeto do seu job e definir os papéis do IAM exigidos da sua conta de serviço. A conta de serviço precisa ter no mínimo o papel de worker do Dataflow. A conta de serviço também pode precisar de outros papéis para usar os recursos do Cloud Platform exigidos pelo job, como BigQuery, Pub/Sub ou gravação no Cloud Storage. Por exemplo, se o job fizer leituras no BigQuery, a conta de serviço também precisará ter, pelo menos, o papel de bigquery.dataViewer.

Java

Use a opção --serviceAccount e especifique a conta de serviço ao executar o job do pipeline: --serviceAccount=my-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=my-service-account-name@<project-id>.iam.gserviceaccount.com

Como acessar recursos do Google Cloud Platform em vários projetos da plataforma

Seus pipelines do Apache Beam podem acessar recursos do Google Cloud em outros projetos do Google Cloud. São eles:

Java

  • Buckets do Cloud Storage
  • conjuntos de dados do BigQuery
  • tópicos e assinaturas do Pub/Sub
  • conjuntos de dados do Datastore

Python

  • Buckets do Cloud Storage
  • conjuntos de dados do BigQuery
  • tópicos e assinaturas do Pub/Sub
  • conjuntos de dados do Datastore

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

Como acessar os buckets do Cloud Storage em projetos do Google Cloud Platform

Para conceder ao seu projeto do Dataflow acesso a um bucket do Cloud Storage que pertence a outro projeto do Google Cloud, torne o bucket acessível à conta de serviço do controlador do projeto do Dataflow Use os controles de acesso do Cloud Storage para conceder o acesso necessário.

Observação: caso as contas de serviço padrão não sejam usadas, verifique se as permissões estão consistentes com as configurações do IAM.

Para conferir uma lista das contas de serviço do seu projeto do Dataflow, verifique a página IAM e administrador no Console do Cloud. Depois de receber os nomes das contas, será possível executar comandos gsutil para conceder a propriedade da conta de serviço do projeto (permissão de leitura e gravação) para o bucket e os conteúdos dele.

Para conceder acesso a um bucket do Cloud Storage às contas de serviço do projeto do Dataflow em outro projeto, use o seguinte comando no shell ou na janela de terminal: gsutil acl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Para conceder acesso a conteúdo existente de um bucket do Cloud Storage às contas de serviço do projeto do Dataflow em outro projeto, use o seguinte comando no shell ou na janela de terminal: gsutil -m acl ch -r -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Observação: a opção -m executa o comando em paralelo para processamento mais rápido, e a opção -r executa o comando de forma recorrente em recursos dentro do bucket.

O comando anterior apenas concede acesso aos recursos atuais. Conceder a permissão padrão às contas de serviço do projeto do Dataflow dá acesso aos futuros recursos adicionados ao bucket: gsutil defacl ch -u <project-number>-compute@developer.gserviceaccount.com:OWNER gs://<bucket>

Como acessar os conjuntos de dados do BigQuery em projetos do Google Cloud Platform

Você pode usar a API BigQueryIO para acessar conjuntos de dados do BigQuery pertencentes a outro projeto do Google Cloud, ou seja, não o projeto em que está usando o Dataflow. 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:

Talvez seja 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 IU da Web do BigQuery ou a API do BigQuery.

Por exemplo, se sua conta do Google Cloud for abcde@gmail.com e o número do projeto onde você executa o job do Dataflow for 123456789, todas as contas a seguir precisam ter acesso aos conjuntos de dados do BigQuery usados: abcde@gmail.com e 123456789-compute@developer.gserviceaccount.com.

Como acessar os tópicos e as assinaturas do Cloud Pub/Sub nos projetos do Google Cloud Platform

Para acessar um tópico do Pub/Sub ou uma assinatura pertencente a outro projeto do Google Cloud, use os recursos de gerenciamento de identidade e acesso do Pub/Sub para configurar permissões entre projetos. O Dataflow usa a conta de serviço do controlador para executar seus jobs, e você precisa conceder a essa conta de serviço acesso aos recursos do Pub/Sub no outro projeto.

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

  • roles/pubsub.subscriber
  • roles/pubsub.viewer

Consulte Exemplo de caso de uso: comunicação entre projetos 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.

Como acessar o Cloud Datastore em projetos do Cloud Platform

Para acessar um Datastore pertencente a outro projeto do Google Cloud, adicione a conta de serviço do Compute Engine (<project-number>-compute@developer.gserviceaccount.com) do seu projeto do Dataflow como editor do projeto proprietário do Datastore. Você também precisa ativar a API Datastore em ambos os projetos em https://console.cloud.google.com/project/<project-id>/apiui/apiview/datastore/overview.

Acesso e segurança dos dados

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:

  • Quando você envia um pipeline para o serviço.
  • Quando o serviço avalia o pipeline.
  • Quando você solicita acesso à telemetria e métricas durante e após a execução do pipeline.

Envio de pipeline

As permissões do projeto do Google Cloud controlam o acesso ao serviço Dataflow. Qualquer membro do projeto com direitos de edição e proprietário pode enviar pipelines para o serviço. Para enviar pipelines, faça a autenticação usando a ferramenta de linha de comando gcloud. Após a autenticação, os pipelines são enviados usando o protocolo HTTPS. 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.

Avaliação do pipeline

Dados temporários

Como parte da avaliação de um canal, os dados temporários podem ser gerados e armazenados localmente nos workers 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 canal.

Java

Por padrão, as VMs do Compute Engine são excluídas quando o job do Dataflow é concluído, sem levar em conta o status de êxito ou falha do job. Isso significa que o disco permanente associado 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 e/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, sem levar em conta o status de êxito ou falha do job. Isso significa que o disco permanente associado 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 e/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 registrados

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.

Dados em trânsito

Há dois modos de transmissão dos dados durante a avaliação do canal:

  • Durante a leitura/gravação de origens e coletores
  • Entre instâncias de workers, enquanto os dados estão sendo processados no próprio pipeline

Todas as comunicações com origens e coletores do Google Cloud são criptografadas e transmitidas por HTTPS. Todas as comunicações entre trabalhadores ocorrem em uma rede privada e estão sujeitas às permissões e regras de firewall do projeto.

Localidade dos dados

A lógica de um canal é avaliada nas instâncias individuais do Compute Engine. Especifique a zona em que essas instâncias e a rede privada usada para se comunicarem estão localizadas. Os cálculos complementares que ocorrem na infraestrutura do Google dependem de metadados, como tamanhos de arquivo ou locais do Cloud Storage. Os dados nunca deixam a zona nem rompem os limites de segurança.

Telemetria e métricas

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.

Recomendamos o uso dos mecanismos de segurança disponíveis nos recursos em nuvem de base do canal. 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.