This page describes the basic concepts of Identity-Aware Proxy (IAP), a Google Cloud global service.
IAP lets you establish a central authorization layer for applications accessed by HTTPS, so you can use an application-level access control model instead of relying on network-level firewalls.
IAP policies scale across your organization. You can define access policies centrally and apply them to all of your applications and resources. When you assign a dedicated team to create and enforce policies, you protect your project from incorrect policy definition or implementation in any application.
When to use IAP
Use IAP when you want to enforce access control policies for applications and resources. IAP works with signed headers or the App Engine standard environment Users API to secure your app. With IAP, you can set up group-based application access: a resource could be accessible for employees and inaccessible for contractors, or only accessible to a specific department.
How IAP works
When an application or resource is protected by IAP, it can only be accessed through the proxy by principals, also known as users, who have the correct Identity and Access Management (IAM) role. When you grant a user access to an application or resource by 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 an IAP-secured resource, IAP performs authentication and authorization checks.
Requests to your Google Cloud resources come through App Engine, Cloud Load Balancing (External and Internal HTTP(S) Load Balancing). The serving infrastructure code for these products checks if IAP is enabled for the app or backend service. If IAP is enabled, information about the protected resource is sent to the IAP authentication server. This includes information like the Google Cloud project number, the request URL, and any IAP credentials in the request headers or cookies.
Next, 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 IAM role and check if the user is authorized to access the resource.
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 GKE firewall rules can't protect against access from code running on the same VM as the IAP-secured application. Firewall rules can protect against access from another VM, but only if properly configured. Learn about your responsibilities to ensure security.
If you're using Cloud Run, users who can access the auto-assigned URL can bypass IAP authentication. Ingress controls can restrict access to use load balancing, but only if properly configured. Learn more about your responsibilities to ensure security.
After authentication, IAP applies the relevant IAM policy to check if the user is authorized to access the requested resource. If the user has the IAP-secured Web App User role on the Google Cloud console project where the resource exists, they're authorized to access the application. To manage the IAP-secured Web App User role list, use the IAP panel on the Google Cloud console.
When you turn on 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, IAP won't function correctly. You can view and manage OAuth 2.0 credentials in the Google Cloud console APIs & services.
IAP secures authentication and authorization of all requests to App Engine, Cloud Load Balancing (HTTPS), or internal HTTP load balancing. IAP doesn't protect against activity within a project, such as another VM inside the project.
Internal HTTP load balancers require a BeyondCorp Enterprise subscription.
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.
- As an alternative if you're using Cloud Run, you can restrict access by using ingress controls.
- Use signed headers or the App Engine standard environment Users API.
- Get started with IAP by completing one of the following tasks:
- Learn more: