Caso de uso: controle de acesso para um cluster do Managed Service for Apache Spark em outro projeto

Esta página descreve como gerenciar o controle de acesso ao implantar e executar um pipeline que usa clusters do Managed Service for Apache Spark em outro Google Cloud projeto.

Cenário

Por padrão, quando uma instância do Cloud Data Fusion é iniciada em um Google Cloud projeto, ela implanta e executa pipelines usando clusters do Managed Service for Apache Spark no mesmo projeto. No entanto, sua organização pode exigir que você use clusters em outro projeto. Para esse caso de uso, é necessário gerenciar o acesso entre os projetos. A página a seguir descreve como mudar as configurações de referência (padrão) e aplicar os controles de acesso adequados.

Antes de começar

Para entender as soluções neste caso de uso, você precisa do seguinte contexto:

Premissas e escopo

Esse caso de uso tem os seguintes requisitos:

  • Uma instância particular do Cloud Data Fusion. Por motivos de segurança, uma organização pode exigir que você use esse tipo de instância.
  • Uma origem e um coletor do BigQuery.
  • Controle de acesso com o IAM, não controle de acesso baseado em papéis (RBAC).

Solução

Essa solução compara a arquitetura e a configuração de referência e específicas do caso de uso.

Arquitetura

Os diagramas a seguir comparam a arquitetura do projeto para criar uma instância do Cloud Data Fusion e executar pipelines ao usar clusters no mesmo projeto (referência) e em um projeto diferente pela VPC do projeto de locatário.

Arquitetura de referência

Este diagrama mostra a arquitetura de referência dos projetos:

Arquitetura de projeto de locatário, cliente e Dataproc no Cloud Data Fusion.

Para a configuração de referência, crie uma instância particular do Cloud Data Fusion e execute um pipeline sem personalização adicional:

  • Você usa um dos perfis de computação integrados
  • A origem e o coletor estão no mesmo projeto que a instância
  • Nenhum papel adicional foi concedido a nenhuma das contas de serviço

Para mais informações sobre projetos de locatário e de cliente, consulte Rede.

Arquitetura de caso de uso

Este diagrama mostra a arquitetura do projeto quando você usa clusters em outro projeto:

Arquitetura de projeto de locatário, cliente e Dataproc no Cloud Data Fusion.

Configurações

As seções a seguir comparam as configurações de referência com as configurações específicas do caso de uso para usar clusters do Managed Service for Apache Spark em um projeto diferente pela VPC padrão do projeto de locatário.

Nas descrições de caso de uso a seguir, o projeto do cliente é onde a instância do Cloud Data Fusion é executada, e o projeto do Managed Service for Apache Spark é onde o cluster do Managed Service for Apache Spark é iniciado.

VPC e instância do projeto de locatário

Valor de referência Caso de uso
No diagrama de arquitetura de referência anterior, o projeto de locatário contém os seguintes componentes:
  • A VPC padrão, que é criada automaticamente.
  • A implantação física da instância do Cloud Data Fusion.
 Nenhuma configuração adicional é necessária para esse caso de uso.

Projeto do cliente

Valor de referência Caso de uso
O projeto do cliente é onde você implanta e exec0/}uta pipelines. Google Cloud Por padrão, os clusters do Managed Service for Apache Spark são iniciados nesse projeto quando você executa os pipelines. Nesse caso de uso, você gerencia dois projetos. Nesta página, o projeto do cliente se refere a onde a instância do Cloud Data Fusion é executada.
O projeto do Managed Service for Apache Spark se refere a onde os clusters do Managed Service for Apache Spark são iniciados.

VPC do cliente

Valor de referência Caso de uso

Do seu ponto de vista (do cliente), a VPC do cliente é onde o Cloud Data Fusion está logicamente situado.


Principal conclusão:
É possível encontrar os detalhes da VPC do cliente na página "Redes VPC" do seu projeto.

Acesse as redes VPC

 Nenhuma configuração adicional é necessária para esse caso de uso.

Sub-rede do Cloud Data Fusion

Valor de referência Caso de uso

Do seu ponto de vista (do cliente), essa sub-rede é onde Cloud Data Fusion está logicamente situado.


Principal conclusão:
A região dessa sub-rede é a mesma que o local da instância do Cloud Data Fusion no projeto de locatário. 		Nenhuma configuração adicional é necessária para esse caso de uso.

Sub-rede do Managed Service for Apache Spark

Valor de referência Caso de uso

A sub-rede em que os clusters do Managed Service for Apache Spark são iniciados quando você executa um pipeline.


Principais conclusões:
  • Para essa configuração de referência, o Managed Service for Apache Spark é executado em a mesma sub-rede que a instância do Cloud Data Fusion.
  • O Cloud Data Fusion localiza uma sub-rede na mesma região que a instância e a sub-rede do Cloud Data Fusion. Se houver apenas uma sub-rede nessa região, as sub-redes serão as mesmas.
  • A sub-rede do Managed Service for Apache Spark precisa ter Acesso privado do Google.

Essa é uma nova sub-rede em que os clusters do Managed Service for Apache Spark são iniciados quando você executa um pipeline.


Principais conclusões:
  • Para essa nova sub-rede, defina o Acesso privado do Google como Ativado.
  • A sub-rede do Managed Service for Apache Spark não precisa estar no mesmo local que a instância do Cloud Data Fusion.

Origens e coletores

Valor de referência Caso de uso

As origens em que os dados são extraídos e os coletores em que os dados são carregados, como origens e coletores do BigQuery.


Principal conclusão:
  • Os jobs que buscam e carregam dados precisam ser processados no mesmo local que o conjunto de dados. Caso contrário, um erro será gerado.
 As configurações de controle de acesso específicas do caso de uso nesta página são para BigQuery sources and sinks.

Cloud Storage

Valor de referência Caso de uso

O bucket de armazenamento no projeto do cliente que ajuda a transferir arquivos entre o Cloud Data Fusion e o Managed Service for Apache Spark.


Principais conclusões:
  • É possível especificar esse bucket pela interface da Web do Cloud Data Fusion nas configurações do Perfil de computação para clusters efêmeros.
  • Para pipelines em lote e em tempo real ou jobs de replicação: se você não especificar um bucket no perfil de computação, o Cloud Data Fusion vai criar um bucket no mesmo projeto que a instância para essa finalidade.
  • Mesmo para clusters estáticos do Managed Service for Apache Spark, nessa configuração de referência, o bucket é criado pelo Cloud Data Fusion e difere dos buckets de preparo e temporários do Managed Service for Apache Spark.
  • O agente de serviço da API Data Fusion tem permissões integradas para criar esse bucket no projeto que contém a instância do Cloud Data Fusion.
 Nenhuma configuração adicional é necessária para esse caso de uso.

Buckets temporários usados pela origem e pelo coletor

Valor de referência Caso de uso

Os buckets temporários criados por plug-ins para suas origens e coletores, como os jobs de carregamento iniciados pelo plug-in do coletor do BigQuery.


Principais conclusões:
  • É possível definir esses buckets ao configurar as propriedades do plug-in de origem e coletor
  • Se você não definir um bucket, um será criado no mesmo projeto onde o Managed Service for Apache Spark é executado.
  • Se o conjunto de dados for multirregional, o bucket será criado no mesmo escopo.
  • Se você definir um bucket na configuração do plug-in, a região do bucket precisará corresponder à região do conjunto de dados.
  • Se você não definir um bucket nas configurações do plug-in, o bucket criado será excluído quando o pipeline terminar.
 Para esse caso de uso, o bucket pode ser criado em qualquer projeto.

Buckets que são origens ou coletores de dados para plug-ins

Valor de referência Caso de uso
Buckets do cliente, que você especifica nas configurações de plug-ins, como o plug-in do Cloud Storage e o plug-in FTP para Cloud Storage. Nenhuma configuração adicional é necessária para esse caso de uso.

IAM: agente de serviço da API Data Fusion

Valor de referência Caso de uso

Quando a API Data Fusion está ativada, o papel de agente de serviço da API Data Fusion (roles/datafusion.serviceAgent) é concedido automaticamente à conta de serviço do Cloud Data Fusion, o agente de serviço principal.


Principais conclusões:
  • O papel contém permissões para serviços no mesmo projeto que a instância, como o BigQuery e o Managed Service for Apache Spark. Para todos os serviços compatíveis, consulte os detalhes do papel.
  • A conta de serviço do Cloud Data Fusion faz o seguinte:
    • Comunicação do plano de dados (design e execução de pipeline) com outros serviços (por exemplo, comunicação com Cloud Storage, BigQuery e Datastream no momento do design).
    • Provisiona clusters do Managed Service for Apache Spark.
  • Se você estiver replicando de uma origem Oracle, essa conta de serviço também precisará receber os papéis de administrador do Datastream e administrador do Storage no projeto em que o job ocorre. Esta página não aborda um caso de uso de replicação.

Para esse caso de uso, conceda o papel de agente de serviço da API Data Fusion do Cloud Data Fusion à conta de serviço no projeto do Managed Service for Apache Spark. Em seguida, conceda os seguintes papéis nesse projeto:

  • Papel Usuário de rede do Compute
  • Papel de editor do Dataproc

IAM: conta de serviço do Managed Service for Apache Spark

Valor de referência Caso de uso

A conta de serviço usada para executar o pipeline como um job no Managed Service for Apache Spark cluster. Por padrão, é a conta de serviço do Compute Engine.


Opcional: na configuração de referência, é possível mudar a conta de serviço padrão para outra conta de serviço do mesmo projeto. Conceda os seguintes papéis do IAM à nova conta de serviço:

  • O papel de executor do Cloud Data Fusion. Esse papel permite que o Managed Service for Apache Spark se comunique com a API Data Fusion.
  • O papel de worker do Dataproc. Esse papel permite que os jobs sejam executados em clusters do Managed Service for Apache Spark.
Principais conclusões:
  • A conta de serviço do agente de API para o novo serviço precisa receber o papel de usuário da conta de serviço na conta de serviço do Managed Service for Apache Spark para que o agente de API de serviço possa usá-la para iniciar clusters do Managed Service for Apache Spark.

Este exemplo de caso de uso pressupõe que você use a conta de serviço padrão do Compute Engine (PROJECT_NUMBER-compute@developer.gserviceaccount.com) do projeto do Managed Service for Apache Spark.


Conceda os seguintes papéis à conta de serviço padrão do Compute Engine no projeto do Managed Service for Apache Spark.

  • O papel de worker do Dataproc
  • O papel de administrador do Storage (ou, no mínimo, a permissão `storage.buckets.create`) para permitir que o Managed Service for Apache Spark crie buckets temporários para o BigQuery.
  • Papel de usuário do job do BigQuery. Esse papel permite que o Managed Service for Apache Spark crie jobs de carregamento. Os jobs são criados no projeto do Managed Service for Apache Spark por padrão.
  • Papel de editor de conjuntos de dados do BigQuery. Esse papel permite que o Managed Service for Apache Spark crie conjuntos de dados ao carregar dados.

Conceda a função de usuário da conta de serviço à conta de serviço do Cloud Data Fusion na conta de serviço padrão do Compute Engine do projeto do Managed Service for Apache Spark. Essa ação precisa ser realizada no projeto do Managed Service for Apache Spark.

Adicione a conta de serviço padrão do Compute Engine do projeto do Managed Service for Apache Spark ao projeto do Cloud Data Fusion. Conceda também os seguintes papéis:

  • O papel de leitor de objetos do Storage para recuperar artefatos relacionados ao job do pipeline do bucket do consumidor do Cloud Data Fusion.
  • Papel de executor do Cloud Data Fusion, para que o cluster do Managed Service for Apache Spark possa se comunicar com o Cloud Data Fusion enquanto estiver em execução.

APIs

Valor de referência Caso de uso
Quando você ativa a API Cloud Data Fusion, as APIs a seguir também são ativadas. Para mais informações sobre essas APIs, acesse a página "APIs e serviços" no seu projeto.

Acessar APIs e serviços

  • API de escalonamento automático do Cloud
  • API Dataproc
  • API Cloud Dataproc Control
  • Cloud DNS API
  • API Login do SO
  • API Pub/Sub
  • API Compute Engine
  • API Container Filesystem
  • API Container Registry
  • API Service Account Credentials
  • API Identity and Access Management
  • API Kubernetes Engine

Quando você ativa a API Data Fusion, as seguintes contas de serviço são adicionadas automaticamente ao seu projeto:

  • Agente de serviço de APIs do Google
  • Agente de serviço do Compute Engine
  • Agente de serviço do Kubernetes Engine
  • Agente de serviço do Google Container Registry
  • Agente de serviços do Google Cloud Dataproc
  • Agente de serviço do Cloud KMS
  • Conta de serviços do Cloud Pub/Sub
 Para esse caso de uso, ative as seguintes APIs no projeto que contém o projeto do Managed Service for Apache Spark:
  • API Compute Engine
  • API Dataproc (é provável que já esteja ativada nesse projeto). A API Dataproc Control é ativada automaticamente quando você ativa a API Dataproc.
  • API Resource Manager.

Chaves de criptografia

Valor de referência Caso de uso

Na configuração de referência, as chaves de criptografia podem ser gerenciadas pelo Google ou CMEK


Principais conclusões:

Se você usar a CMEK, a configuração de referência vai exigir o seguinte:

  • A chave precisa ser regional, criada na mesma região que a Cloud Data Fusion instance.
  • Conceda o papel Criptografador/Descriptografador do Cloud KMS CryptoKey às seguintes contas de serviço no nível da chave (não na página do IAM do Google Cloud console) no projeto em que ela é criada:
    • Conta de serviço da API Data Fusion
    • Conta de serviço do Managed Service for Apache Spark, que é o agente de serviço do Compute Engine (service-PROJECT_NUMBER@compute-system.iam.gserviceaccount.com) por padrão
    • Agente de serviços do Google Cloud Dataproc (service-PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com)
    • Agente de serviço do Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Dependendo dos serviços usados no pipeline, como BigQuery ou Cloud Storage, as contas de serviço também precisam receber o papel Criptografador/Descriptografador do Cloud KMS CryptoKey:

  • A conta de serviço do BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • A conta de serviço do Pub/Sub (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • A conta de serviço do Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Se você não usar a CMEK, nenhuma mudança adicional será necessária para esse caso de uso.

Se você usar a CMEK, o papel Criptografador/Descriptografador do Cloud KMS CryptoKey precisará ser fornecido à seguinte conta de serviço no nível da chave no projeto em que ela é criada:

  • Agente de serviço do Cloud Storage (service-PROJECT_NUMBER@gs-project-accounts.iam.gserviceaccount.com)

Dependendo dos serviços usados no pipeline, como BigQuery ou Cloud Storage, outras contas de serviço também precisam receber o papel Criptografador/Descriptografador do Cloud KMS CryptoKey no nível da chave. Exemplo:

  • A conta de serviço do BigQuery (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com)
  • A conta de serviço do Pub/Sub (service-PROJECT_NUMBER@gcp-sa-pubsub.iam.gserviceaccount.com)
  • A conta de serviço do Spanner (service-PROJECT_NUMBER@gcp-sa-spanner.iam.gserviceaccount.com)

Depois de fazer essas configurações específicas do caso de uso, o pipeline de dados poderá começar a ser executado em clusters em outro projeto.

A seguir