Secure Access to Private IP AlloyDB with Identity-Aware Proxy (IAP) and Auth Proxy🔒

Saurabh Kumar — Mon, 16 Feb 2026 05:43:55 +0000

Need to access a private AlloyDB instance securely from your local machine? In this guide, I'll show you how to use Identity-Aware Proxy (IAP) combined with AlloyDB Auth Proxy to create a secure connection to your private AlloyDB instance-all with just your gcloud command and zero public IPs required.

The Challenge

Imagine you have an AlloyDB instance sitting in a private subnet-no public IP, no direct internet access. This is great for security, but how do you connect to it for development, debugging, or administration tasks? Traditional approaches often involve:

Setting up VPNs
Exposing databases to the internet (security risk)
Complex networking configurations
Managing multiple access points

There's a better way! Google Cloud's IAP (Identity-Aware Proxy) combined with AlloyDB Auth Proxy lets you securely access your database using identity-based authentication, leveraging Google's enterprise-grade security infrastructure. IAP eliminates the need for VPNs by providing secure, authenticated access to private resources through Google's identity system.

What We'll Build

By the end of this tutorial, you'll have:

A private VPC with AlloyDB instance (no public IP)
A secure jumphost VM (no public IP) accessible only via IAP
AlloyDB Auth Proxy running on the jumphost for secure database connections
Local access to AlloyDB through an encrypted IAP tunnel

The Challenge
What We'll Build
Architecture Overview
Prerequisites
Step 1: Set Up Network Infrastructure
- Create VPC and Subnet
- Configure Firewall Rules for IAP
Step 2: Create Service Account
Step 3: Provision the Jumphost VM
Step 4: Set Up Cloud NAT
Step 5: Provision AlloyDB
- Enable Private Services Access
- Create AlloyDB Cluster and Instance
Step 6: Access the Jumphost via IAP
- Verify Internet Access
- Test Direct AlloyDB Connection
Step 7: Install and Run AlloyDB Auth Proxy
- Download and Install
- Run the Auth Proxy
Step 8: Connect from Your Local Machine
Step 9: Grant Access to Team Members
Security Best Practices
Troubleshooting
- "Network is unreachable" during apt update
- IAP SSH connection fails
- AlloyDB connection refused
- Port forwarding not working
Cost Optimization Tips
Conclusion
References

Architecture Overview

┌─────────────┐         ┌──────────────────────────────────────────┐
│   Your      │  IAP    │          Private VPC                     │
│   Local     │  Tunnel │  ┌──────────────┐         ┌─────────────┐│
│   Machine   │ ────────┼─►│   Jumphost   │  Auth   │   AlloyDB   ││
│             │         │  │     VM       │ ──────► │  Instance   ││
│             │         │  │  (Private)   │  Proxy  │  (Private)  ││
└─────────────┘         │  └──────────────┘         └─────────────┘│
                        └──────────────────────────────────────────┘

Prerequisites

Before we begin, make sure you have:

A Google Cloud Project with billing enabled
gcloud CLI installed and authenticated
PostgreSQL client installed (for local connections)

In this tutorial, we'll use IAP's TCP forwarding feature to securely connect to a private VM (jumphost) that has no public IP address. This jumphost will then connect to your AlloyDB instance, which is also in a private network.

Step 1: Set Up Network Infrastructure

Create VPC and Subnet

First, let's create a custom VPC network for our private resources:

gcloud compute networks create restricted-access-vpc \
    --subnet-mode=custom \
    --bgp-routing-mode=regional

Create a subnet within this VPC:

gcloud compute networks subnets create private-apps-us-south1 \
    --network=restricted-access-vpc \
    --range=10.10.0.0/24 \
    --region=us-south1

Note: Make sure to provision your AlloyDB instance in the same VPC where your jumphost VM will be located.

Configure Firewall Rules for IAP

IAP uses specific IP ranges to connect to your VMs. These IP ranges are managed by Google and are used exclusively by IAP services. We need to allow these:

gcloud compute firewall-rules create allow-iap-access \
    --network=restricted-access-vpc \
    --allow=tcp:22,tcp:3389 \
    --source-ranges=35.235.240.0/20 \
    --description="Allow IAP to access jumphost VM"

This firewall rule allows IAP to connect to VMs without public IPs for SSH access.

Step 2: Create Service Account

The jumphost VM needs permissions to access AlloyDB. Let's create a service account with the necessary roles:

# Create service account
gcloud iam service-accounts create alloydb-jumphost-sa \
    --display-name="AlloyDB Jumphost Service Account"

# Grant AlloyDB Client role
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:alloydb-jumphost-sa@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/alloydb.client"

# Grant Service Usage Consumer role (required for AlloyDB access)
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="serviceAccount:alloydb-jumphost-sa@PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/serviceusage.serviceUsageConsumer"

Replace PROJECT_ID with your actual Google Cloud project ID.

Step 3: Provision the Jumphost VM

Now, let's create the jumphost VM without a public IP address:

gcloud compute instances create iap-jumphost-vm \
    --zone=us-south1-b \
    --machine-type=e2-micro \
    --subnet=private-apps-us-south1 \
    --no-address \
    --service-account=alloydb-jumphost-sa@PROJECT_ID.iam.gserviceaccount.com \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --image-family=ubuntu-2204-lts \
    --image-project=ubuntu-os-cloud \
    --preemptible

Key points:

--no-address: No external IP for maximum security
--service-account: Attach the service account with AlloyDB permissions
--subnet: Use the subnet created in Step 1
--preemptible: Cost optimization for testing (optional)

Step 4: Set Up Cloud NAT

Since our VM has no public IP, we need Cloud NAT for outbound internet access (to download packages, etc.):

# Create Cloud Router
gcloud compute routers create nat-router \
    --network=restricted-access-vpc \
    --region=us-south1

# Create Cloud NAT Gateway
gcloud compute routers nats create nat-gateway \
    --router=nat-router \
    --region=us-south1 \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

Select NAT type: Public and create the Cloud Router attached to your VPC.

Step 5: Provision AlloyDB

Provision your AlloyDB cluster and instance in the same VPC as your jumphost VM. Make sure to configure Private Services Access (PSA) for AlloyDB to connect to Google-managed services.

Step 6: Access the Jumphost via IAP

Now for the magic! This is where IAP comes into play. We'll connect to your private VM using IAP's TCP forwarding feature:

Get the SSH command from the Google Cloud Console VM UI and use it to connect via IAP. The command will automatically include the --tunnel-through-iap flag, which tells gcloud to route your connection through IAP instead of requiring a public IP.

That's it! Simple and secure access through Google's identity verification and IAP tunneling. IAP handles all the authentication and encryption automatically—you just need to be authenticated with gcloud and have the proper IAM permissions.

Verify Internet Access

Once connected, test that Cloud NAT is working:

sudo apt update

If this works, you're all set! If not, double-check your Cloud NAT configuration.

Test Direct AlloyDB Connection

From the jumphost VM, you can test direct connection to AlloyDB:

# Install PostgreSQL client
sudo apt install postgresql-client-common postgresql-client -y

# Connect to AlloyDB (use the private IP from AlloyDB instance details)
psql -h 10.48.0.2 -p 5432 -U postgres

Step 7: Install and Run AlloyDB Auth Proxy

The AlloyDB Auth Proxy provides secure, authenticated connections to your AlloyDB instance.

Download and Install

# Download the latest version from GitHub
curl -L -o alloydb-auth-proxy https://github.com/GoogleCloudPlatform/alloydb-auth-proxy/releases/latest/download/alloydb-auth-proxy.linux.amd64

# Make it executable
chmod +x alloydb-auth-proxy

Run the Auth Proxy

./alloydb-auth-proxy "projects/PROJECT_ID/locations/REGION/clusters/CLUSTER_NAME/instances/INSTANCE_NAME" \
    --address "0.0.0.0" \
    --port 5432

Example:

./alloydb-auth-proxy "projects/pocs-487506/locations/us-east1/clusters/dev-alloydb-primary/instances/dev-alloydb-primary-primary" \
    --address "0.0.0.0" \
    --port 5432

Replace the connection URI with your AlloyDB instance details. You can find the connection URI in the AlloyDB instance details in the Google Cloud Console. The proxy will now listen on port 5432.

Step 8: Connect from Your Local Machine

This is where it all comes together! From your local machine, establish an SSH connection with port forwarding.

Open a new terminal and run this command:

gcloud compute ssh iap-jumphost-vm \
    --zone=us-south1-b \
    --tunnel-through-iap \
    --ssh-flag="-L 5432:localhost:5432"

This command does two important things:

Connects via IAP (--tunnel-through-iap): Creates a secure, authenticated tunnel through IAP to your private jumphost VM
Port Forwarding (-L 5432:localhost:5432): Forwards traffic from your local port 5432 to the jumphost's port 5432, where the AlloyDB Auth Proxy is listening

The IAP tunnel ensures that all traffic is encrypted and authenticated before reaching your private network.

Now, in another terminal (keep the SSH session running), connect to AlloyDB as if it were local:

psql -h localhost -p 5432 -U postgres

🎉 Success! You're now connected to your private AlloyDB instance from your local machine through a secure IAP tunnel!

Step 9: Grant Access to Team Members

To allow other users to access the jumphost via IAP, grant them the necessary IAM roles:

# IAP-secured Tunnel User role
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:USER_EMAIL" \
    --role="roles/iap.tunnelResourceAccessor"

# Compute Instance Admin role (for SSH)
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member="user:USER_EMAIL" \
    --role="roles/compute.instanceAdmin.v1"

Replace USER_EMAIL with the email address of the user who needs access.

Security Best Practices

No External IPs: Keep all resources private—no public-facing endpoints
IAP Authentication: Leverage Google's identity verification—no shared keys or passwords
Least Privilege: Grant only necessary permissions to service accounts and users
Network Isolation: Use private VPCs with controlled firewall rules
Audit Logging: Enable Cloud Audit Logs to monitor access

Troubleshooting

"Network is unreachable" during apt update

Ensure Cloud NAT is properly configured and attached to your VPC
Verify the NAT gateway is in the same region as your subnet

IAP SSH connection fails

Check firewall rules allow IAP source ranges (35.235.240.0/20) - this is the IP range that IAP uses to connect to your VMs
Verify you have the roles/iap.tunnelResourceAccessor IAM role - this role is required to use IAP's TCP forwarding feature
Ensure the firewall rule is properly configured for your VPC
Make sure you're authenticated with gcloud auth login and have the correct project selected

AlloyDB connection refused

Ensure Auth Proxy is running on the jumphost
Verify service account has roles/alloydb.client role
Check AlloyDB instance is in the same VPC as the jumphost

Port forwarding not working

Confirm Auth Proxy is listening on 0.0.0.0:5432 (not just 127.0.0.1)
Verify SSH command includes correct port forwarding flags
Keep the SSH session running while connecting

Cost Optimization Tips

Use preemptible instances for development/testing (saves up to 80%)
Stop the jumphost VM when not in use
Consider e2-micro instances for light workloads
Delete Cloud NAT if outbound internet access isn't needed

Conclusion

This setup provides enterprise-grade security for accessing AlloyDB while maintaining ease of use. The combination of IAP tunneling, private networking, and AlloyDB Auth Proxy ensures that your database remains completely isolated from the public internet while still being accessible to authorized users.

The beauty of this approach is its simplicity: just run a gcloud command, and you have a secure tunnel to your private database. IAP (Identity-Aware Proxy) handles authentication and encryption using your Google Cloud identity, while AlloyDB Auth Proxy manages secure database connections—all working together seamlessly with Google Cloud's identity-aware security infrastructure. No VPN clients, no complex networking, just secure, identity-based access to your private resources.

References

If you found this helpful, feel free to share your thoughts or questions in the comments below. Have you tried this setup? What challenges did you face? Let's discuss!

Forem: Saurabh Kumar