例如,如需将接收 Cloud Run 函数配置为接受来自特定调用函数或服务的请求,您需要将调用者的服务账号添加为接收函数的主账号,并向该主账号授予 Cloud Run 函数 Invoker (roles/cloudfunctions.invoker) 角色。同样,如需为 Cloud Run 设置服务账号,请向该服务账号授予 Cloud Run Invoker (roles/run.invoker) 角色。如需了解详情,请参阅使用 IAM 进行访问权限控制或 Cloud Run 身份验证概览。
调用 Cloud Run functions
在 Cloud Run 函数中,您可以通过管理底层 Cloud Run 服务来获取调用权限。如果您的工作流正在调用 Cloud Run 函数服务,则无需向调用方的服务账号授予 Cloud Functions Invoker (roles/cloudfunctions.invoker) 角色。您必须授予 Cloud Run Invoker (roles/run.invoker) 角色。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-09-04。"],[],[],null,["# Invoke Cloud Run functions or Cloud Run\n\nCalling or invoking a Google Cloud service such as Cloud Run functions\nor Cloud Run from Workflows is done through an HTTP\nrequest. The most common HTTP request methods have a call shortcut (such as\n[http.get](/workflows/docs/reference/stdlib/http/get)\nand [http.post](/workflows/docs/reference/stdlib/http/post)), but you can make\nany type of HTTP request by setting the `call` field to `http.request` and\nspecifying the type of request using the `method` field. For\nmore information, see [Make an HTTP request](/workflows/docs/http-requests).\n| **Note:** Invoking a Google Cloud service through an HTTP request should not be confused with using Workflows [connectors](/workflows/docs/connectors) to perform API operations with other Google Cloud products.\n\n#### To send authenticated requests:\n\n- Your workflow must be associated with a service account that has been granted\n one or more Identity and Access Management (IAM) roles containing the required\n permissions.\n\n- You must explicitly add authentication information to your workflow\n definition. By default, HTTP requests do not contain identity or access tokens\n for security reasons.\n\nFor more information, see\n[Grant a workflow permission to access Google Cloud resources](/workflows/docs/authentication).\n\nWhen to call a service\n----------------------\n\n\nHow do you know when to create steps in YAML or JSON using the Workflows\nsyntax or when to create a service---for example, a Cloud Run service\nor a Cloud Run function---to do the work instead?\n\nCreate services to do any work that is too complex for Workflows;\nfor example, implementing reusable business logic, complex computations, or\ntransformations that are not supported by Workflows expressions and its\nstandard library. A complicated case is typically easier to implement in code,\ninstead of using YAML or JSON and the Workflows syntax.\n\nInvoke services that are restricted to internal ingress\n-------------------------------------------------------\n\nWorkflows can invoke Cloud Run functions\nor Cloud Run services in the same Google Cloud project\nthat have ingress restricted to internal traffic. With this configuration, your\nservices are unreachable from the internet but can be reached from\nWorkflows.\n\nTo apply these restrictions, you must adjust the ingress settings of your\nservice or function. Note that the Cloud Run service must be\nreached on its `run.app` URL and not at a custom domain. For more information,\nsee [Restrict network ingress](/run/docs/securing/ingress) (for Cloud Run)\nand [Configure network settings](/functions/docs/networking/network-settings)\n(for Cloud Run functions). No other changes are needed to your\nworkflow.\n\nUse a service account with the required permissions\n---------------------------------------------------\n\nWhen making requests to other Google Cloud services, your workflow must\nbe associated with a service account that has the correct permissions to access\nthe requested resources. To learn what service account is associated with an\nexisting workflow, see [Verify a workflow's associated service account](/workflows/docs/authentication#verify-service-account).\n\nWhen setting up a service account, you associate the requesting identity with the\nresource you wish to give it access to---you make the requesting identity a\n**principal** of the resource---and then assign it the appropriate [role](/iam/docs/understanding-roles).\nThe role defines what permissions the identity has in the context of the resource.\n\nFor example, to configure a receiving Cloud Run function to\naccept requests from a specific calling function or service, you need to add the\ncaller's service account as a principal on the receiving function and grant that\nprincipal the Cloud Run functions Invoker (`roles/cloudfunctions.invoker`)\nrole. Similarly, to set up a service account for Cloud Run, you\ngrant that service account the Cloud Run Invoker\n(`roles/run.invoker`) role. To learn more, see\n[Access control with IAM](/run/docs/securing/managing-access)\nor the [Cloud Run authentication overview](/run/docs/authenticating/overview).\n\n### Invoke Cloud Run functions\n\nIn Cloud Run functions, invocation permissions are available by\nmanaging the underlying Cloud Run service. If your workflow is invoking\na Cloud Run functions service, you don't need to grant the caller's\nservice account the Cloud Functions Invoker\n(`roles/cloudfunctions.invoker`) role. Instead, you must grant the\nCloud Run Invoker (`roles/run.invoker`) role.\n\nFor more information, see\n[Compare Cloud Run functions](/run/docs/functions/comparison).\n\nAdd authentication information to your workflow\n-----------------------------------------------\n\n| **Note:** This authentication method is restricted to HTTPS endpoints.\n\nWhen making requests to Cloud Run functions or Cloud Run,\nuse OIDC to authenticate.\n\nTo make an HTTP request using OIDC, add an `auth` section to the `args` section\nof your workflow's definition, after you specify the URL. In this example, a\nrequest is sent to invoke a Cloud Run function:\n\n\u003cbr /\u003e\n\n### YAML\n\n```yaml\n - step_A:\n call: http.get\n args:\n url: https://us-central1-project.cloudfunctions.net/functionA\n query:\n firstNumber: 4\n secondNumber: 6\n operation: sum\n auth:\n type: OIDC\n audience: OIDC_AUDIENCE\n \n```\n\n### JSON\n\n```json\n [\n {\n \"step_A\": {\n \"call\": \"http.get\",\n \"args\": {\n \"url\": \"https://us-central1-project.cloudfunctions.net/functionA\",\n \"query\": {\n \"firstNumber\": 4,\n \"secondNumber\": 6,\n \"operation\": \"sum\"\n },\n \"auth\": {\n \"type\": \"OIDC\",\n \"audience\": \"\u003cvar translate=\"no\"\u003eOIDC_AUDIENCE\u003c/var\u003e\"\n }\n }\n }\n }\n ]\n \n```\nThe `audience` parameter can be used to specify the OIDC audience for the token. By default, it's set to the same value as `url`; however, it should be set to your service's root URL. For example: `https://region-project.cloudfunctions.net/hello_world`.\n\n\u003cbr /\u003e\n\nSpecify the media type for the response data\n--------------------------------------------\n\nIf the `Content-Type` header for the response specifies an\n`application/json` media type, the JSON response that is stored in a\nvariable is automatically converted to a map that can be accessed.\n\nIf necessary, modify the API that is being called to specify an\n`application/json` media type for the `Content-Type`\nresponse header. Otherwise, you can use the\n[`json.decode`](/workflows/docs/reference/stdlib/json/decode)\nand [`text.encode`](/workflows/docs/reference/stdlib/text/encode) functions to\nconvert the response body into a map. For example: \n\n json.decode(text.encode(\u003cvar translate=\"no\"\u003eRESPONSE_FROM_API\u003c/var\u003e))\n\nFor more information, see\n[Access HTTP response data saved in a variable](/workflows/docs/http-requests#access-data).\n\nExecute Cloud Run jobs\n----------------------\n\nUnlike Cloud Run services,\n[Cloud Run jobs](/run/docs/create-jobs) do not listen for or\nserve HTTP requests. To execute Cloud Run jobs from a workflow,\nuse the\n[Cloud Run Admin API connector](/workflows/docs/reference/googleapis/run/Overview).\n\nFor an end-to-end example of executing a Cloud Run job that\nprocesses data passed as environment variables to the job, see\n[Execute a Cloud Run job using Workflows](/workflows/docs/tutorials/execute-cloud-run-jobs).\n\nFor an end-to-end example of executing a Cloud Run job that\nprocesses data stored in a Cloud Storage bucket allowing you to\nencrypt the data using customer-managed encryption keys (CMEK), see\n[Execute a Cloud Run job that processes event data in Cloud Storage](/workflows/docs/tutorials/execute-cloud-run-jobs-stored-events).\n\nWhat's next\n-----------\n\n- [Invoke with an HTTPS Request](/run/docs/triggering/https-request)\n- [Use Workflows with Cloud Run and Cloud Run functions tutorial](/workflows/docs/tutorials/run/cloud-run)"]]