There are several reasons to isolate your Google Kubernetes Engine (GKE) clusters from internet access, the primary one being security. For many financial, government, and similar institutions this is a must to run their workloads on Google Cloud Platform (GCP).

This post will walk through the steps needed to stand up an isolated GKE cluster in a network that blocks any access to the internet.

TL;DR

Create VPC and subnets for GKE cluster with private Google access enabled Lock down VPC with firewall rules blocking egress to 0.0.0.0/0, allowing ingress from Google health checks, and allowing egress to Google health checks, restricted APIs, and GKE private master ranges. Remove default route automatically created in VPC (0.0.0.0/0 with default internet gateway as next hop). Create route to reach Google restricted APIs (199.36.153.4/30) through a default internet gateway Make the following Cloud DNS changes and attach the zones to the VPC:

Create private DNS zone googleapis.com with a CNAME record to restricted.googleapis.com for *.googleapis.com and A record to 199.36.153.4/30 for restricted.googleapis.com

Create private DNS zone gcr.io with a CNAME record to gcr.io for *.gcr.io and A record to 199.36.153.4/30 for a blank gcr.io DNS name

5. Create GKE cluster with private nodes and private master

The Environment

Step by Step Deployment

Terraform Code Available Below

1. Create the VPC and Subnets

Before we create any clusters, there needs to be a VPC and subnets in the environment to use for the cluster. There are three subnets that go into each cluster:

Node Range: The GKE worker nodes live on this subnet

Cluster Range: GKE takes this range and divides it among the nodes. By default each node gets a /24 from this range, but that can be customized by using flex pod CIDR.

Services Range: This is used for cluster IP services running within the cluster

The cluster and services ranges are configured as secondary ranges to the node primary range. The secondary ranges are used to configure alias IP’s on the cluster, which makes for a better SDN integration. Using alias IP subnets is recommended over other methods of deployment for these reasons.