Configure Identity-Aware Proxy (IAP) on GCP

Secure Access to Private VMs Without Public IP or VPN

Most teams still expose virtual machines with public IPs or rely on VPNs just to allow internal access. Both approaches increase attack surface and operational overhead. There’s a cleaner model: identity-based access.

That’s exactly what Google Cloud Identity-Aware Proxy (IAP) provides.

This guide walks you through a real-world, zero-cost setup where:

• Your VM has no external IP
• Access is controlled using IAM (identity)
• Users connect via secure tunnels through IAP

No load balancers. No VPN. No shortcuts.

Architecture Overview

Identity-Aware Proxy (IAP) Architecture

Instead of opening your VM to the internet, access flows like this:

User → Google IAP → Private VM (No need External IP)

The VM stays private. Authentication happens at Google’s edge using your identity.

Module-1: IAP Setup

Required Permissions (Minimum)

| Role                      | Why it’s needed                |
| ------------------------- | ------------------------------ |
| `roles/compute.admin`     | Create and manage VM instances |
| `roles/iap.admin`         | Configure IAP access           |
| `roles/iam.securityAdmin` | Assign IAM roles to users      |

Create a Private VM

The VM must not have an external IP.

gcloud compute instances create private-vm \
  --zone=us-central1-a \
  --machine-type=e2-medium \
  --no-address

This ensures the VM is only reachable internally.

Allow IAP Traffic Through Firewall

IAP connects from a fixed Google IP range. If you don’t allow it, nothing will work.

gcloud compute firewall-rules create allow-iap-ssh \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp \
  --source-ranges=35.235.240.0/20 \
  --target-tags=iap-access

Enable OS Login

This ties SSH access to IAM identities instead of SSH keys.

gcloud compute project-info add-metadata \
  --metadata enable-oslogin=TRUE

This is not optional if you want clean access control.

Grant required permissions to Users

Grant IAP Access to Users

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:user@example.com" \
  --role="roles/iap.tunnelResourceAccessor"

Without this role, users won’t even reach the VM.

Get UK’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Grant SSH Login Permission

gcloud projects add-iam-policy-binding PROJECT_ID \
  --member="user:user@example.com" \
  --role="roles/compute.osLogin"

This allows actual login after the tunnel is established.

Module-2: User Access via IAP

Required Permissions

| Role                               | Purpose               |
| ---------------------------------- | --------------------- |
| `roles/iap.tunnelResourceAccessor` | Allows tunnel via IAP |
| `roles/compute.osLogin`            | Allows SSH login      |

Initial Setup

• Install: Google Cloud SDK
• Login: Setup Google Cloud SDK

gcloud auth login
gcloud config set project PROJECT_ID

Access the VM via SSH

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

This command:

• Authenticates you
• Establishes a secure tunnel
• Logs you into the VM

No IP address required.

Access via RDP (Windows)

gcloud compute start-iap-tunnel private-vm 3389 \
  --zone=us-central1-a \
  --local-host-port=localhost:3389

Then open your RDP client and connect to:

localhost:3389

Common Issues

• Connection timeout: Firewall rule missing or incorrect
• Permission denied: Missing IAM role
• SSH not working: OS Login not enabled

Final Thoughts

This approach shifts security from:

• Network-based (IP, VPN) ➡ TO ➡ Identity-based (IAM, authentication)

That’s the direction modern cloud architecture is moving toward.

If you implement this correctly:

• Your VM is not exposed
• Access is tightly controlled
• You eliminate unnecessary infrastructure like bastion hosts

If you implement it poorly:

• You’ll spend hours debugging simple IAM or firewall mistakes

There’s no middle ground here.