DEV Community

Cover image for Secure Access to Private IP AlloyDB with Identity-Aware Proxy (IAP) and Auth Proxy🔒
Saurabh Kumar
Saurabh Kumar

Posted on

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

#devops #cloud #googlecloud #alloydb

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

Table of Contents

Architecture Overview 

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

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
Enter fullscreen mode Exit fullscreen mode

VPC Configuration

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
Enter fullscreen mode Exit fullscreen mode

Subnet Configuration

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"
Enter fullscreen mode Exit fullscreen mode

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

Firewall Rules Configuration

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"
Enter fullscreen mode Exit fullscreen mode

Replace PROJECT_ID with your actual Google Cloud project ID.

Service Account Permissions

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
Enter fullscreen mode Exit fullscreen mode

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)

Service Account Mounted on Jumphost VM

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
Enter fullscreen mode Exit fullscreen mode

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

Cloud NAT Configuration

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.

AlloyDB Config

AlloyDB Cluster Credentials

Private Services Access (PSA) Configuration

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.

SSH Connection using IAP

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Database Connection from Jumphost VM

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

AlloyDB Auth Proxy Running

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"
Enter fullscreen mode Exit fullscreen mode

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.

SSH Connection with Port Forwarding

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

psql -h localhost -p 5432 -U postgres
Enter fullscreen mode Exit fullscreen mode

Local Connection to AlloyDB

🎉 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"
Enter fullscreen mode Exit fullscreen mode

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

Security Best Practices

  1. No External IPs: Keep all resources private—no public-facing endpoints
  2. IAP Authentication: Leverage Google's identity verification—no shared keys or passwords
  3. Least Privilege: Grant only necessary permissions to service accounts and users
  4. Network Isolation: Use private VPCs with controlled firewall rules
  5. 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!

Top comments (0)