Segurança e permissões do 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. 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 em projetos.
  • 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 da plataforma. Esses identificadores incluem o nome, o ID e o número do projeto.

Como fazer upgrade e aplicar patches nas 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 são vinculados ao tempo e não exigem 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, seu 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. 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.

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 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.

  • A conta de serviço do worker. 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 do serviço Dataflow

Como parte da execução do pipeline do Dataflow, o serviço Dataflow manipula recursos em seu nome (por exemplo, criando VMs adicionais). Quando você executa o pipeline no serviço do Dataflow, ele usa a conta de serviço do Dataflow (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com). A conta de serviço do Dataflow é criada na primeira vez em que o recurso Dataflow Job é usado. Essa conta recebe o papel de agente de serviço do Dataflow no projeto e tem as permissões necessárias para executar um job do Dataflow no projeto, incluindo a inicialização dos workers do Compute Engine. A conta é usada exclusivamente pelo serviço Dataflow e é específica para seu projeto.

Revise as permissões da conta de serviço do Dataflow no Console do Cloud ou na ferramenta de linha de comando gcloud.

Console

  1. Acesse a página Papéis.

    Acessar "Papéis"

  2. Na barra de ferramentas do Console do Cloud, selecione o projeto.

  3. Para visualizar as permissões da conta de serviço do Dataflow, marque a caixa de seleção Incluir concessões de papel fornecidas pelo Google no canto superior direito e marque a caixa de seleção Agente de serviço do Cloud Dataflow. de dados.

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/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 de gerenciamento de identidade e acesso (IAM, na sigla em inglês), as contas continuarão presentes, porque são de propriedade do serviço Dataflow. 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.

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 do pipeline. A conta de serviço do worker é usada como a identidade de todas as VMs de worker. Todas as solicitações originadas da VM usam a conta de serviço de 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 controlador possa criar, executar e examinar um job, verifique se ele tem os papéis roles/dataflow.admin e roles/dataflow.worker. Além disso, a permissão iam.serviceAccounts.actAs é necessária para sua conta de usuário para personificar a conta de serviço.

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 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 Biblioteca de APIs do Console do Cloud.

A conta de serviço padrão do Compute Engine tem amplo acesso aos recursos do projeto, o que facilita os primeiros passos com o Dataflow. No entanto, para cargas de trabalho de produção, recomendamos criar uma nova conta de serviço apenas com os papéis e permissões necessários.

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

Se você quiser criar e usar recursos com um controle de acesso detalhado, crie uma conta de serviço gerenciada pelo usuário e use-a como a conta de serviço do controlador.

Se você não tiver uma conta de serviço gerenciada pelo usuário, será preciso criar uma conta de serviço 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 Google Cloud 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 roles/bigquery.dataViewer. 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.

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. Você também precisa conceder o papel Criador de token da conta de serviço às seguintes contas de serviço gerenciadas pelo Google na conta de serviço gerenciada pelo usuário:

  • Conta de serviço padrão do Compute Engine (<project-number>-compute@developer.gserviceaccount.com)
  • Agente de serviço do Dataflow (service-<project-number>@dataflow-service-producer-prod.iam.gserviceaccount.com)

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

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

Como acessar recursos do Google Cloud em vários projetos do Google Cloud

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

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 fornecer ao projeto do Dataflow acesso a um bucket do Cloud Storage de 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.

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>

O comando anterior concede acesso apenas a recursos existentes. 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

Use a API BigQueryIO para acessar conjuntos de dados do BigQuery pertencentes a um projeto diferente do Google Cloud, ou seja, um projeto diferente do 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:

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.

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 tópicos e assinaturas do Pub/Sub nos projetos do Google Cloud

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 os jobs e concede a essa conta de serviço acesso aos recursos do Pub/Sub do outro projeto.

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

  • roles/pubsub.subscriber: para consumir dados e criar assinaturas
  • roles/pubsub.viewer: para consultar a configuração de tópicos e assinaturas. Para estender os prazos adequadamente, o Dataflow precisa acessar os prazos de confirmação de assinaturas Além disso, essa permissão permite que o Dataflow verifique configurações não compatíveis em assinaturas e tópicos que podem causar problemas.

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 Firestore em projetos do Google Cloud

Para acessar um banco de dados do Firestore (no modo nativo ou no modo Datastore) de 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 Firestore 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.

Como 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 é um projeto do Cloud que contém as imagens dos 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 são os dados 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. Um job de pipeline pode opcionalmente ler e gravar a partir de origens e coletores em outras regiões se você especificar essa opção no código do pipeline. 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 endpoints regionais e localidade de dados, consulte Endpoints regionais.

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 ferramenta de linha de comando gcloud. Depois da 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.

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. Isso significa que o Disco permanente associados 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, independentemente de êxito ou falha. Isso significa que o Disco permanente associados 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 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 da 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 selecionará automaticamente a zona na região que você especificou. 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 em nuvem de base do seu 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.