Enabling IAP for Cloud Run

This page explains how to secure a Cloud Run service with Identity-Aware Proxy (IAP).

Known limitations

  • IAM must be configured to grant allUsers the Invoker role on the Cloud Run service. You can still lock down access at the network level so all external requests must be authorized via IAP. See Configuring Cloud Run to limit access for more information. This limitation is being addressed so you'll be able to explicitly grant project-specific IAP access to the Cloud Run service.

  • Cloud Run services with HTTP/2 enabled encounter an infinite redirect loop upon request when secured with IAP. This behavior is not intended and Google anticipates addressing this in the future. For now, to avoid this behavior Google recommends disabling HTTP/2 configuration (the default setting) when a service sits behind IAP.

  • Cloud Run services served by a Envoy based load balancer mode (Global external HTTP(S) load balancer) do not have the X-Goog-IAP-JWT-Assertion IAP header. To avoid this behavior, we recommend using the Global external HTTP(S) load balancer (classic) mode.

Before you begin

To enable IAP for Cloud Run, you need the following:

  • A Google Cloud console project with billing enabled.
  • A group of one or more Cloud Run services, served by a load balancer.
  • Application code to verify that all requests have an identity.

Enabling IAP


If you haven't configured your project's OAuth consent screen, you need to do so. An email address and product name are required for the OAuth consent screen.

  1. Go to the OAuth consent screen.
  2. Under Support email, select the email address you want to display as a public contact. This email address must be your email address, or a Google Group you own.
  3. Enter the Application name you want to display.
  4. Add any optional details.
  5. Click Save.

To change information on the OAuth consent screen later, such as the product name or email address, repeat the preceding steps to configure the consent screen.

Setting up IAP access

  1. Go to the Identity-Aware Proxy page.
  2. Select the project you want to secure with IAP.
  3. Under HTTPS RESOURCES, select the checkbox next to the load balancer backend service to which you want to add members.
  4. On the right side panel, click Add member.
  5. In the Add members dialog, enter the accounts of groups or individuals who should have the IAP-secured Web App User role for the project. The following kinds of accounts can be members:

    • Google Account: user@gmail.com - This can also be a Google Workspace account, such as user@google.com or some other workspace domain.
    • Google Group: admins@googlegroups.com
    • Service account: server@example.gserviceaccount.com
    • Google Workspace domain: example.com
  6. Select Cloud IAP > IAP-secured Web App User from the Roles drop-down list.

  7. Click Save.

Turning on IAP

  1. On the IAP page, under HTTPS RESOURCES, find the load balancer backend service to which you want to restrict access. To turn on IAP for a resource, toggle the On or Off switch in the IAP column. To enable IAP:
    • At least one protocol in the load balancer frontend configuration must be HTTPS. Learn about setting up a load balancer.
    • You need the compute.backendServices.update, clientauthconfig.clients.create, and clientauthconfig.clients.getWithSecret permissions. These permissions are granted by roles, such as the Project Editor role. To learn more, see Managing access to IAP-secured resources.
  2. In the Turn on IAP window that appears, click Turn On to confirm that you want IAP to secure your resource. After you turn on IAP, it requires login credentials for all connections to your load balancer. Only accounts with the IAP-Secured Web App User role on the project will be given access.
  3. Create a service account by going to the IAM page in the console.

    Go to IAM

  4. Search for the service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com service account, and then add the Cloud Run Invoker role to the principal. Additionally, you can add conditions to restrict the role to required Cloud Run services.


  1. Follow the instructions in Programmatically creating OAuth clients for IAP to configure the OAuth consent screen and create the OAuth client.
  2. Save the OAuth client ID and secret.
  3. If you have not previously done so, create a service account by running the following command. If you previously created a service account, running the command does not create duplicate service accounts.
    gcloud beta services identity create --service=iap.googleapis.com --project=[PROJECT_ID]
  4. Grant invoker permission to the service account, created in the previous step, by running the following command:
    gcloud run services add-iam-policy-binding [SERVICE-NAME] \
    --member=`serviceAccount:service-[PROJECT-NUMBER]@gcp-sa-iap.iam.gserviceaccount.com`  \
  5. Enable IAP by running either the globally or regionally scoped command, depending on whether your load balancer backend service is global or regional. Use the OAuth client ID and secret from the previous step.

    Global scope:

    gcloud compute backend-services update BACKEND_SERVICE_NAME --global --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET

    Regional scope:

    gcloud compute backend-services update BACKEND_SERVICE_NAME --region REGION_NAME --iap=enabled,oauth2-client-id=CLIENT_ID,oauth2-client-secret=CLIENT_SECRET
    Replace the following:

    • BACKEND_SERVICE_NAME: the name of the backend service.
    • CLIENT_ID: the OAuth client ID, from the previous step.
    • CLIENT_SECRET: the OAuth client secret, from the previous step.
    • REGION_NAME: the region in which you want to enable IAP.

After you enable IAP, you can use the Google Cloud CLI to manipulate an IAP access policy using the Identity and Access Management role roles/iap.httpsResourceAccessor. See Managing roles and permissions for more information.

Configuring Cloud Run to limit access

Complete the following steps to configure access to your Cloud Run service.

  1. Configure the Cloud Run service and set ingress to Internal and Cloud Load Balancing. See Restricting ingress for Cloud Run for details.

    This step ensures that only internal clients and the External load balancer can call the Cloud Run service, and direct requests from the public internet are blocked.

  2. For the Cloud Run service, grant allUsers the Invoker role. For details, see Allowing public (unauthenticated) access.

    This step is important to ensuring your IAP configuration works properly, because it configures Cloud Run to not try to authenticate and authorize requests on its own. Instead, IAP completes the authentication and authorization.

Note that this configuration allows all clients that are considered internal (per definition in Restricting ingress for Cloud Run) to access the Cloud Run service without authenticating. All other clients coming in through the external load balancer authenticate through IAP. This is a known limitation that will be addressed in the future.