You can invoke a private on‑premises, Compute Engine, Google Kubernetes Engine (GKE), or other Google Cloud endpoint from Workflows by enabling Identity-Aware Proxy (IAP) for the endpoint. IAP is used to enforce access control policies, and it lets you establish a central authorization layer for applications accessed by HTTPS, so that you can use an application-level access control model instead of relying on network-level firewalls. For more information, see the IAP overview and the following:
- Enable IAP for App Engine
- Enable IAP for Cloud Run
- Enable IAP for Compute Engine
- Enable IAP for GKE
- Enable IAP for on‑premises apps
Alternatively, you can target a private endpoint for HTTP calls from your workflow execution by using Service Directory's service registry with Workflows. By creating a private endpoint within a Virtual Private Cloud (VPC) network, the endpoint can be VPC Service Controls-compliant. For more information, see Invoke a VPC Service Controls-compliant private endpoint.
Make an HTTP request
Calling or invoking a private endpoint 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.
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 been granted one or more Identity and Access Management (IAM) roles containing the required 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 want to give it access to—you make the requesting identity a principal, or user, of the resource—and then assign it the appropriate role. The role defines what permissions the identity has in the context of the resource. When an application or resource is protected by IAP, it can only be accessed through the proxy by principals who have the correct role.
For example, after authentication, IAP applies the relevant
allow policy to check if the principal is authorized to access the requested
resource. If the principal has the IAP-secured Web App User role
(roles/iap.httpsResourceAccessor
) on the Google Cloud console project
where the resource exists, they're authorized to access the application.
You can configure access to your IAP-secured resource through the IAP page by adding the Workflows service account as a principal. For more information, see Managing access to IAP-secured resources.
Add authentication information to your workflow
By default, HTTP requests don't contain identity or access tokens for security reasons. You must explicitly add authentication information to your workflow definition. When making requests to a private endpoint, use OIDC to authenticate through IAP.
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.
YAML
- step_A: call: http.get args: url: https://www.example.com/endpoint body: someValue: "Hello World" anotherValue: 123 auth: type: OIDC audience: OIDC_AUDIENCE
JSON
[ { "step_A": { "call": "http.get", "args": { "url": "https://www.example.com/endpoint", "body": { "someValue": "Hello World", "anotherValue": 123 }, "auth": { "type": "OIDC", "audience": "OIDC_AUDIENCE" } } } } ]
You can use the audience
parameter to specify the OIDC audience for the token.
When invoking an IAP-enabled endpoint, you must specify the
OAuth 2.0 client ID that you have configured for your application. This can be
obtained from the Credentials page.
What's next
- Grant a workflow permission to access Google Cloud resources
- Access HTTP response data saved in a variable