舉例來說，如要將接收端 Cloud Run 函式設定為接受來自特定呼叫函式或服務的要求，您必須將呼叫端的服務帳戶新增為接收端函式的主體，並授予該主體 Cloud Run 函式 Invoker (roles/cloudfunctions.invoker) 角色。同樣地，如要為 Cloud Run 設定服務帳戶，請將 Cloud Run Invoker (roles/run.invoker) 角色授予該服務帳戶。詳情請參閱「使用 IAM 控管存取權」或「Cloud Run 驗證總覽」。
叫用 Cloud Run 函式
在 Cloud Run 函式中，您可以管理基礎 Cloud Run 服務，取得叫用權限。如果工作流程要叫用 Cloud Run 函式服務，您不需要將 Cloud Functions 叫用者 (roles/cloudfunctions.invoker) 角色授予呼叫端的服務帳戶。您必須改為授予 Cloud Run 叫用者 (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"]],["上次更新時間：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)"]]
