Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Autentica para la invocación
En este documento, se proporciona información complementaria sobre cómo invocar funciones creadas con la API de Cloud Functions v2, por ejemplo, con gcloud functions, la API de REST o Terraform. Para obtener información detallada y
ejemplos, consulta las guías de
Autenticación de solicitudes de Cloud Run. Los temas que se tratan en las guías de Cloud Run también se aplican a las funciones creadas con la API de Cloud Functions v2, ya que las funciones de v2 también usan el rol de invocador de Cloud Run (roles/run.invoker).
Para invocar una función autenticada, el
principal subyacente debe cumplir con los siguientes requisitos:
Tener permiso para invocar la función
Proporcionar un token de ID cuando invoque la función
Las funciones de Cloud Run admiten dos tipos diferentes de identidades, que también se llaman principales:
Cuentas de servicio: Estas son cuentas especiales que actúan como la identidad de una entidad
que no es una persona, como una función, una aplicación o una VM. Te brindan una forma
de autenticar a las entidades que no son personas.
Cuentas de usuario: Estas cuentas representan personas, ya sea como titulares
de cuentas de Google individuales o como parte de una entidad controlada por Google, como un Grupo
de Google.
Para invocar una función autenticada, el principal debe tener el permiso de IAM de invocador:
run.routes.invoke. Por lo general, esto se hace a través del rol de invocador de Cloud Run Invoker. Este
permiso se debe asignar en el recurso de servicio de Cloud Run.
Si quieres obtener permiso para crear, actualizar o realizar otras acciones administrativas en una función,
la principal debe tener una función adecuada. Los roles incluyen permisos que definen las acciones que la principal puede realizar. Para obtener más información, consulta
Usa IAM para autorizar el acceso.
Solo la fuente del evento a la que están suscritas las funciones controladas por eventos puede invocarlas. Sin embargo, las funciones de HTTP pueden ser invocadas por diferentes tipos de identidad que se originan en diferentes lugares, como un desarrollador que prueba la función o otro servicio que la usa. Las identidades deben proporcionar un token de ID para la autenticación. La cuenta en uso también debe tener los permisos adecuados.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
