Cloud Identity-Aware Proxy


This page describes the basic concepts of Cloud Identity-Aware Proxy (Cloud IAP).

Cloud IAP lets you establish a central authorization layer for applications accessed by HTTPS, enabling you to adopt an application-level access control model instead of relying on network-level firewalls.

Cloud IAP policies scale across your organization. You can define access policies centrally and apply them to all of your applications and resources. Policies can be created and enforced by a dedicated team, which protects your project from incorrect policy definition or implementation in any given application.

When to use Cloud IAP

Use Cloud IAP when you want to enforce access control policies for applications and resources. Cloud IAP works with signed headers or the App Engine standard environment Users API to secure your app. With Cloud IAP, you can set up group-based application access: a resource could be accessible for employees and inacccessible for contractors, or only accessible to a specific department.

How Cloud IAP works

Applications and resources protected by Cloud IAP can only be accessed through the proxy by users and groups with the correct Cloud Identity Access Management (Cloud IAM) role. When you grant a user access to an application or resource by Cloud IAP, they're subject to the fine-grained access controls implemented by the product in use without requiring a VPN. When a user tries to access a Cloud IAP-secured resource, Cloud IAP performs authentication and authorization checks.


Requests to your Google Cloud Platform (GCP) resources come through App Engine or Cloud Load Balancing (HTTPS). The serving infrastructure code for these products checks if Cloud IAP is enabled for the app or backend service. If Cloud IAP is enabled, information about the protected resource is sent to the Cloud IAP authentication server. This includes information like the GCP project number, the request URL, and any Cloud IAP credentials in the request headers or cookies.

Next, Cloud IAP checks the user's browser credentials. If none exist, the user is redirected to an OAuth 2.0 Google Account sign-in flow that stores a token in a browser cookie for future sign-ins. If you need to create Google Accounts for your existing users, you can use Google Cloud Directory Sync to synchronize with your Active Directory or LDAP server.

If the request credentials are valid, the authentication server uses those credentials to get the user's identity (email address and user ID). The authentication server then uses the identity to check the user's Cloud IAM role and check if the user is authorized to access the resource.

If you're using Compute Engine or Container Engine, users who can access the application-serving port of the Virtual Machine (VM) can bypass Cloud IAP authentication. The Compute Engine and Container Engine firewalls don't protect against access from other VMs on the same network or from code running on the same VM as the Cloud IAP-secured application. Learn about your responsibilities to ensure security.


After authentication, Cloud IAP applies the relevant Cloud IAM policy to check if the user is authorized to access the requested resource. If the user has the Cloud IAP access: HTTPS role on the Cloud Platform Console project where the resource exists, they're authorized to access the application. To manage the Cloud IAP access: HTTPS role list, use the Cloud IAP panel on the Cloud Platform Console.

When you turn on Cloud IAP for a resource, it automatically creates an OAuth 2.0 client ID and secret. If you delete the automatically generated OAuth 2.0 credentials, Cloud IAP won't function correctly. You can view and manage OAuth 2.0 credentials in the Cloud Platform Console API Manager.

Your responsibilities

Cloud IAP secures authentication and authorization of all requests to App Engine or Cloud Load Balancing HTTP(S). Cloud IAP doesn't protect against the following:

  • Activity inside your VM, such as if someone accesses the VM via SSH. This includes the App Engine flexible environment when direct SSH access to your VM is enabled.
  • Activity within a project, such as another VM inside the project.

To ensure security, you must take the following precautions:

  • Configure your firewall and load balancer to protect against traffic that doesn't come through the serving infrastructure.
  • Use signed headers or the App Engine standard environment Users API.

What's next

Send feedback about...

Identity-Aware Proxy Documentation