Stay organized with collections
Save and categorize content based on your preferences.
Use Identity-Aware Proxy (IAP) to control access to applications
on your workstations. IAP establishes a central authorization
layer, allowing you to manage access at the application level rather than
relying on network-level firewalls.
You can control access based on user identity, group membership, device
security, location, IP address, and other signals. Users access applications
using their web browser and HTTPS, while IT teams centrally define and enforce
access policies in one place.
This document describes how to enable IAP for applications on
workstations in your cluster. The following diagram illustrates a cluster
with IAP enabled:
Figure 1. Cluster with IAP enabled
Before you begin
Before you can enable IAP for your workstations, your cluster
needs the following:
A custom domain: IAP is only supported on workstation
clusters that use a custom domain.
An Application Load Balancer: This load balancer will handle all
ingress HTTP traffic using a Private Service Connect (PSC) endpoint
and lets you to configure the IAP.
BACKEND_SERVICE_NAME: the name of the backend service.
PRINCIPAL: the principal to grant access to. For example, group:my-group@example.com, user:test-user@example.com, or domain:example.com.
EXPRESSION: the condition expression, written in the Common Expression Language (CEL). For example, this expression can be used to specify access levels to configure context-aware access.
TITLE: a title for the condition.
DESCRIPTION: an optional description for the condition.
Cloud Workstations still performs the IAM checks based on the IAM policy configured on the individual workstation resources. To avoid redundancy, consider configuring the IAP policy to grant permissions to a broad group that
encompasses all approved workstation users, or your entire domain. You can primarily use this policy to specify access levels to configure context-aware access.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# Enable IAP\n\nUse [Identity-Aware Proxy (IAP)](/iap/docs) to control access to applications\non your workstations. IAP establishes a central authorization\nlayer, allowing you to manage access at the application level rather than\nrelying on network-level firewalls.\n\nYou can control access based on user identity, group membership, device\nsecurity, location, IP address, and other signals. Users access applications\nusing their web browser and HTTPS, while IT teams centrally define and enforce\naccess policies in one place.\n\nThis document describes how to enable IAP for applications on\nworkstations in your cluster. The following diagram illustrates a cluster\nwith IAP enabled:\n\n\nFigure 1. Cluster with IAP enabled\n\n\u003cbr /\u003e\n\nBefore you begin\n----------------\n\nBefore you can enable IAP for your workstations, your cluster\nneeds the following:\n\n- **A custom domain:** IAP is only supported on workstation clusters that use a custom domain.\n- **An Application Load Balancer:** This load balancer will handle all ingress HTTP traffic using a Private Service Connect (PSC) endpoint and lets you to configure the IAP.\n\nTo set up these components, see [Set up custom domains for Cloud Workstations](/workstations/docs/set-up-custom-domains-for-cloud-workstations).\n\nEnable the proxy\n----------------\n\nTo enable IAP for your workstations, follow these steps:\n\n1. Enable IAP on the cluster's Application Load Balancer, by\n running the following command:\n\n gcloud compute backend-services update \u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e \\\n --iap=enabled,oauth2-client-id=\u003cvar translate=\"no\"\u003eCLIENT_ID\u003c/var\u003e,oauth2-client-secret=\u003cvar translate=\"no\"\u003eCLIENT_SECRET\u003c/var\u003e \\\n --global\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e: the name of the backend service you created while setting up a custom domain for your cluster.\n - \u003cvar translate=\"no\"\u003eCLIENT_ID\u003c/var\u003e: the OAuth 2.0 client ID.\n - \u003cvar translate=\"no\"\u003eCLIENT_SECRET\u003c/var\u003e: the OAuth 2.0 client secret.\n\n For more information on setting up a Application Load Balancer with\n IAP enabled, see [Enable IAP on a load balancer](/iap/docs/load-balancer-howto#enable-iap).\n2. Grant access to users in your domain:\n\n gcloud iap web add-iam-policy-binding \\\n --resource-type=backend-services \\\n --service=\u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e \\\n --member='\u003cvar translate=\"no\"\u003ePRINCIPAL\u003c/var\u003e' \\\n --role='roles/iap.httpsResourceAccessor' \\\n --condition=\"expression=\u003cvar translate=\"no\"\u003eEXPRESSION\u003c/var\u003e,title=\u003cvar translate=\"no\"\u003eTITLE\u003c/var\u003e,description=\u003cvar translate=\"no\"\u003eDESCRIPTION\u003c/var\u003e\"\n\n Replace the following:\n - \u003cvar translate=\"no\"\u003eBACKEND_SERVICE_NAME\u003c/var\u003e: the name of the backend service.\n - \u003cvar translate=\"no\"\u003ePRINCIPAL\u003c/var\u003e: the principal to grant access to. For example, `group:my-group@example.com`, `user:test-user@example.com`, or `domain:example.com`.\n - \u003cvar translate=\"no\"\u003eEXPRESSION\u003c/var\u003e: the condition expression, written in the Common Expression Language (CEL). For example, this expression can be used to specify [access levels](/access-context-manager/docs/overview#access-levels) to configure context-aware access.\n - \u003cvar translate=\"no\"\u003eTITLE\u003c/var\u003e: a title for the condition.\n - \u003cvar translate=\"no\"\u003eDESCRIPTION\u003c/var\u003e: an optional description for the condition. Cloud Workstations still performs the IAM checks based on the IAM policy configured on the individual workstation resources. To avoid redundancy, consider configuring the IAP policy to [grant permissions](/iam/docs/principal-identifiers#allow) to a broad group that encompasses all approved workstation users, or your entire domain. You can primarily use this policy to specify [access levels](/access-context-manager/docs/overview#access-levels) to configure context-aware access.\n\n For more information on granting access to users, see [gcloud iap web add-iam-policy-binding](/sdk/gcloud/reference/iap/web/add-iam-policy-binding)."]]