This page describes the basic concepts of Identity-Aware Proxy(IAP), a Google Cloud global service.

IAP lets you establish a central authorizationlayer for applications accessed by HTTPS, so you can use an application-levelaccess control model instead of relying on network-level firewalls.

IAP policies scale across your organization. You can defineaccess policies centrally and apply them to all of your applications andresources. When you assign a dedicated team to create and enforce policies, youprotect your project from incorrect policy definition or implementation in anyapplication.

When to use IAP

Use IAP when you want to enforce access control policiesfor applications and resources. IAP works withsigned headers or the App Enginestandard environmentUsers APIto secure your app. With IAP, you can set up group-basedapplication access: a resource could be accessible for employees andinaccessible for contractors, or only accessible to a specific department.

How IAP works

When an application or resource is protected by IAP, it canonly be accessed through the proxy byprincipals, also known as users,who have the correctIdentity and Access Management (IAM) role.When you grant a user access to an application or resource byIAP, they're subject to the fine-grained access controlsimplemented by the product in use without requiring a VPN. When a user triesto access an IAP-secured resource, IAPperforms authentication and authorization checks.

App Engine

Cloud Run

Compute Engine

GKE

On-premises

Authentication

Requests to your Google Cloud resources come through Cloud Run,App Engine, and Cloud Load Balancing (External and Internal HTTP(S)Load Balancing). The serving infrastructure code for these products checks ifIAP is enabled for the app or backend service. IfIAP is enabled, information about the protected resource issent to the IAP authentication server. This includesinformation like the Google Cloud project number, the request URL, and anyIAP credentials in the request headers or cookies.

IAP then checks whether the user is signed in. If theuser isn't signed in, their browser is redirected to one of the followingsign-in methods that IAP supports:

• Google Account: Your Google Cloud users with Google Accounts areredirected through the Google Account sign-in flow to access Google Cloud.

• Workforce Identity Federation: Your Google Cloud users in an external identityprovider are redirected through their IdP sign-in to access Google Cloud.

• Identity Platform: Your customers who use email and passwords or socialsign-ins, such as Facebook, Apple, and Google (Gmail) to access yourapplication.

After authentication, the user's browser stores a token in a browser cookie forfuture sign-ins.

If the request credentials are valid, the authentication server uses thosecredentials to get the user's identity (email address and user ID). Theauthentication server then uses the identity to check the user'sIAM role and check if the user is authorized to access theresource.

If you're using Compute Engine or Google Kubernetes Engine,users who can access the application-serving port of the Virtual Machine (VM)can bypass IAP authentication. Compute Engine and GKEfirewall rules can't protect against access from code running on the same VM asthe IAP-secured application. Firewall rules can protectagainst access from another VM, but only if properly configured. Learnaboutyour responsibilities to ensure security.

If you're using Cloud Run, you canenableIAP in thefollowing ways:

• Directly on your Cloud Run services. This enablesIAP to protect all ingress paths to Cloud Run,including theauto-assigned URL and anyconfigured load balancer URL. This configuration is useful when you havea single Cloud Run service to enable IAP for.
• Through a load balancer with a Cloud Run backend. Thisconfiguration is useful when you have multiple Cloud Runservices in different regions behind a single global load balancer. In thisconfiguration, the auto-assigned URL is unprotected by IAP andmight be directly accessible. Learn more aboutyourresponsibilities to ensure security.

If a Cloud Run service is behind a load balancer, don't enableIAP on both the load balancer and the Cloud Runservice.

Learn more aboutWorkforce Identity Federation.Learn how toconfigure IAP with Workforce Identity Federation.Alternatively, if you want to sync your external identities to their own GoogleAccounts, you can useGoogle Cloud Directory Syncto synchronize with your IdP.

Authorization

After authentication, IAP applies the relevantIAM policy to check if the user is authorized to access therequested resource. If the user has theIAP-secured Web App User role on theGoogle Cloud console project where the resource exists, they're authorized toaccess the application. To manage theIAP-secured Web App User role list,use theIAP panel on the Google Cloud console.

When you turn on IAP for a resource, it automaticallycreates an OAuth 2.0 client ID and secret. If you delete the automaticallygenerated OAuth 2.0 credentials, IAP won't functioncorrectly. You can view and manage OAuth 2.0 credentials in theGoogle Cloud console APIs & services.

Context-aware access

As part of theauthorization step, you can use context-aware access to providesecure access to the following types of resources:

Google Cloud console and APIs

• First layer of defense in protecting infrastructure access to Google Cloud.
• Advanced context-aware Google Cloud access to users.

Virtual Machines (VMs)

• Enables administrative SSH/RDP access to VMs in Google Cloud and in otherclouds.
• Lets you implement robust context-aware controls to restrict access to onlydesignated administrators.

Web applications

• Provides authorization and authentication for web applications hosted inGoogle Cloud and other clouds.
• Provides continuous authorization to prevent unauthorized access and data loss.

Your responsibilities

IAP secures authentication and authorization of all requeststo Cloud Run, App Engine, Cloud Load Balancing (HTTPS),and internal HTTP load balancing.

To ensure security, you must take the following precautions:

• If you're enabling IAP on a load balancer, verify whether thebackend resources can be accessed directly.
  • If the backend resource is a VM, configure your firewall rules to protectagainst traffic that doesn't come through the load balancer.IAP doesn't protect against activity within a project,such as another VM inside the project.
  • If the backend resource is a Cloud Run service, you candisable the run.app URL to ensure that all ingress comes in through the loadbalancer. If you choose to leave the run.app URL enabled, you should useingress controls to block traffic from outsideyour network.
• Update your app to usesigned headers or use theApp Engine standard environmentUsers API.

What's next

• Get started with IAP by completing one of the followingtasks:
  • Enable IAPdirectly on yourCloud Runservices or on aload balancer with aCloud Run backend.
  • Complete the App Engine quickstart toManage Access with GoogleAccounts.
  • EnableIAP for Compute Engine.
  • EnableIAP for GKE.
  • EnableIAP for on-premises apps.
• Learn more:
  • Authenticating to Compute Engine
  • App Engine user authentication options
  • Using OAuth 2.0 to access Google APIs
  • Google Cloud auth guide
  • Setting up a load balancer
  • Setting up a load balancer with Cloud Run (fully managed)
  • Restricting ingress for Cloud Run