# Setting Up Private GKE Clusters with Master Authorized Networks: A Production Security Guide

> Secure your GKE clusters by setting up private clusters with Master Authorized Networks. Restrict API access and enhance security for production environments.

- Repository: [Google/skills](https://github.com/google/skills)
- Tags: how-to-guide
- Published: 2026-08-09

---

**Private GKE clusters with Master Authorized Networks (MAN) restrict Kubernetes API access to specific CIDR ranges while ensuring nodes communicate with the control plane exclusively over internal VPC traffic, eliminating public exposure of cluster endpoints.**

Google Kubernetes Engine (GKE) provides a hardened configuration where nodes run without external IP addresses and the control plane is locked down to an explicit whitelist of trusted networks. This architecture—implemented through **Master Authorized Networks**—is the security standard documented in the `google/skills` repository for production-grade container workloads. By combining VPC-native networking with strict CIDR-based access controls, you can isolate sensitive workloads from the public internet while maintaining operational connectivity to Google Cloud APIs.

## How Master Authorized Networks Work in Private GKE

Master Authorized Networks creates a zero-trust perimeter around your cluster's control plane. When you enable this feature, the Kubernetes API server rejects any request originating from IP addresses outside your configured CIDR blocks, even if the request presents valid credentials.

The architecture relies on four key components documented in [`skills/cloud/gke-networking/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-networking/SKILL.md):

- **Private Nodes**: Nodes receive only RFC 1918 internal IP addresses and communicate with the master through VPC peering, never traversing the public internet.
- **Private Endpoint**: When enabled alongside MAN, the control plane receives an internal IP address in your VPC, and the public endpoint is disabled entirely.
- **VPC-Native Routing**: IP aliasing (Alias IPs) assigns Pods and Services dedicated CIDR ranges inside your VPC, required for private cluster operation.
- **Private Google Access**: Allows nodes without external IPs to reach Google APIs (Container Registry, Cloud Logging, Monitoring) through Google's private backbone.

According to [`skills/cloud/gke-golden-path/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-golden-path/SKILL.md), this configuration ensures that all traffic between your worker nodes and the Kubernetes API stays within your network boundary, while the master API surface is exposed only to specific bastion hosts, corporate networks, or management proxies you designate.

## Prerequisites and Network Architecture

Before deploying, your VPC infrastructure must support private connectivity. The `google/skills` repository outlines a five-step architecture that forms the foundation for secure cluster operation.

1. **Create a custom VPC network** with a dedicated subnet for the cluster (e.g., `10.0.0.0/14`).
2. **Reserve CIDR blocks** for your management networks—these will become your Master Authorized Networks (e.g., `203.0.113.0/24` for your office VPN).
3. **Enable Private Google Access** on the subnet to allow nodes to reach Google services without external IPs.
4. **Provision the private cluster** using `gcloud` with IP aliasing, private nodes, and MAN enabled.
5. **Deploy Cloud NAT** (optional) if workloads require outbound internet access for package downloads or third-party APIs.

The subnet configuration in [`skills/cloud/gke-basics/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-basics/SKILL.md) emphasizes that Private Google Access is mandatory; without it, nodes cannot pull images from Google Artifact Registry or report logs to Cloud Logging.

## Implementation: Creating a Private GKE Cluster with MAN

The following `gcloud` commands implement the architecture described in [`skills/cloud/gke-networking/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-networking/SKILL.md). Replace placeholder values (`[PROJECT]`, `[REGION]`) with your environment specifics.

First, create the VPC infrastructure with Private Google Access enabled:

```bash
gcloud compute networks create my-vpc \
    --subnet-mode=custom

gcloud compute networks subnets create my-subnet \
    --network=my-vpc \
    --region=us-central1 \
    --range=10.0.0.0/14 \
    --enable-private-ip-google-access

```

Next, deploy the private cluster with Master Authorized Networks configured:

```bash
gcloud container clusters create my-private-cluster \
    --project=[PROJECT] \
    --region=us-central1 \
    --network=my-vpc \
    --subnetwork=my-subnet \
    --enable-ip-alias \
    --enable-private-nodes \
    --enable-private-endpoint \
    --master-authorized-networks=203.0.113.0/24 \
    --no-enable-basic-auth \
    --no-issue-client-certificate

```

**Critical flag explanations:**
- `--enable-ip-alias`: Activates VPC-native routing (Alias IPs), a prerequisite for private clusters as noted in [`skills/cloud/gke-basics/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-basics/SKILL.md).
- `--enable-private-nodes`: Assigns nodes only internal IP addresses; they cannot be reached from or reach the internet directly.
- `--enable-private-endpoint`: Provisions the Kubernetes master with an internal IP address and disables the public endpoint, forcing all API traffic through your VPC.
- `--master-authorized-networks`: The CIDR whitelist that defines which networks may reach the master API.
- `--no-enable-basic-auth` and `--no-issue-client-certificate`: Disables legacy authentication methods, enforcing IAM-based access as recommended in [`skills/cloud/gke-productionize/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-productionize/SKILL.md).

## Verification and Connectivity Testing

Validate that Master Authorized Networks is active by inspecting the cluster configuration:

```bash
gcloud container clusters describe my-private-cluster \
    --region=us-central1 \
    --format="value(masterAuthorizedNetworksConfig.cidrBlocks)"

```

The output should display your authorized CIDR (e.g., `203.0.113.0/24`). If you enabled the private endpoint, verify that the master IP is internal to your VPC:

```bash
gcloud container clusters describe my-private-cluster \
    --region=us-central1 \
    --format="value(privateClusterConfig.privateEndpoint)"

```

Access the cluster from a workstation within the authorized CIDR range:

```bash
kubectl get nodes

```

If you attempt to connect from an unauthorized IP, the connection will timeout or receive a connection refused error, confirming that MAN is enforcing the network boundary.

## Outbound Internet Access with Cloud NAT

Private nodes have no external IP addresses. If your workloads require egress to the internet (for example, to pull public container images or call external APIs), deploy Cloud NAT as documented in [`skills/cloud/gke-networking/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-networking/SKILL.md):

```bash
gcloud compute routers create nat-router \
    --network=my-vpc \
    --region=us-central1

gcloud compute routers nats create nat-config \
    --router=nat-router \
    --region=us-central1 \
    --auto-allocate-nat-external-ips \
    --nat-all-subnet-ip-ranges

```

This configuration allows outbound connections while maintaining the inbound security of private nodes and the Master Authorized Networks restriction.

## Summary

- **Master Authorized Networks** restricts Kubernetes API access to specific CIDR blocks, creating a network-level security boundary for private GKE clusters.
- **Private nodes** and **private endpoints** ensure that both node-to-master and client-to-master traffic remains within your VPC, eliminating public internet exposure.
- **VPC-native networking** (IP aliasing) is mandatory for private clusters, providing routable Pod CIDRs inside your VPC.
- **Private Google Access** allows nodes without external IPs to reach Google Cloud services, while **Cloud NAT** provides optional outbound internet connectivity.
- Reference implementations in [`skills/cloud/gke-golden-path/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-golden-path/SKILL.md) and [`skills/cloud/gke-networking/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-networking/SKILL.md) provide production-ready patterns for this architecture.

## Frequently Asked Questions

### What is the difference between private nodes and private endpoint in GKE?

**Private nodes** configures worker nodes to use only internal IP addresses, preventing direct internet access. **Private endpoint** provisions the Kubernetes master with an internal IP and disables the public API server endpoint. According to [`skills/cloud/gke-networking/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-networking/SKILL.md), you should enable both for maximum security, though private nodes can technically operate with a public endpoint restricted by Master Authorized Networks.

### Can I use Master Authorized Networks with a public cluster endpoint?

Yes, but this is less secure than using a private endpoint. When the public endpoint is enabled, `--master-authorized-networks` whitelists specific CIDR blocks that may reach the public IP of the master. However, the API remains exposed to the internet (filtered by IP). [`skills/cloud/gke-golden-path/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-golden-path/SKILL.md) recommends disabling the public endpoint entirely (`--enable-private-endpoint`) and using authorized networks to restrict access to your bastion hosts or management proxies.

### How do I update the authorized CIDR blocks after cluster creation?

You can modify Master Authorized Networks using the `gcloud container clusters update` command. For example, to add an additional office network: `gcloud container clusters update CLUSTER_NAME --master-authorized-networks=203.0.113.0/24,198.51.100.0/24`. Changes take effect immediately without disrupting existing connections from authorized sources.

### Why is VPC-Native (IP aliasing) required for private GKE clusters?

VPC-Native clusters use Alias IPs to assign Pod CIDRs that are routable within your VPC. This is required because private nodes must communicate with the master through internal VPC networking paths. As documented in [`skills/cloud/gke-basics/SKILL.md`](https://github.com/google/skills/blob/main/skills/cloud/gke-basics/SKILL.md), routes-based networking (legacy mode) does not support the internal routing requirements of private clusters, making `--enable-ip-alias` mandatory.