Usar a autenticação com destinos HTTP

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

Configurar uma conta de serviço

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

Os aplicativos podem usar contas de serviço para fazer chamadas de API autorizadas, autenticando-se como a própria conta de serviço e acessando todos os recursos que ela 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, conceda os papéis do Identity and Access Management (IAM) à conta de serviço para permitir que ela acesse os recursos do 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.). 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 no Google Cloud, conceda os papéis do IAM necessários à sua conta de serviço. Cada serviço no Google Cloud requer um papel específico, e o serviço de recebimento verifica automaticamente o token gerado.

    Por exemplo, para o Cloud Run e o Cloud Run functions, é necessário conceder o papel de Invocador do Cloud Run (roles/run.invoker). Já para o Cloud 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, essa permissão é concedida automaticamente.

    Na etapa anterior, se você criou especificamente uma conta de serviço 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 console do Google Cloud , na página do seletor de projetos, selecione um projeto doGoogle Cloud .

      Acessar o seletor de projetos

    2. Acesse 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 necessárias ao principal.

    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 destino. Por exemplo, run services para um destino de serviço do Cloud Run.
    • RESOURCE_ID: o identificador do destino. Por exemplo, o nome de um serviço do Cloud Run.
    • PRINCIPAL: o identificador da conta de serviço. O formato é o seguinte: serviceAccount:SERVICE_ACCOUNT_EMAIL_ADDRESS. Por exemplo, serviceAccount:my-service-account@my-project..
    • ROLE: o nome do papel que o serviço de destino requer para invocação. Por exemplo, roles/run.invoker para um destino de serviço do Cloud Run. Para destinos de funções do Cloud Run, recomendamos usar o comando add-invoker-policy-binding.

    Exemplos:

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

      gcloud run services add-iam-policy-binding my-service \
          --region=REGION \
          --member=serviceAccount:my-service-account@my-project. \
          --role=roles/run.invoker
      
    • Use o comando gcloud functions add-invoker-policy-binding para conceder o papel apropriado à conta de serviço my-service-account@my-project. na função do Cloud Run my-cloud-function.

      Para as funções do Cloud Run, 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 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 \
          --region=REGION \
          --member=serviceAccount:my-service-account@my-project.
      

    Para ver 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 Como 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 o token manualmente.

  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 é para que ele possa gerar tokens de cabeçalho em nome da sua conta de serviço para autenticar no destino.

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

Para autenticar 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, usando HTTPS, para o destino. É possível usar um token de ID (OIDC) ou um token OAuth (de acesso). O OIDC geralmente é usado, exceto para APIs do Google hospedadas em *.googleapis.com: essas APIs esperam um token OAuth, e o Cloud Scheduler aceita tokens OAuth apenas para URLs de destino hospedados em *.googleapis.com.

Para criar um job do Cloud Scheduler que use 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 console do Google Cloud , acesse a página do Cloud Scheduler.

    Acessar o Cloud Scheduler

  2. Clique em Criar job.

  3. No campo Nome, insira um nome para o job que seja exclusivo para o projeto e a região. Depois de excluir o job associado, é possível reutilizar o nome dele.

  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 string fornecida aqui pode ser qualquer string compatível com o unix-cron.

  6. Clique em Continuar.

  7. Na lista Tipo de destino, selecione HTTP.

  8. Especifique um URL que comece com https:// 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, já que essas APIs esperam um token OAuth.

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

  11. Se quiser, especifique um Público-alvo que limite os destinatários do token OIDC. Normalmente, o URL de destino do job sem parâmetros de URL. Se não for especificado, todo o URL 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 \
    --location=LOCATION \
    --schedule="FREQUENCY" \
    --uri=URI \
    --oidc-service-account-email=SERVICE_ACCOUNT_EMAIL

Substitua:

  • JOB_ID: um nome para o job que é exclusivo do projeto e da região. Depois de excluir o job associado, é possível reutilizar o nome dele.
  • LOCATION: o local (região) do job.
  • FREQUENCY: o intervalo ou a frequência com que o job será executado, por exemplo, every 3 hours ou every 10 mins. A string fornecida aqui pode ser qualquer string compatível com o unix-cron.
  • URI: o URL HTTPS totalmente qualificado do endpoint (precisa começar com https://).
  • SERVICE_ACCOUNT_EMAIL: o e-mail da conta de serviço. Um token OIDC geralmente é usado, exceto para APIs do Google hospedadas em *.googleapis.com, porque essas APIs esperam 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 gcloud.

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

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

O agente de serviço do Cloud Scheduler requer o papel Agente de serviço do Cloud Scheduler (roles/cloudscheduler.serviceAgent). Sem esse papel, os jobs do Cloud Scheduler que exigem o agente de serviço (como jobs de destino HTTP que usam autenticação e jobs de destino do Pub/Sub) falham. É possível conceder manualmente o papel ao agente de serviço do Cloud Scheduler, que tem um endereço de e-mail com o seguinte formato:

service-PROJECT_NUMBER@gcp-sa-cloudscheduler.

Você precisa conceder o papel manualmente apenas 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

Para verificar se o agente de serviço do Cloud Scheduler está configurado no projeto e se ele tem o papel de agente de serviço do Cloud Scheduler concedido, confira o acesso atual do projeto. Se você usar o console do Google Cloud para ver o acesso do projeto, marque a caixa de seleção Incluir concessões de papéis fornecidos 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.