How to Create a Private GKE Cluster Using gcloud

Use gcloud container clusters create-auto with the --enable-private-nodes and --enable-master-authorized-networks flags to provision a private Autopilot GKE cluster that isolates both the control plane and node VMs from the public internet.

The google/skills repository provides a production-hardened reference implementation for deploying secure Google Kubernetes Engine environments. According to the gke-cluster-creation SKILL.md, private clusters represent the recommended default for production workloads, ensuring that the Kubernetes API server and underlying node pools operate exclusively on internal Google Cloud networking unless explicitly exposed via authorized CIDR ranges.

Golden-Path Configuration Reference

The repository defines the recommended "golden path" for private cluster deployment in [skills/cloud/gke-cluster-creation/SKILL.md](https://github.com/google/skills/blob/main/skills/cloud/gke-cluster-creation/SKILL.md). The specific gcloud command implementation appears at lines 112-124, which specifies an Autopilot configuration with enablePrivateNodes set to true. This aligns with the YAML representation found in [skills/cloud/gke-golden-path/assets/golden-path-autopilot.yaml](https://github.com/google/skills/blob/main/skills/cloud/gke-golden-path/assets/golden-path-autopilot.yaml), where the privateClusterConfig block enforces private node requirements.

This configuration ensures that nodes do not receive external IP addresses and that access to the control plane requires explicit authorization through Master Authorized Networks.

Prerequisites and Variable Setup

Before executing the creation command, configure your environment with the target project and regional settings. The following variables align with the repository's standardized deployment pattern:

gcloud config set project YOUR_PROJECT_ID
REGION=us-central1
CLUSTER_NAME=my-private-gke-cluster
PROJECT_ID=YOUR_PROJECT_ID

Deploying the Private Cluster

The following command implements the golden-path settings documented in the source skill. It creates an Autopilot cluster with private nodes enabled, master authorized networks enforced, and DNS-based private endpoint access configured:

gcloud container clusters create-auto "$CLUSTER_NAME" \
  --region "$REGION" \
  --project "$PROJECT_ID" \
  --release-channel regular \
  --enable-private-nodes \
  --enable-master-authorized-networks \
  --enable-dns-access \
  --enable-secret-manager \
  --secret-manager-rotation-interval=120s \
  --scoped-rbs-bindings \
  --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER,STORAGE,POD,DEPLOYMENT,STATEFULSET,DAEMONSET,HPA,CADVISOR,KUBELET,DCGM \
  --quiet

Critical Security Flags Explained

Each flag in this command serves a specific security function within the private cluster architecture:

• --enable-private-nodes — Creates node pools that lack external IP addresses, forcing all outbound traffic through Cloud NAT or VPC-native networking.
• --enable-master-authorized-networks — Restricts access to the Kubernetes control plane to explicitly defined IPv4 CIDR ranges, preventing unauthorized internet-based API access.
• --enable-dns-access — Enables private DNS resolution for the cluster endpoint, allowing internal VPC networks to resolve the control plane address without exposing it to public DNS.
• --release-channel regular — Subscribes the cluster to the Regular release channel, ensuring stable access to security patches and GKE feature updates as validated by Google Cloud.

Restricting Control Plane Access

After initial creation, refine the security posture by specifying the exact IP ranges permitted to reach the Kubernetes API server. Update the master authorized networks using the clusters update subcommand:

gcloud container clusters update "$CLUSTER_NAME" \
  --region "$REGION" \
  --master-authorized-networks 203.0.113.0/24,198.51.100.0/24

This operation modifies the masterAuth configuration in the cluster resource, immediately enforcing network-level access control to the control plane endpoint.

Verifying Private Configuration

Confirm that the cluster operates in private mode by inspecting the privateClusterConfig field in the cluster metadata:

gcloud container clusters describe "$CLUSTER_NAME" \
  --region "$REGION" \
  --format=json | jq '.privateClusterConfig.enablePrivateNodes'

A return value of true indicates that the nodes operate without external IP addresses, while the presence of enablePrivateEndpoint or masterIpv4CidrBlock in the same output confirms the control plane isolation configuration defined in the SKILL.md specification.

Accessing the Private Cluster

Because the control plane endpoint resolves to an internal IP address within your VPC, standard public internet connectivity cannot reach the Kubernetes API. Establish connectivity through one of the following methods:

• Cloud Shell — Access from the Google Cloud Console, which resides within the Google network and can route to private endpoints.
• VPN or Interconnect — Establish private connectivity from on-premises environments or other VPC networks to reach the internal master endpoint.
• Bastion Host — Deploy a Compute Engine instance within the same VPC with IAP tunneling enabled, then proxy kubectl commands through that instance.

Once connected, retrieve credentials using:

gcloud container clusters get-credentials "$CLUSTER_NAME" --region "$REGION"

Summary

• Private nodes require the --enable-private-nodes flag to ensure GKE node VMs lack external IP addresses and route traffic exclusively through internal VPC networking.
• Master Authorized Networks enforce CIDR-based access control to the Kubernetes API server, specified via --enable-master-authorized-networks and updated post-creation with gcloud container clusters update.
• The golden-path template in google/skills recommends combining private nodes with --enable-dns-access for seamless internal resolution of the control plane endpoint.
• Verification relies on inspecting privateClusterConfig.enablePrivateNodes via the clusters describe command to confirm isolation from public networks.
• Connectivity requires Cloud Shell, VPN, or bastion hosts because the private control plane endpoint does not expose a publicly routable IP address.

Frequently Asked Questions

What distinguishes private nodes from a private endpoint in GKE?

Private nodes ensure that the virtual machines running your workloads do not have external IP addresses, routing all traffic through the VPC. A private endpoint restricts access to the Kubernetes control plane (API server) itself, making it resolvable only from within the VPC or authorized networks. The google/skills repository recommends enabling both (--enable-private-nodes and master authorized networks) for defense-in-depth security.

Can I migrate an existing public GKE cluster to use private nodes?

You cannot directly convert existing node pools from public to private. Migration requires creating a new node pool with --enable-private-nodes (or recreating the cluster), draining workloads from the public pool, and then deleting the old pool. The control plane endpoint can be privatized on existing clusters using gcloud container clusters update, but node-level privacy requires pool replacement.

What networking prerequisites must exist before creating a private cluster?

The VPC network must have Private Google Access enabled for the subnet where you deploy the cluster, allowing private nodes to reach Google APIs and services. If you require outbound internet access from private nodes, you must configure Cloud NAT in the same region. The repository's configuration assumes these networking foundations are in place as part of the landing zone.

How does the --release-channel regular flag affect private cluster operations?

The Regular release channel ensures that your private cluster receives automatic upgrades to stable GKE versions, including security patches for the control plane and node operating systems. This aligns with the production-hardened approach in the google/skills repository, which prioritizes security updates over rapid feature adoption for private/production workloads.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}