Identity-Aware Proxy (IAP)

Introduction to Identity-Aware Proxy (IAP)

In a world where the network perimeter has dissolved, Identity-Aware Proxy (IAP) is the Google Cloud solution for implementing a Zero Trust security model. Inspired by Google's internal BeyondCorp initiative, IAP shifts security from the network edge to the application and identity layer.

For a Professional Cloud Security Engineer (PSE), IAP is critical because it allows users to access internal applications and administrative interfaces (SSH/RDP) from anywhere, without the need for a traditional VPN. By verifying the user's identity and the context of their request, IAP ensures that only authorized users on healthy devices can reach your sensitive resources.

白話文解釋（Plain English Explanation）

1. The Bouncer at the Club (Web App Security)

A traditional VPN is like giving everyone a key to the front door of the building. Once inside, they can wander around. IAP is like a Bouncer standing directly in front of each VIP room (Application). Even if you are inside the building, you must show your ID to the Bouncer for that specific room. If you're not on the list, you don't get in.

2. The Secure Tunnel (TCP Forwarding)

Imagine you need to send a secret message to a friend in a fortified castle, but all the gates are locked. Instead of opening a gate (Firewall rule), you use a Secret Pneumatic Tube (IAP Tunnel) that goes directly to your friend's room. No one else can see the tube or use it, and you must verify yourself at the tube's entrance.

3. The Digital Valet (Identity Verification)

When you give your car to a valet, they don't just take the keys; they check your ticket (Identity) and ensure you are the rightful owner before handing back the car. IAP acts as this valet, checking your identity (Google Account/Identity Platform) and context (Device health) before handing over the "keys" to the application.

Context-Aware Access for Web Applications

IAP works by intercepting HTTP(S) requests sent to your application. It is integrated with Google Cloud Load Balancing (GCLB).

How it Works:

1. A user accesses a web app via a Load Balancer.
2. IAP checks if the user is authenticated. If not, it redirects them to the Google Login page.
3. After login, IAP checks IAM Policies to see if the user has the iap.httpsResourceAccessor role.
4. Optionally, IAP checks Access Levels (via Access Context Manager) to ensure the device is encrypted or coming from a specific IP.

IAP for SSH and RDP (TCP Forwarding)

One of the most powerful features for PSEs is TCP Forwarding. This allows you to manage VMs that do not have public IP addresses.

The Problem with Public IPs

Exposing port 22 (SSH) or 3389 (RDP) to the internet is a major security risk (Brute force, zero-day exploits).

The IAP Solution:

• VMs are kept on a private network with no external IPs.
• The Firewall is configured to allow traffic only from the IAP netblock (35.235.240.0/20).
• Users use the gcloud compute ssh --tunnel-through-iap command.
• IAP tunnels the SSH traffic over HTTPS (port 443) to the VM.

Securing Internal Apps without VPNs

Traditional VPNs are often slow, difficult to manage, and offer "all-or-nothing" access. IAP provides:

• Granular Access: Grant access to App A but not App B to the same user.
• No Client Software: For web apps, users only need a standard browser.
• Scalability: Managed by Google, so you don't have to worry about VPN concentrator capacity.

IAP Headers and Identity Verification

How does your application know who the user is after IAP lets them through?

IAP Headers

IAP passes identity information to the backend via HTTP headers:

• x-goog-authenticated-user-email
• x-goog-authenticated-user-id
• x-goog-iap-jwt-assertion (A signed JSON Web Token)

Configuring IAP with Load Balancers

IAP can be enabled on the following backend services:

• Compute Engine (Instance Groups)
• App Engine
• Cloud Run (via GCLB)
• GKE (via Ingress)

Setup Steps:

1. Configure a Global External HTTP(S) Load Balancer.
2. Configure the OAuth Consent Screen in the GCP Console.
3. Enable IAP on the Backend Service of the Load Balancer.
4. Add users to the IAP-secured Web App User IAM role.

Managing Access Levels and Conditions

Standard IAM checks "Who are you?". Context-Aware Access (integrated with Access Context Manager) checks "What is the state of your request?".

Example Access Levels:

• Device Policy: User must be on a corporate-managed laptop with disk encryption enabled.
• IP Range: User must be coming from the company's office HQ.
• Geographic: User must be located within the United States.

External Identities with Identity Platform

By default, IAP uses Google Accounts or Cloud Identity. However, you can use Google Cloud Identity Platform to support:

• SAML/OIDC providers (Azure AD, Okta).
• Social logins (Facebook, GitHub).
• Email/Password accounts for external partners or customers.

This allows you to provide IAP protection to users who are not part of your organization's directory.

Audit Logs for IAP Access

Visibility is a core requirement for PSEs. IAP logs all access attempts to Cloud Audit Logs.

• Successful Access: Logged under data_access logs.
• Denied Access: Logged as errors with the reason for denial (e.g., "Missing IAM role" or "Failed Access Level check").

BeyondCorp Enterprise Integration

BeyondCorp Enterprise is the premium version of IAP that adds:

• Threat and Data Protection: Integrated Chrome browser security to prevent data exfiltration.
• URL Filtering: Control which external sites users can visit from within protected apps.
• Continuous Monitoring: Re-evaluating access levels in real-time as device posture changes.

Troubleshooting IAP Connection Issues

1. 403 Forbidden (Web App)

• Check: Does the user have iap.httpsResourceAccessor?
• Check: Is an Access Level blocking them (e.g., wrong IP)?
• Check: Is the Load Balancer backend healthy?

2. "Unable to connect on port 22" (SSH Tunneling)

• Check: Does the VM have a service account?
• Check: Does the Firewall allow 35.235.240.0/20?
• Check: Does the user have iap.tunnelResourceAccessor?

CLI Commands for IAP

SSH via IAP Tunnel

gcloud compute ssh my-vm \
    --zone=us-central1-a \
    --tunnel-through-iap

Granting IAP Access via CLI

gcloud iap web add-iam-policy-binding \
    --resource-type=backend-services \
    --service=my-backend-service \
    --member='user:[email protected]' \
    --role='roles/iap.httpsResourceAccessor'

Security Best Practices for PSE

1. Defense in Depth: Even with IAP, keep your application's internal authentication (if it exists) as a second layer.
2. Validate JWTs: Always validate the IAP JWT in your backend code.
3. Rotate OAuth Secrets: Regularly rotate the client secrets used for IAP/OAuth.
4. Use Private IPs: Combined with IAP, ensure your backend VMs have no public IP addresses to minimize the attack surface.

Troubleshooting Scenarios

Scenario: Users can SSH but cannot use RDP via IAP

Diagnosis: Check the firewall rules. You might have allowed port 22 but forgotten port 3389 for the IAP netblock 35.235.240.0/20. Fix: Update the ingress firewall rule to include TCP port 3389.

Scenario: Application receives "Unauthorized" error despite IAP being ON

Diagnosis: The application might be expecting a specific cookie or header that IAP is stripping, or the application's internal JWT validation is failing due to an expired public key. Fix: Verify the JWT validation logic and ensure it fetches Google's latest public keys from https://www.gstatic.com/iap/verify/public_key.

PSE Exam Scenarios

Scenario 1: Replacing a VPN

"An organization wants to retire their legacy VPN and provide secure access to an internal HR portal. The portal must only be accessible from company-owned laptops. What is the solution?" Answer: Deploy IAP on a Load Balancer for the HR portal and define an Access Level in Access Context Manager that requires a managed device.

Scenario 2: Admin Access to Private VMs

"A security policy mandates that no VM can have a public IP address. How should administrators perform SSH maintenance?" Answer: Use IAP TCP Forwarding. Configure a firewall rule to allow 35.235.240.0/20 on port 22 and use gcloud compute ssh --tunnel-through-iap.

Summary Checklist

• Explain the difference between IAP for Web Apps and IAP for TCP Forwarding.
• List the required IAM roles for IAP access.
• Identify the IP range required for IAP firewall rules.
• Explain why validating the IAP JWT is necessary.
• Describe how Access Context Manager integrates with IAP.