Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Autenticazione per le chiamate
Questo documento fornisce informazioni supplementari su come richiamare le funzioni create utilizzando l'API Cloud Functions v2, ad esempio utilizzando gcloud functions, l'API REST o Terraform. Per informazioni dettagliate e esempi, consulta le guide sull'autenticazione delle richieste di Cloud Run. Gli argomenti trattati nelle guide di Cloud Run si applicano anche alle funzioni create utilizzando l'API Cloud Functions v2, poiché anche le funzioni v2 utilizzano il ruolo Invoker di Cloud Run (roles/run.invoker).
Per richiamare una funzione autenticata, il principale sottostante deve soddisfare i seguenti requisiti:
Avere l'autorizzazione per richiamare la funzione.
Fornisci un token di identità quando viene invocata la funzione.
Cloud Run Functions supporta due diversi tipi di identità, chiamate anche principali:
Account di servizio: si tratta di account speciali che fungono da identità di un soggetto non umano, come una funzione, un'applicazione o una VM. Ti offrono un modo per autenticare queste entità non umane.
Account utente: questi account rappresentano persone, come singoli detentori di Account Google o come parte di un'entità controllata da Google, come un gruppo Google.
Consulta la panoramica di IAM per saperne di più sui concetti di base di IAM.
Per richiamare una funzione autenticata, l'entità deve disporre dell'autorizzazione IAM invoker:
run.routes.invoke. In genere, tramite il
ruolo Invoker di Cloud Run. Questa permission deve essere assegnata alla risorsa del servizio Cloud Run.
Per avere l'autorizzazione a creare, aggiornare o eseguire altre azioni amministrative su una funzione, il principale deve disporre di un ruolo appropriato. I ruoli includono le autorizzazioni che definiscono le azioni consentite all'entità. Per ulteriori informazioni, consulta
Utilizzare IAM per autorizzare l'accesso.
Le funzioni basate su eventi possono essere richiamate solo dall'origine evento a cui sono sottoscritte. Le funzioni HTTP, invece, possono essere richiamate da diversi tipi di identità provenienti da luoghi diversi, ad esempio da uno sviluppatore che testa la funzione o da un altro servizio che la utilizza. Le identità devono fornire un token ID per l'autenticazione. L'account in uso deve inoltre disporre delle autorizzazioni appropriate.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 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."]]
