Securely Access Private GKE Clusters Using Tinyproxy and Identity-Aware Proxy (IAP)

Introduction

Private clusters in Google Kubernetes Engine improve security by preventing public access to the Kubernetes control plane, but this also makes remote management more difficult.This step-by-step guide will walks you through how to configure Tinyproxy on a private bastion host and how to use Identity-Aware Proxy (IAP) to safely access a private GKE cluster without making the control plane accessible from the public internet.

What is Tinyproxy?

Tinyproxy is an open-source, lightweight HTTP/HTTPS proxy daemon that is meant to be fast, simple, and resource-efficient. It is ideal for minimal environments such as cloud bastion hosts.

Key Features of Tinyproxy

1. Ultra-lightweight footprint : Has a small CPU and memory footprint and works well on small GKE bastion virtual machines (like e2-micro).
2. HTTPS connect support : Allows you to securely tunnel your Kubernetes API communications from your local machine to a private GKE control plane.
3. Simple, single-file configuration : Easy to deploy and maintain as part of an automated bastion setup with a simple, single-file configuration.
4. IP Based access control : It is necessary to ensure that only traffic via trusted IAP tunnels is allowed by restricting proxy usage to localhost.
5. Header filtering functionality : It provides an additional layer of control over HTTP/S communications that are tunnelled.
6. Basic yet efficient logging : Light logging with low storage and performance costs is achieved.
7. Runs with least privilege permissions : It reduces risk on attack-resistant bastion hosts by running as a non-privileged user.
8. Ideal for private GKE clusters : Provides safe access to Kubectl without making the control plane visible to the public.
9. Works seamlessly with IAP tunnelling : This feature allows it to integrate with IAP tunnelling, providing secure and identity-based access and routing private networks without exposing services to the internet.
10. Minimal attack surface: Its design is simple, and it has only the basic features, making it suitable for cloud environments because it has minimal security vulnerabilities.

Enabling Secure Remote Access to a Private GKE Cluster –

One practical use case for Tinyproxy is providing remote access to a private GKE cluster using tinyproxy on a bastion host.In this architecture, Tinyproxy is deployed on a bastion VM located within the same VPC as a private Google Kubernetes Engine cluster with the public endpoint disabled.

The remote administrative access is implemented as follows :

1. Creation of an authenticated tunnel to the bastion host via Identity-Aware Proxy.
2. Routing of HTTPS Kubernetes API traffic via Tinyproxy.
3. Internal routing of requests to the private control plane endpoint.

Why Is This Approach Secure?

1. The Kubernetes API server is not exposed to the public.
2. There is no need to configure authorized networks.
3. Identity-based access control is implemented via IAM.
4. Low overhead on the bastion host.

How to Deploy Tinyproxy for Private GKE Access ?

Step 1: Create a Private GKE Cluster

Create a private Google Kubernetes Engine cluster that has no public endpoint access to the control plane.

While setting up the cluster:

• Enable the feature for private nodes so that worker nodes are not given public IPs.
• Enable the Private Control Plane to keep API communication internal.
• Disable public endpoint access completely.

Step 2: Create the Bastion Host

Deploy a private bastion server with in the same VPC as the Google Kubernetes Engine cluster.

• The bastion VM can be deployed in the same vpc and same subnet as the GKE cluster for networking ease.
• However, if bastion is in same vpc but in different subnet, make sure to add that subnet’s IP range to the cluster’s authorized networks so it can reach the control plane.
• The bastion server should not be given a public IP address.
• To allow the Identity Aware Proxy ,access to the bastion virtual machine, add a firewall rule.

Step 3: Set up the Bastion Host with Tinyproxy

To forward requests to cluster control plane, a proxy daemon needs to be installed on the bastion host after the private cluster and bastion host have been deployed.

1. Use IAP to establish a connection to the bastion server :

gcloud compute ssh INSTANCE_NAME \
--tunnel-through-iap \
--project=PROJECT_ID

2. Install the Tinyproxy :

sudo apt install tinyproxy

3. Open the configuration file :

sudo vi /etc/tinyproxy/tinyproxy.conf

4. Modify the config file :

• Ensure the port is set to 8888.
• Search for the Allow section:

  /Allow 127

• Add the following line:

  Allow localhost

5. Restart the Tinyproxy :

sudo service tinyproxy restart

Connect to the private cluster from your local machine

After setting up Tinyproxy ,configure the remote client with the proxy details and cluster credentials.

1. Obtain your private cluster credentials :

gcloud container clusters get-credentials CLUSTER_NAME \
--region=COMPUTE_REGION \
--project=PROJECT_ID

2. Set up the IAP tunnel for Bastion server :

gcloud compute ssh INSTANCE_NAME \
--tunnel-through-iap \
--project=PROJECT_ID \
--zone=COMPUTE_ZONE \
--ssh-flag="-4 -L8888:localhost:8888 -N -q -f"

Tunnel to the bastion host using IAP

3. Set up a proxy for your local machine :

export HTTPS_PROXY=localhost:8888

4. Verify the Access using the command.

kubectl get namespaces

Gke Cluster Access verification

If configured correctly, the request will securely goes through:
Local Machine → IAP Tunnel → Bastion Host → Tinyproxy → Private GKE Control Plane

Conclusion

To enable secure remote access to a private cluster in Google Kubernetes Engine, one must consider a design that is both secure and easy to manage. The use of Tinyproxy on a private bastion host with Identity-Aware Proxy (IAP) enables access to the Kubernetes control plane without making it accessible over the public internet. This design removes the need for public endpoints, static IP allowlists, and VPNs while still being able to control access based on identity and having low overhead. This makes for a secure, lightweight, and production-ready access pattern for private GKE clusters.