Usar a autenticação com destinos HTTP

O Cloud Scheduler poderá chamar destinos HTTP que exigem autenticação se você tiver configurado uma conta de serviço associada que tenha as credenciais apropriadas.

Configurar uma conta de serviço

Uma conta de serviço geralmente é usada por um aplicativo ou carga de trabalho de computação e é identificada pelo endereço de e-mail dela, que é exclusivo.

Os aplicativos podem usar contas de serviço para fazer chamadas de API autorizadas, autenticando como a própria conta de serviço e acessando todos os recursos que a conta de serviço tem permissão para acessar.

A maneira mais comum de permitir que um aplicativo seja autenticado como uma conta de serviço é anexando uma conta de serviço ao recurso que está executando o aplicativo. Em seguida, é possível conceder papéis do Identity and Access Management (IAM) à conta de serviço para permitir que ela acesse recursos. Google Cloud

1. Se você ainda não tiver uma conta de serviço que queira usar para jobs do Cloud Scheduler com destinos HTTP, crie uma nova conta de serviço. Observe o seguinte:

   • A conta de serviço precisa pertencer ao projeto em que o job do Cloud Scheduler é criado.

   • Não use o agente de serviço do Cloud Scheduler (service-PROJECT_NUMBER@gcp-sa-cloudscheduler.iam.gserviceaccount.com). Ele não pode ser usado para essa finalidade.

   • Não revogue o papel de agente de serviço do Cloud Scheduler (roles/cloudscheduler.serviceAgent) do agente de serviço do Cloud Scheduler no seu projeto. Isso resulta em respostas 403 para endpoints que exigem autenticação, mesmo que a conta de serviço do job tenha o papel apropriado.

2. Se o destino estiver dentro do Google Cloud, conceda os papéis do IAM necessários à sua conta de serviço. Cada serviço dentro do Google Cloud exige um papel específico, e o serviço de recebimento verifica automaticamente o token gerado.

   Por exemplo, para o Cloud Run e a versão mais recente do Cloud Run functions, é necessário conceder o papel de invocador do Cloud Run (roles/run.invoker), enquanto para o Cloud Run functions (1ª geração), é necessário conceder o papel de invocador do Cloud Functions (roles/cloudfunctions.invoker).

   Para receber a permissão necessária para anexar uma conta de serviço a um recurso, peça ao administrador que conceda a você o papel do IAM de usuário da conta de serviço (roles/iam.serviceAccountUser) na conta de serviço. Esse papel predefinido contém a permissão iam.serviceAccounts.actAs, que é necessária para anexar uma conta de serviço a um recurso. Se você criou a conta de serviço, recebe automaticamente essa permissão.

   Na etapa anterior, se você criou uma conta de serviço especificamente para invocar o serviço que o job do Cloud Scheduler segmenta, siga o princípio de privilégio mínimo vinculando a conta e a permissão de invocador ao serviço de destino:

   Console

   1. No Google Cloud console do, na página do seletor de projetos, escolha um Google Cloud projeto do.

      Acessar o seletor de projetos

   2. Navegue até a página do tipo de recurso que você está invocando. Por exemplo, se você estiver invocando um serviço do Cloud Run, navegue até a página que lista os serviços do Cloud Run.

   3. Marque a caixa de seleção à esquerda do serviço que você quer invocar. (Não clique no próprio serviço.)

   4. Clique na guia person Permissões.

      Se o painel de informações não estiver visível, clique em Mostrar painel de informações > Permissões.

   5. Clique em person_add Adicionar principal.

   6. No campo Novos principais, insira o endereço de e-mail da conta de serviço que você criou.

   7. Na lista Selecionar um papel, escolha um papel para conceder.

      Siga o princípio de privilégio mínimo escolhendo o papel que inclui apenas as permissões de que seu principal precisa.

   8. Clique em Salvar.

   gcloud

   gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
       --member=PRINCIPAL \
       --role=ROLE
   

   Substitua:

   • RESOURCE_TYPE: o tipo de recurso do seu destino. Por exemplo, run services para um destino de serviço do Cloud Run.
   • RESOURCE_ID: o identificador do seu destino. Por exemplo, o nome de um serviço do Cloud Run.
   • PRINCIPAL: o identificador da sua conta de serviço. Ele tem o seguinte formato: serviceAccount:SERVICE_ACCOUNT_EMAIL_ADDRESS. Por exemplo, serviceAccount:my-service-account@my-project.iam.gserviceaccount.com.
   • ROLE: o nome do papel que o serviço de destino exige para invocação. Por exemplo, roles/run.invoker para um destino de serviço do Cloud Run. Para destinos do Cloud Run functions, recomendamos usar o comando add-invoker-policy-binding.

   Exemplos:

   • Use o gcloud run services add-iam-policy-binding comando para conceder o papel do IAM de invocador do Cloud Run (roles/run.invoker) à conta de serviço my-service-account@my-project.iam.gserviceaccount.com no serviço do Cloud Run my-service:

     gcloud run services add-iam-policy-binding my-service \
         --member=serviceAccount:my-service-account@my-project.iam.gserviceaccount.com \
         --role=roles/run.invoker
     

   • Use o gcloud functions add-invoker-policy-binding comando para conceder o papel apropriado à conta de serviço my-service-account@my-project.iam.gserviceaccount.com na função do Cloud Run my-cloud-function.

     Para a versão mais recente do Cloud Run functions, isso adiciona a vinculação do invocador do Cloud Run (roles/run.invoker) à política do IAM do serviço do Cloud Run subjacente da função especificada. Para o Cloud Run functions (1ª geração), isso adiciona a vinculação do invocador do Cloud Functions (roles/cloudfunctions.invoker) à política do IAM da função especificada:

     gcloud functions add-invoker-policy-binding my-cloud-function \
         --member=serviceAccount:my-service-account@my-project.iam.gserviceaccount.com
     

   Para um exemplo de como usar o Terraform para criar uma conta de serviço com permissão para invocar um serviço do Cloud Run, consulte Criar uma conta de serviço para o Cloud Scheduler.

3. Se o destino estiver fora do Google Cloud, o serviço de recebimento precisará verificar manualmente o token.

4. O agente de serviço padrão do Cloud Scheduler é configurado automaticamente quando você ativa a API Cloud Scheduler, a menos que você a tenha ativado antes de 19 de março de 2019. Nesse caso, é necessário conceder o papel de agente de serviço do Cloud Scheduler. Isso é necessário para que ele possa gerar tokens de cabeçalho em nome da conta de serviço e criar uma autenticação no destino.

Criar um job do Cloud Scheduler que usa autenticação

Para realizar a autenticação entre o Cloud Scheduler e um destino HTTP, o Cloud Scheduler cria um token de cabeçalho com base na conta de serviço do cliente identificada pelo e-mail e o envia até o destino por meio do HTTPS. É possível usar um token de ID (OIDC) ou um token OAuth (acesso). O OIDC geralmente é usado exceto para APIs do Google hospedadas em *.googleapis.com, porque essas APIs usam um token OAuth.

Para criar um job do Cloud Scheduler que usa autenticação, adicione o tipo de token e o endereço de e-mail que identifica a conta de serviço do cliente ao criar o job:

gcloud scheduler jobs create