Conta de serviço do Serverless para Apache Spark

O

Neste documento, descrevemos como visualizar e gerenciar papéis da conta de serviço do Identity and Access Management. Uma carga de trabalho em lote ou uma sessão interativa do Serverless para Apache Spark é executada como a conta de serviço padrão do Compute Engine, a menos que você especifique uma conta de serviço personalizada ao enviar uma carga de trabalho em lote, criar uma sessão ou criar um modelo de ambiente de execução de sessão.

Requisito de segurança:você precisa ter a permissão ActAs da conta de serviço para executar cargas de trabalho ou sessões do Serverless para Apache Spark. O papel Service Account User contém essa permissão. Para informações detalhadas sobre permissões da conta de serviço, consulte Papéis para autenticação da conta de serviço.

Papel de worker do Dataproc obrigatório

A conta de serviço da sessão ou da carga de trabalho sem servidor para Apache Spark precisa ter o papel do IAM Worker do Dataproc. A conta de serviço padrão do Compute Engine, project_number-compute@developer.gserviceaccount.com, que o Serverless para Apache Spark usa, tem esse papel por padrão. Se você especificar uma conta de serviço diferente ao criar uma carga de trabalho em lote, uma sessão ou um modelo de sessão, conceda o papel de worker do Dataproc à conta de serviço. Outras operações, como leitura e gravação de dados do e para o Cloud Storage ou o BigQuery, podem exigir papéis extras.

Em alguns projetos, a conta de serviço da carga de trabalho em lote ou da sessão pode ter recebido automaticamente o papel de Editor do projeto, que inclui as permissões do papel de worker do Dataproc e outras permissões que não são necessárias para o Serverless para Apache Spark. Para seguir o princípio de segurança de privilégio mínimo, substitua o papel Editor da conta de serviço pelo papel worker do Dataproc.

Resolver problemas de falhas baseadas em permissões

Permissões incorretas ou insuficientes para a conta de serviço usada pela carga de trabalho em lote ou sessão do Serverless para Apache Spark podem causar falhas na criação de lotes ou sessões que informam a mensagem de erro "Não foi possível inicializar o nó de computação do driver para o lote em 600 segundos". Esse erro indica que o driver do Spark não pôde ser iniciado dentro do período de tempo limite alocado, geralmente devido à falta de acesso necessário aos recursos do Google Cloud .

Para resolver esse problema, verifique se a conta de serviço tem os seguintes papéis ou permissões mínimas:

• Papel Worker do Dataproc (roles/dataproc.worker): concede as permissões necessárias para que o Serverless para Apache Spark gerencie e execute cargas de trabalho e sessões do Spark.
• Leitor de objetos do Storage (roles/storage.objectViewer), Criador de objetos do Storage (roles/storage.objectCreator) ou Administrador de objetos do Storage (roles/storage.admin): se o aplicativo Spark ler ou gravar em buckets do Cloud Storage, a conta de serviço precisará das permissões adequadas para acessar os buckets. Por exemplo, se os dados de entrada estiverem em um bucket do Cloud Storage, o Storage Object Viewer será obrigatório. Se o aplicativo gravar a saída em um bucket do Cloud Storage, será necessário usar Storage Object Creator ou Storage Object Admin.
• Editor de dados do BigQuery (roles/bigquery.dataEditor) ou Leitor de dados do BigQuery (roles/bigquery.dataViewer): se o aplicativo Spark interagir com o BigQuery, verifique se a conta de serviço tem as funções do BigQuery adequadas.
• Permissões do Cloud Logging:a conta de serviço precisa de permissões para gravar registros no Cloud Logging e fazer depuração de maneira eficaz. Normalmente, o papel Logging Writer (roles/logging.logWriter) é suficiente.

Falhas comuns relacionadas a permissões ou acesso

• Função dataproc.worker ausente: sem essa função principal, a infraestrutura do Serverless para Apache Spark não pode provisionar e gerenciar corretamente o nó do driver.

• Permissões insuficientes do Cloud Storage: se o aplicativo Spark tentar ler dados de entrada ou gravar saída em um bucket do Cloud Storage sem as permissões necessárias da conta de serviço, o driver poderá não ser inicializado por falta de acesso a recursos críticos.

• Problemas de rede ou firewall: o VPC Service Controls ou as regras de firewall podem bloquear inadvertidamente o acesso da conta de serviço a APIs ou recursos do Google Cloud .

Para verificar e atualizar as permissões da conta de serviço:

1. Acesse a página IAM e administrador > IAM no console do Google Cloud .
2. Localize a conta de serviço usada para suas cargas de trabalho ou sessões em lote do Serverless para Apache Spark.
3. Verifique se os papéis necessários estão atribuídos. Se não estiverem, adicione.

Para uma lista de papéis e permissões do Serverless para Apache Spark, consulte Permissões e papéis do IAM do Serverless para Apache Spark.

Ver e gerenciar papéis da conta de serviço do IAM

Para conferir e gerenciar os papéis concedidos à conta de serviço da carga de trabalho em lote ou da sessão do Serverless para Apache Spark, faça o seguinte:

1. No console Google Cloud , acesse a página IAM.

   Acessar IAM

2. Clique em Incluir concessões de papel fornecidas pelo Google.

3. Confira os papéis listados para a conta de serviço da sessão ou da carga de trabalho em lote. A imagem a seguir mostra o papel Worker do Dataproc necessário listado para a conta de serviço padrão do Compute Engine, project_number-compute@developer.gserviceaccount.com, que o Serverless para Apache Spark usa por padrão como a conta de serviço de carga de trabalho ou sessão.

   

4. Clique no ícone de lápis exibido na linha da conta de serviço para conceder ou remover papéis da conta de serviço.

Conta de serviço entre projetos

É possível enviar uma carga de trabalho em lote do Serverless para Apache Spark que usa uma conta de serviço de um projeto diferente do projeto da carga de trabalho em lote (o projeto em que o lote é enviado). Nesta seção, o projeto em que a conta de serviço está localizada é chamado de service account project, e o projeto em que o lote é enviado é chamado de batch project.

Por que usar uma conta de serviço entre projetos para executar uma carga de trabalho em lote? Um motivo possível é se a conta de serviço no outro projeto tiver recebido papéis do IAM que fornecem acesso refinado aos recursos desse projeto.

Etapas da configuração

1. No projeto da conta de serviço:

   1. Ativar contas de serviço para serem anexadas a projetos.

   2. Enable the Dataproc API.

      Enable the API

   3. Conceda à sua conta de e-mail (o usuário que está criando o cluster) o papel de Usuário da conta de serviço no projeto da conta de serviço ou, para um controle mais granular, na conta de serviço do projeto da conta de serviço.

      Para mais informações, consulte Gerenciar o acesso a projetos, pastas e organizações para conceder papéis no nível do projeto e Gerenciar o acesso a contas de serviço para conceder papéis no nível da conta de serviço.

      Exemplos da CLI gcloud:

      O exemplo de comando a seguir concede ao usuário o papel de Usuário da conta de serviço no nível do projeto:

      gcloud projects add-iam-policy-binding SERVICE_ACCOUNT_PROJECT_ID \
          --member=USER_EMAIL \
          --role="roles/iam.serviceAccountUser"
      

      Observações:

      • USER_EMAIL: informe o endereço de e-mail da sua conta de usuário no formato user:user-name@example.com.

      O exemplo de comando a seguir concede ao usuário o papel de usuário da conta de serviço no nível da conta de serviço:

      gcloud iam service-accounts add-iam-policy-binding VM_SERVICE_ACCOUNT_EMAIL \
          --member=USER_EMAIL \
          --role="roles/iam.serviceAccountUser"
      

      Observações:

      • USER_EMAIL: informe o endereço de e-mail da sua conta de usuário no formato: user:user-name@example.com.

   4. Conceda à conta de serviço o papel Worker do Dataproc no projeto em lote.

      Exemplo da CLI gcloud:

      gcloud projects add-iam-policy-binding BATCH_PROJECT_ID \
          --member=serviceAccount:SERVICE_ACCOUNT_NAME@SERVICE_ACCOUNT_PROJECT_ID.iam.gserviceaccount.com \
          --role="roles/dataproc.worker"
      

2. No projeto em lote:

   1. Conceda à conta de serviço do agente de serviço do Dataproc os papéis de Usuário da conta de serviço e Criador de token da conta de serviço no projeto da conta de serviço ou, para um controle mais granular, na conta de serviço no projeto da conta de serviço. Ao fazer isso, você permite que a conta de serviço do agente de serviço do Dataproc no projeto em lote crie tokens para a conta de serviço no projeto da conta de serviço.

      Para mais informações, consulte Gerenciar o acesso a projetos, pastas e organizações para conceder papéis no nível do projeto e Gerenciar o acesso a contas de serviço para conceder papéis no nível da conta de serviço.

      Exemplos da CLI gcloud:

      Os comandos a seguir concedem à conta de serviço do agente de serviço do Dataproc no projeto em lote os papéis de usuário da conta de serviço e criador de token da conta de serviço no nível do projeto:

      gcloud projects add-iam-policy-binding SERVICE_ACCOUNT_PROJECT_ID \
          --member=serviceAccount:service-BATCH_PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com \
          --role="roles/iam.serviceAccountUser"
      

      gcloud projects add-iam-policy-binding SERVICE_ACCOUNT_PROJECT_ID \
          --member=serviceAccount:service-BATCH_PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com \
          --role="roles/iam.serviceAccountTokenCreator"
      

      Os comandos de exemplo a seguir concedem à conta de serviço do agente de serviço do Dataproc no projeto em lote os papéis de usuário da conta de serviço e criador de token da conta de serviço no nível da conta de serviço:

      gcloud iam service-accounts add-iam-policy-binding VM_SERVICE_ACCOUNT_EMAIL \
          --member=serviceAccount:service-BATCH_PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com \
          --role="roles/iam.serviceAccountUser"
      

      gcloud iam service-accounts add-iam-policy-binding VM_SERVICE_ACCOUNT_EMAIL \
          --member=serviceAccount:service-BATCH_PROJECT_NUMBER@dataproc-accounts.iam.gserviceaccount.com \
          --role="roles/iam.serviceAccountTokenCreator"
      

   2. Conceda à conta de serviço do agente de serviço do Compute Engine no projeto em lote o papel Criador de token da conta de serviço no projeto da conta de serviço ou, para um controle mais granular, na conta de serviço no projeto da conta de serviço. Ao fazer isso, você concede à conta de serviço do agente de serviço do Compute no projeto em lote a capacidade de criar tokens para a conta de serviço no projeto da conta de serviço.

      Para mais informações, consulte Gerenciar o acesso a projetos, pastas e organizações para conceder papéis no nível do projeto e Gerenciar o acesso a contas de serviço para conceder papéis no nível da conta de serviço.

      Exemplos da CLI gcloud:

      O exemplo de comando a seguir concede à conta de serviço do agente de serviço do Compute Engine no projeto em lote o papel de criador de token da conta de serviço no nível do projeto:

      gcloud projects add-iam-policy-binding SERVICE_ACCOUNT_PROJECT_ID \
          --member=serviceAccount:service-BATCH_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com \
          --role="roles/iam.serviceAccountTokenCreator"
      

      O exemplo de comando a seguir concede à conta de serviço do agente de serviço do Compute Engine no projeto do cluster o papel de criador de token da conta de serviço no nível da conta de serviço:

      gcloud iam service-accounts add-iam-policy-binding VM_SERVICE_ACCOUNT_EMAIL \
          --member=serviceAccount:service-BATCH_PROJECT_NUMBER@compute-system.iam.gserviceaccount.com \
          --role="roles/iam.serviceAccountTokenCreator"
      

Enviar a carga de trabalho em lote

Depois de concluir as etapas de configuração, é possível enviar uma carga de trabalho em lote. Especifique a conta de serviço no projeto dela como a conta de serviço a ser usada para a carga de trabalho em lote.