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

Console

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

    Acessar o Cloud Scheduler

  2. Clique em Criar job.

  3. No campo Nome, insira um nome para o job que seja exclusivo do projeto. Observação: não é possível reutilizar o nome de um job em um projeto mesmo depois de excluir o job associado.

  4. Na lista Região, selecione uma região para o job.

  5. Especifique uma frequência e um fuso horário para o job. A cadeia que você fornece aqui pode ser qualquer unix-cron compatível cadeia.

  6. Clique em Continuar.

  7. Na lista Tipo de destino, selecione HTTP.

  8. Especifique um URL e um método HTTP.

  9. Na lista Cabeçalho de autenticação, selecione o tipo de token. Um token OIDC geralmente é usado exceto para APIs do Google hospedadas em *.googleapis.com, porque essas APIs usam um token OAuth.

  10. Na lista Conta de serviço, selecione o e-mail da conta de serviço.

  11. Opcionalmente, especifique um público-alvo que limita os destinatários do token OIDC. Normalmente, o URL de destino do job sem parâmetros de URL. Se não for especificado, o URL inteiro será usado como o público-alvo, incluindo os parâmetros de solicitação.

  12. Defina as configurações opcionais.

  13. Clique em Criar.

gcloud 

gcloud scheduler jobs create http JOB_ID \
    --schedule="FREQUENCY" \
    --uri=URI \
    --oidc-service-account-email=SERVICE_ACCOUNT_EMAIL

Substitua:

  • JOB_ID: um nome para o job que seja exclusivo do projeto. Observação: não é possível reutilizar o nome de um job em um projeto mesmo depois de excluir o job associado.
  • FREQUENCY: o intervalo ou a frequência com que o job será executado. Por exemplo, every 3 hours ou every 10 mins. A cadeia que você fornece aqui pode ser qualquer unix-cron compatível cadeia.
  • URI: o URL totalmente qualificado do endpoint.
  • SERVICE_ACCOUNT_EMAIL: o e-mail da sua conta de serviço. Um token OIDC geralmente é usado exceto para APIs do Google hospedadas em *.googleapis.com, porque essas APIs usam um token OAuth. Use a flag --oauth-service-account-email para definir um tipo de token OAuth.
  • Outros parâmetros opcionais são descritos na referência da linha de comando do gcloud.

Conceder o papel de agente de serviço do Cloud Scheduler

Alguns Google Cloud serviços precisam acessar seus recursos para serem capazes de atuar em seu nome. Para atender a essa necessidade, Google Cloud cria e gerencia contas de serviço conhecidas como agentes de serviço e que são criadas e recebem papéis automaticamente à medida que você ativa e usa Google Cloud serviços.

O agente de serviço do Cloud Scheduler requer o papel de agente de serviço do Cloud Scheduler (roles/cloudscheduler.serviceAgent). Sem esse papel, os jobs do Cloud Scheduler falham. É possível conceder manualmente o papel ao agente de serviço do Cloud Scheduler, que tem um endereço de e-mail no seguinte formato:

service-PROJECT_NUMBER@gcp-sa-cloudscheduler.iam.gserviceaccount.com

É necessário conceder o papel manualmente somente se uma das seguintes condições for verdadeira:

  • Você ativou a API Cloud Scheduler antes de 19 de março de 2019.
  • Você removeu o papel de agente de serviço do Cloud Scheduler do agente de serviço.

É possível verificar se o agente de serviço do Cloud Scheduler está configurado no seu projeto e se ele tem o papel de agente de serviço do Cloud Scheduler concedido a ele, visualizando o acesso atual do projeto. Se você usar o Google Cloud console para visualizar o acesso do projeto, marque a caixa de seleção Incluir concessões de papel fornecidas pelo Google.

Para saber como conceder um papel ao agente de serviço, consulte Criar e conceder papéis a agentes de serviço.

A seguir

Saiba como se autenticar no Cloud Scheduler de maneira programática.