Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://cloud.google.com/functions/docs/securing/authenticating below:

Authenticate for invocation | Cloud Run functions Documentation

Stay organized with collections Save and categorize content based on your preferences.

This document provides supplemental information on how to invoke functions created using the Cloud Functions v2 API—for example, using gcloud functions, the REST API, or Terraform. For detailed information and examples, see the Cloud Run Authenticate requests guides. The topics covered in the Cloud Run guides also apply to functions created using the Cloud Functions v2 API, since v2 functions also use the Cloud Run Invoker role (roles/run.invoker).

To invoke an authenticated function, the underlying principal must meet the following requirements:

• Have permission to invoke the function.
• Provide an ID token when it invokes the function.

Cloud Run functions supports two different kinds of identities, which are also called principals:

• 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.
• User accounts: These accounts represent people, either as individual Google Account holders or as part of a Google-controlled entity like a Google Group.

See the IAM overview to learn more about basic IAM concepts.

To invoke an authenticated function, the principal must have the invoker IAM permission:

• run.routes.invoke. This is usually through the Cloud Run Invoker role. This permission must be assigned on the Cloud Run service resource.

To grant these permissions, follow the steps in the Cloud Run Authenticating service-to-service guide.

For permission to create, update, or perform other administrative actions on a function, the principal must have an appropriate role. Roles include permissions that define the actions that the principal is allowed to do. See Using IAM to Authorize Access for more information.

Event-driven functions can only be invoked by the event source that they're subscribed to. HTTP functions, however, can be invoked by different identity types originating from different places, such as by a developer testing the function or by another service using the function. Identities must provide an ID token for authentication. The account in use must also have the appropriate permissions.

Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-08-07 UTC.

[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["To invoke an authenticated Cloud Run function, the principal must have the `run.routes.invoke` permission, typically through the Cloud Run Invoker role, and provide an ID token."],["Principals 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."],["Developers 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."],["For 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."],["ID 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."]]],[]]

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4