Accessing Private GKE Clusters with IAP SSH Tunneling

Overview

In modern cloud environments, securing access to critical infrastructure is paramount. Directly exposing resources like Kubernetes clusters or virtual machines to the internet poses significant security risks. To mitigate these risks, private networks and Identity-Aware Proxy (IAP) create secure, private, scalable access pathways.

This blog outlines a practical setup for accessing private GKE clusters using a Jump Host and IAP SSH tunneling. By following this guide, you can ensure your infrastructure remains secure and complies with best practices.

Pioneers in Cloud Consulting & Migration Services

Reduced infrastructural costs
Accelerated application deployment

Get Started

Key Challenges Addressed

Securing Internal Resources
Private GKE clusters and compute instances do not have public IP addresses, making them inaccessible directly from the internet. This setup provides a secure and controlled way to access these resources.
Minimizing Public Exposure
Exposing resources to the public internet increases the risk of unauthorized access. Using private endpoints and internal IPs enhances security.
Granular Access Control
Leveraging IAP ensures fine-grained access control over who can connect to your internal systems, allowing only authorized users.
Simplified Access Management
Traditional bastion hosts require extensive firewall rules and public IPs. This setup eliminates the need for public IPs while providing similar functionality through IAP.

Prerequisites

Ensure the following prerequisites are met:

GCP Account: Access to a Google Cloud Platform project with billing enabled.
Terraform Installed: Installed on your local machine for infrastructure provisioning.
IAM Permissions: Sufficient IAM roles for creating VPCs, subnets, instances, and managing GKE clusters.
APIs Enabled:
- Compute Engine API (compute.googleapis.com)
- Kubernetes Engine API (container.googleapis.com)
- Cloud IAP API (iap.googleapis.com)

Terraform Configuration

Terraform automates the provisioning of resources in GCP. Below are the configuration steps.

2.1 VPC and Subnet Setup

Create a custom VPC with explicitly defined subnets for resource isolation:

resource "google_compute_network" "vpc_network" {
  name                    = "vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "vpc_subnetwork_a" {
  name                     = "subnet-a"
  region                   = "asia-south1"
  network                  = google_compute_network.vpc_network.name
  ip_cidr_range            = "10.0.1.0/24"
  private_ip_google_access = true
}

resource "google_compute_network" "vpc_network" {

name = "vpc"

auto_create_subnetworks = false

}

resource "google_compute_subnetwork" "vpc_subnetwork_a" {

name = "subnet-a"

region = "asia-south1"

network = google_compute_network.vpc_network.name

ip_cidr_range = "10.0.1.0/24"

private_ip_google_access = true

}

2.2 Jump Host Setup

Create a Jump Host with an internal IP for secure access:

resource "google_compute_address" "internal_ip_addr" {
  name         = "internal-ip"
  region       = "asia-south1"
  address_type = "INTERNAL"
  subnetwork   = google_compute_subnetwork.vpc_subnetwork_a.name
  address      = "10.0.1.7"
}
resource "google_compute_instance" "vm_instance" {
  name         = "jump-host"
  zone         = "asia-south1-a"
  machine_type = "e2-medium"
  
  network_interface {
    network    = google_compute_network.vpc_network.name
    subnetwork = google_compute_subnetwork.vpc_subnetwork_a.name
    network_ip = google_compute_address.internal_ip_addr.address
  }
}

resource "google_compute_address" "internal_ip_addr" {

name = "internal-ip"

region = "asia-south1"

address_type = "INTERNAL"

subnetwork = google_compute_subnetwork.vpc_subnetwork_a.name

address = "10.0.1.7"

}

resource "google_compute_instance" "vm_instance" {

name = "jump-host"

zone = "asia-south1-a"

machine_type = "e2-medium"

network_interface {

network = google_compute_network.vpc_network.name

subnetwork = google_compute_subnetwork.vpc_subnetwork_a.name

network_ip = google_compute_address.internal_ip_addr.address

}

2.3 Firewall Rule for SSH Access

Define firewall rules to allow SSH access via IAP:

resource "google_compute_firewall" "firewall_rules" {
  name    = "allow-ssh"
  network = google_compute_network.vpc_network.name

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["35.235.240.0/20"]  # IAP IP range
}

resource "google_compute_firewall" "firewall_rules" {

name = "allow-ssh"

network = google_compute_network.vpc_network.name

allow {

protocol = "tcp"

ports = ["22"]

}

source_ranges = ["35.235.240.0/20"] # IAP IP range

}

2.4 GKE Cluster Setup

Provision a GKE cluster with private nodes and Jump Host access:

resource "google_container_cluster" "primary" {
  name     = "my-gke-cluster"
  location = "asia-south1"
  network  = google_compute_network.vpc_network.name
  subnetwork = google_compute_subnetwork.vpc_subnetwork_a.name

  private_cluster_config {
    enable_private_endpoint = true
    enable_private_nodes    = true
    master_ipv4_cidr_block  = "10.13.0.0/28"
  }

  master_authorized_networks_config {
    cidr_blocks {
      cidr_block   = "10.0.1.7/32"  # Jump Host IP
      display_name = "jump-host"
    }
  }
}

resource "google_container_cluster" "primary" {

name = "my-gke-cluster"

location = "asia-south1"

network = google_compute_network.vpc_network.name

subnetwork = google_compute_subnetwork.vpc_subnetwork_a.name

private_cluster_config {

enable_private_endpoint = true

enable_private_nodes = true

master_ipv4_cidr_block = "10.13.0.0/28"

}

master_authorized_networks_config {

cidr_blocks {

cidr_block = "10.0.1.7/32" # Jump Host IP

display_name = "jump-host"

}

Identity-Aware Proxy (IAP) SSH Tunnel Setup

3.1 Grant IAP Role

Assign the roles/iap.tunnelResourceAccessor role to the user:

gcloud projects add-iam-policy-binding [PROJECT_ID] \
--member=user:[USER_EMAIL] \
--role=roles/iap.tunnelResourceAccessor

gcloud projects add-iam-policy-binding [PROJECT_ID] \

--member=user:[USER_EMAIL] \

--role=roles/iap.tunnelResourceAccessor

3.2 SSH Access via IAP

Use the following command to SSH into the Jump Host:

gcloud compute ssh jump-host \
--zone=asia-south1-a \
--tunnel-through-iap

gcloud compute ssh jump-host \

--zone=asia-south1-a \

--tunnel-through-iap

3.3 Access Jump Host via GCP Console

Alternatively, SSH into the Jump Host directly from the Google Cloud Console:

Navigate to Compute Engine > VM instances.
Locate the Jump Host and click the SSH button.

Accessing GKE Cluster

Once connected to the Jump Host, configure kubectl to interact with the private GKE cluster:

gcloud container clusters get-credentials my-gke-cluster --region asia-south1

1	gcloud container clusters get-credentials my-gke-cluster --region asia-south1

You can now deploy workloads or manage configurations using kubectl.

Advantages of This Setup

Enhanced Security

No Public IPs Required: Reduces exposure to external attacks.
Controlled Access: Only authorized users can connect.
Encrypted Communication: Secures data transmission.

2. Cost Efficiency

Reduced Egress Costs: Minimizes public internet data transfer.
Simplified Maintenance: Eliminates complex bastion host setups.

3. Improved Manageability

Centralized Access Management: IAM simplifies user permissions.
Seamless User Experience: Easy access via gcloud or console.

4. Compliance and Governance

Auditable Access Logs: IAP provides detailed user access logs.
Best Practice Alignment: Complies with modern cloud security standards.

Conclusion

This blog demonstrated the setup of a secure infrastructure using Terraform to provision a VPC, Jump Host, and GKE cluster, combined with IAP SSH tunneling for secure access. This architecture ensures security by minimizing public exposure while enabling seamless access for authorized users.

This setup provides a scalable, and secure way to access private resources in GCP, adhering to the best practices of modern cloud environments.

Drop a query if you have any questions regarding IAP SSH tunnel and we will get back to you quickly.

Making IT Networks Enterprise-ready – Cloud Management Services

Accelerated cloud migration
End-to-end view of the cloud environment

Get Started

About CloudThat

CloudThat is a leading provider of Cloud Training and Consulting services with a global presence in India, the USA, Asia, Europe, and Africa. Specializing in AWS, Microsoft Azure, GCP, VMware, Databricks, and more, the company serves mid-market and enterprise clients, offering comprehensive expertise in Cloud Migration, Data Platforms, DevOps, IoT, AI/ML, and more.

CloudThat is the first Indian Company to win the prestigious Microsoft Partner 2024 Award and is recognized as a top-tier partner with AWS and Microsoft, including the prestigious ‘Think Big’ partner award from AWS and the Microsoft Superstars FY 2023 award in Asia & India. Having trained 650k+ professionals in 500+ cloud certifications and completed 300+ consulting projects globally, CloudThat is an official AWS Advanced Consulting Partner, Microsoft Gold Partner, AWS Training Partner, AWS Migration Partner, AWS Data and Analytics Partner, AWS DevOps Competency Partner, AWS GenAI Competency Partner, Amazon QuickSight Service Delivery Partner, Amazon EKS Service Delivery Partner, AWS Microsoft Workload Partners, Amazon EC2 Service Delivery Partner, Amazon ECS Service Delivery Partner, AWS Glue Service Delivery Partner, Amazon Redshift Service Delivery Partner, AWS Control Tower Service Delivery Partner, AWS WAF Service Delivery Partner, Amazon CloudFront and many more.

To get started, go through our Consultancy page and Managed Services Package, CloudThat’s offerings.

FAQs

1. What is the purpose of using an IAP SSH tunnel in this setup?

ANS: – The Identity-Aware Proxy (IAP) SSH tunnel serves as a secure access mechanism for private resources in GCP. It eliminates the need for public IP addresses by allowing users to securely SSH into private instances through Google’s infrastructure. This reduces the risk of unauthorized access and simplifies firewall configurations by relying on IAP’s fine-grained access control and centralized authentication

2. Why is a Jump Host required for accessing private GKE clusters?

ANS: – A Jump Host acts as an intermediary between the user’s local machine and the private GKE cluster. Since the GKE cluster is in a private network without public IPs, the Jump Host provides a controlled access point within the same VPC. By combining the Jump Host with IAP SSH tunnelling, users can securely connect to the private network and manage the GKE cluster without exposing it to the internet. This enhances security and aligns with best practices for cloud infrastructure.