Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Autenticar para invocação
Este documento fornece informações complementares sobre como invocar funções
criadas usando a
API Cloud Functions v2, por exemplo, usando
gcloud functions, a API REST ou o Terraform. Para informações detalhadas e
exemplos, consulte os guias de
Autenticar solicitações do Cloud Run. Os tópicos
abordados nos guias do Cloud Run também se aplicam a funções criadas usando a
API Cloud Functions v2, já que as funções v2 também
usam o
papel Invocador do Cloud Run
(roles/run.invoker).
Para invocar uma função autenticada, o principal
subjacente precisa atender aos seguintes requisitos:
Ter permissão para invocar a função.
Fornecer um token de ID ao invocar a função.
O Cloud Run functions é compatível com dois tipos diferentes de identidades, que também são chamadas de
principais:
Contas de serviço: são contas especiais que servem como a identidade de um
usuário que não é uma pessoa, como uma função, um aplicativo ou uma VM. É uma maneira de autenticar
esses usuários que não são pessoas.
Contas de usuário: representam pessoas, sejam proprietários de contas individuais
do Google ou como parte de uma entidade controlada pelo Google, como um Grupo do
Google.
Consulte a Visão geral do IAM para saber mais sobre
os conceitos básicos do IAM.
Para invocar uma função autenticada, o principal precisa ter a permissão
do IAM do invocador:
run.routes.invoke. Isso geralmente ocorre usando o
papel de Invocador do Cloud Run. Essa
permissão precisa ser atribuída no recurso do serviço do Cloud Run.
Para ter permissão a fim de criar, atualizar ou executar outras ações administrativas em uma
função, o principal precisa ter um papel adequado. Os papéis incluem permissões que definem as ações possíveis para o principal. Para mais informações,
consulte Como usar o IAM para autorizar
o acesso.
As funções orientadas por eventos só podem ser invocadas pela origem do evento em que estão
inscritas. No entanto, as funções HTTP podem ser invocadas por diferentes tipos de identidade
originários de lugares diferentes, como por um desenvolvedor que testa a
função ou por outro serviço que a usa. As identidades precisam fornecer um token de ID
para autenticação. A conta em uso também precisa ter as permissões
adequadas.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-03 UTC."],[[["\u003cp\u003eTo invoke an authenticated Cloud Run function, the principal must have the \u003ccode\u003erun.routes.invoke\u003c/code\u003e permission, typically through the Cloud Run Invoker role, and provide an ID token.\u003c/p\u003e\n"],["\u003cp\u003ePrincipals can be service accounts (for non-persons like functions or applications) or user accounts (for individual Google Account holders or groups), both requiring appropriate permissions to invoke functions.\u003c/p\u003e\n"],["\u003cp\u003eDevelopers can test functions by assigning the Cloud Run Invoker role to their user account, using the Google Cloud CLI to generate ID tokens for requests, and allocating the minimum required permissions to operate.\u003c/p\u003e\n"],["\u003cp\u003eFor function-to-function calls, grant the calling function's service account the Cloud Run Invoker role on the receiving function's service, ensuring the calling function provides a Google-signed ID token.\u003c/p\u003e\n"],["\u003cp\u003eID tokens can be generated programmatically using authentication libraries or manually by using the Compute metadata server or exchanging a self-signed JWT for a Google-signed ID token, with the latter two methods being more complex.\u003c/p\u003e\n"]]],[],null,["# Authenticate for invocation\n===========================\n\nThis document provides supplemental information on how to invoke functions\ncreated using the\n[Cloud Functions v2 API](/functions/docs/apis)---for example, using\n`gcloud functions`, the REST API, or Terraform. For detailed information and\nexamples, see the Cloud Run\n[Authenticate requests](/run/docs/authenticating/overview) guides. The topics\ncovered in the Cloud Run guides also apply to functions created using the\n[Cloud Functions v2 API](/functions/docs/apis), since v2 functions also\nuse the\n[Cloud Run Invoker role](/run/docs/reference/iam/roles#run.invoker)\n(`roles/run.invoker`).\n\nTo invoke an authenticated function, the underlying\n**principal** must meet the following requirements:\n\n- Have permission to invoke the function.\n- Provide an ID token when it invokes the function.\n\nCloud Run functions supports two different kinds of identities, which are also\ncalled **principals**:\n\n- Service accounts: These are special accounts that serve as the identity of a non-person, like a function or an application or a VM. They give you a way to authenticate these non-persons.\n- User accounts: These accounts represent people, either as individual Google Account holders or as part of a Google-controlled entity like a Google Group.\n\nSee the [IAM overview](/iam/docs/overview) to learn more about\nbasic IAM concepts.\n\nTo invoke an authenticated function, the principal must have the invoker\nIAM **permission**:\n\n- `run.routes.invoke`. This is usually through the [Cloud Run Invoker role](/run/docs/reference/iam/roles#run.invoker). This permission must be assigned on the Cloud Run service resource.\n\nTo grant these permissions, follow the steps in the\nCloud Run\n[Authenticating service-to-service](/run/docs/authenticating/service-to-service#set-up-sa) guide.\n\nFor permission to create, update, or perform other administrative actions on a\nfunction, the principal must have an appropriate **role** . Roles include permissions that define the actions that the principal is allowed to do. See\n[Using IAM to Authorize Access](/functions/docs/securing/managing-access-iam)\nfor more information.\n\nEvent-driven functions can only be invoked by the event source that they're\nsubscribed to. HTTP functions, however, can be invoked by different identity\ntypes originating from different places, such as by a developer testing the\nfunction or by another service using the function. Identities must provide an ID\ntoken for authentication. The account in use must also have the appropriate\npermissions."]]
