Invoke Cloud Functions or Cloud Run

Calling or invoking a Google Cloud service such as Cloud Functions or Cloud Run from Workflows is done through an HTTP request. The most common HTTP request methods have a call shortcut (such as http.get and http.post), but you can make any type of HTTP request by setting the call field to http.request and specifying the type of request using the method field. For more information, see Make an HTTP request.

To send authenticated requests:

• Your workflow must be associated with a service account that has been granted one or more Identity and Access Management (IAM) roles containing the required permissions.

• You must explicitly add authentication information to your workflow definition. By default, HTTP requests do not contain identity or access tokens for security reasons.

For more information, see Workflows authentication.

Invoke services that are restricted to internal ingress

Workflows can invoke Cloud Functions or Cloud Run services in the same Google Cloud project that have ingress restricted to internal traffic. With this configuration, your services are unreachable from the internet but can be reached from Workflows.

To apply these restrictions, you must adjust the ingress settings of your service or function. Note that the Cloud Run service must be reached on its run.app URL and not at a custom domain. For more information, see Restricting ingress (for Cloud Run) and Configuring network settings (for Cloud Functions). No other changes are needed to your workflow.

Use a service account with the required permissions

When making requests to other Google Cloud services, your workflow must be associated with a service account that has the correct permissions to access the requested resources. To learn what service account is associated with an existing workflow, see Verify a workflow's associated service account.

When setting up a service account, you associate the requesting identity with the resource you wish to give it access to—you make the requesting identity a principal of the resource—and then assign it the appropriate role. The role defines what permissions the identity has in the context of the resource.

For example, to configure a receiving Cloud Function to accept requests from a specific calling function or service, you need to add the caller's service account as a principal on the receiving function and grant that principal the Cloud Functions Invoker (roles/cloudfunctions.invoker) role. Similarly, to set up a service account for Cloud Run, you grant that service account the Cloud Run Invoker (roles/run.invoker) role. To learn more, see the authentication information for Cloud Functions or the Cloud Run authentication overview.

Add authentication information to your workflow

When making requests to Cloud Functions or Cloud Run, use OIDC to authenticate.

To make an HTTP request using OIDC, add an auth section to the args section of your workflow's definition, after you specify the URL. In this example, a request is sent to invoke a Cloud Function:

  - step_A:
      call: http.get
      args:
          url: https://us-central1-project.cloudfunctions.net/functionA
          query:
              firstNumber: 4
              secondNumber: 6
              operation: sum
          auth:
              type: OIDC
              audience: OIDC_AUDIENCE
    

    [
      {
        "step_A": {
          "call": "http.get",
          "args": {
            "url": "https://us-central1-project.cloudfunctions.net/functionA",
            "query": {
              "firstNumber": 4,
              "secondNumber": 6,
              "operation": "sum"
            },
            "auth": {
              "type": "OIDC",
              "audience": "OIDC_AUDIENCE"
            }
          }
        }
      }
    ]
      

What's next

• Create an HTTP endpoint for your function
• Trigger a Cloud Run-hosted service
• Use Workflows with Cloud Run and Cloud Functions tutorial