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 Serviço Gerenciado para Apache Spark em outro projeto Google Cloud .

Cenário

Por padrão, quando uma instância do Cloud Data Fusion é iniciada em um projetoGoogle Cloud , ela implanta e executa pipelines usando clusters do serviço gerenciado para Apache Spark no mesmo projeto. No entanto, sua organização pode exigir que você use clusters em outro projeto. Nesse caso de uso, é necessário gerenciar o acesso entre os projetos. A página a seguir descreve como mudar as configurações de base (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 com o controle de acesso baseado em papéis (RBAC).

Solução

Essa solução compara a arquitetura e a configuração de base e de caso de uso específico.

Arquitetura

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

Arquitetura de valor de referência

Este diagrama mostra a arquitetura de base dos projetos:

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

Para a configuração de base, 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 destino estão no mesmo projeto da instância.
  • Nenhum papel adicional foi concedido a nenhuma das contas de serviço

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

Arquitetura de caso de uso

Este diagrama mostra a arquitetura do projeto ao usar clusters em outro projeto:

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

Configurações

As seções a seguir comparam as configurações de base com as configurações específicas do caso de uso para usar clusters do Serviço Gerenciado para Apache Spark em um projeto diferente pela VPC padrão do projeto do 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 Serviço Gerenciado para Apache Spark é onde o cluster do Serviço Gerenciado para 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 Google Cloud é onde você implanta e executa pipelines. Por padrão, os clusters do Serviço Gerenciado para Apache Spark são iniciados nesse projeto quando você executa os pipelines. Neste 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 Serviço Gerenciado para Apache Spark se refere a onde os clusters do Serviço Gerenciado para 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 localizado.


Principal conclusão:
você encontra os detalhes da VPC do cliente na página de redes VPC do seu projeto.

Acessar 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 o Cloud Data Fusion está localizado logicamente.


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

Sub-rede do Serviço Gerenciado para Apache Spark

Valor de referência Caso de uso

A sub-rede em que os clusters do Serviço Gerenciado para Apache Spark são iniciados quando você executa um pipeline.


Principais conclusões:
  • Para essa configuração de base, o Serviço Gerenciado para Apache Spark é executado na mesma sub-rede que a instância do Cloud Data Fusion.
  • O Cloud Data Fusion localiza uma sub-rede na mesma região da instância e da sub-rede do Cloud Data Fusion. Se houver apenas uma sub-rede nessa região, elas serão iguais.
  • A sub-rede do Serviço Gerenciado para Apache Spark precisa ter o Acesso privado do Google.

Esta é uma nova sub-rede em que os clusters do Serviço Gerenciado para 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 Serviço Gerenciado para 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 de onde os dados são extraídos e os coletores em que são carregados, como origens e coletores do BigQuery.


Ponto-chave:
  • Os jobs que buscam e carregam dados precisam ser processados no mesmo local que o conjunto de dados. Caso contrário, um erro vai ocorrer.
 As configurações de controle de acesso específicas do caso de uso nesta página são para origens e destinos do BigQuery.

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 Serviço Gerenciado para Apache Spark.


Principais conclusões:
  • É possível especificar esse bucket na interface da Web do Cloud Data Fusion nas configurações de Perfil de computação para clusters temporários.
  • 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 da instância para essa finalidade.
  • Mesmo para clusters estáticos do Serviço Gerenciado para Apache Spark, nessa configuração de referência, o bucket é criado pelo Cloud Data Fusion e difere dos buckets temporários e de teste do Serviço Gerenciado para 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 destinos, como os jobs de carregamento iniciados pelo plug-in de destino do BigQuery.


Principais conclusões:
  • É possível definir esses intervalos ao configurar as propriedades do plug-in de origem e coletor.
  • Se você não definir um bucket, um será criado no mesmo projeto em que o Serviço Gerenciado para 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 dele precisará corresponder à região do conjunto de dados.
  • Se você não definir um bucket nas configurações do plug-in, o bucket criado para você será excluído quando o pipeline terminar.
 Para este caso de uso, o bucket pode ser criado em qualquer projeto.

Buckets que são fontes 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 de FTP para Cloud Storage. Nenhuma configuração adicional é necessária para esse caso de uso.

IAM: agente de serviço da API Cloud Data Fusion

Valor de referência Caso de uso

Quando a API Data Fusion é ativada, a função de agente de serviço da API Data Fusion (roles/datafusion.serviceAgent) é concedida automaticamente à conta de serviço do Cloud Data Fusion, o agente de serviço principal.


Principais conclusões:
  • A função contém permissões para serviços no mesmo projeto da instância, como BigQuery e Serviço Gerenciado para Apache Spark. Para todos os serviços compatíveis, consulte os detalhes da função.
  • 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 Serviço Gerenciado para Apache Spark.
  • Se você estiver replicando de uma origem do Oracle, essa conta de serviço também precisará receber os papéis de administrador do Datastream e 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 Cloud Data Fusion à conta de serviço no projeto do Serviço gerenciado para 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 Serviço Gerenciado para Apache Spark

Valor de referência Caso de uso

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


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

  • A função "Executor do Cloud Data Fusion". Essa função permite que o Serviço Gerenciado para Apache Spark se comunique com a API Cloud Data Fusion.
  • O papel de worker do Dataproc. Essa função permite que os jobs sejam executados em clusters do Serviço Gerenciado para Apache Spark.
Principais conclusões:
  • A conta de serviço do agente da API para o novo serviço precisa receber a função de usuário da conta de serviço na conta de serviço do Serviço Gerenciado para Apache Spark para que o agente da API de serviço possa usá-la para iniciar clusters do Serviço Gerenciado para 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 Serviço Gerenciado para Apache Spark.


Conceda os seguintes papéis à conta de serviço padrão do Compute Engine no projeto do Serviço Gerenciado para 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 Serviço Gerenciado para Apache Spark crie buckets temporários para o BigQuery.
  • Papel de usuário de jobs do BigQuery. Essa função permite que o Serviço Gerenciado para Apache Spark crie jobs de carregamento. Os jobs são criados por padrão no projeto do Serviço Gerenciado para Apache Spark.
  • Função de editor de conjunto de dados do BigQuery. Essa função permite que o Serviço Gerenciado para Apache Spark crie conjuntos de dados ao carregar dados.

Conceda o papel 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 Serviço gerenciado para Apache Spark. Essa ação precisa ser realizada no projeto do Serviço Gerenciado para Apache Spark.

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

  • O papel Leitor de objetos do Storage para recuperar artefatos relacionados a jobs de pipeline do bucket do consumidor do Cloud Data Fusion.
  • Função de executor do Cloud Data Fusion para que o cluster do Serviço gerenciado para 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 seguintes APIs 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 Cloud Autoscaling
  • API Dataproc
  • API Cloud Dataproc Control
  • Cloud DNS API
  • API Cloud OS Login
  • 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 Cloud 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 Serviço Gerenciado para Apache Spark, se elas ainda não estiverem ativadas:
  • API Compute Engine
  • API Dataproc
  • API Cloud Resource Manager

Chaves de criptografia

Valor de referência Caso de uso

Na configuração básica, as chaves de criptografia podem ser gerenciadas pelo Google ou CMEK .


Principais conclusões:

Se você usa a CMEK, a configuração de base exige o seguinte:

  • A chave precisa ser regional e criada na mesma região da instância do Cloud Data Fusion.
  • Conceda o papel Criptografador/descriptografador de CryptoKey do Cloud KMS às seguintes contas de serviço no nível da chave (não na página do IAM do console Google Cloud ) no projeto em que ela foi criada:
    • Conta de serviço da API Cloud Data Fusion
    • Conta de serviço do Serviço Gerenciado para 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ço 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 de criptografador/descriptografador de CryptoKey do Cloud KMS:

  • 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 usa a CMEK, não é necessário fazer outras mudanças para esse caso de uso.

Se você usar a CMEK, o papel de criptografia/descriptografia do CryptoKey do Cloud KMS precisará ser fornecido à seguinte conta de serviço no nível da chave no projeto em que ela foi 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 de criptografador/descriptografador de CryptoKey do Cloud KMS 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, seu pipeline de dados poderá começar a ser executado em clusters em outro projeto.

A seguir