TL;DR: A quick comparison of four bastion-free ways to reach a private GKE control plane: the DNS-based endpoint, IAP tunnels, Connect Gateway, and a ZTNA approach with an in-cluster operator. See the GKE network isolation docs and Twingate's Kubernetes Operator.

Google quietly retired the "private clusters" concept page in GKE last year and replaced it with a broader network isolation guide. The new guidance recommends the DNS-based control plane endpoint as the default, and pitches it as a way to reach your cluster "without needing to configure proxies or bastion hosts."

That's accurate, but it's incomplete. The DNS-based endpoint is resolvable through public Google APIs by default. Anyone with valid IAM credentials can reach it from anywhere on the internet unless you add VPC Service Controls or an authorized networks list on top. For teams migrating away from bastions because they've been burned by exposed SSH, "the endpoint is public but gated by IAM" is an important architectural shift, and your team should spend some time thinking that through before you commit.

So let's walk through the actual options. Four approaches, three questions each: is the API server reachable from the internet, where does identity get enforced, and who holds the audit trail.

The four bastion-free options

Before the comparison, a quick definition of each.

DNS-based control plane endpoint. This is GKE's current default. The control plane gets a DNS name like gke-abc123.us-central1.gke.goog, and resolution and authentication happen through Google's public API fabric. There's no VPC peering, no proxy, and no bastion. Access is controlled by IAM and (optionally) VPC Service Controls.

IAP TCP tunnel to a jump VM. The Identity-Aware Proxy forwards TCP connections through Google's edge to a private VM inside your VPC. The VM has kubectl configured. You still have a jump host, it just isn't exposed to the public internet. Sometimes this is called "bastionless" but it's really "firewalled bastion."

Connect Gateway. A managed Google service that proxies kubectl requests to clusters registered in Fleet. Your laptop talks to connectgateway.googleapis.com, which forwards authenticated requests to the cluster's control plane over Google's internal network. Works for GKE, Anthos, and attached clusters.

ZTNA with an in-cluster operator. A Connector runs inside the cluster (or in the VPC) and dials outbound to a broker. Users authenticate via SSO, and kubectl traffic is tunneled to the private control plane endpoint. The API server stays fully private. Twingate's Kubernetes Operator is one implementation.

Comparison: the three questions that matter

The three questions aren't equally weighted for every team. If you're an all-in Google shop that already trusts Google's identity fabric and ships all logs to Cloud Logging, the DNS endpoint with VPC-SC on top is probably fine. If you're multi-cloud, running compliance frameworks that care about where session data lives, or trying to reduce the number of control planes your traffic passes through, the trade-offs look different.

Option 1: The DNS-based endpoint

This is Google's recommended path. It is genuinely simpler than anything that came before it. You get a DNS name, you authenticate with gcloud, and kubectl works from your laptop, from CI, from a Cloud Run job, basically anywhere with internet and the right IAM binding.

Enable it on an existing cluster:

Enabling the DNS-based endpoint on an existing GKE cluster:

Then configure kubectl:

Fetching cluster credentials using the DNS endpoint:

What's good: There's no bastion, no VPC peering, and it uses short-lived Google-issued credentials. It works from anywhere the operator is authorized.

What to watch: The endpoint resolves from the public internet. If a developer's gcloud session token leaks, or if an IAM binding is too generous, an attacker doesn't need to be inside your VPC to try their luck against the API server. Google recommends layering VPC Service Controls to restrict which networks can hit the endpoint, which closes the exposure but adds a chunk of configuration most teams don't have in place on day one.

Identity enforcement is Google IAM mapped to Kubernetes RBAC. Audit logs go to Google Cloud Audit Logs. If your SOC already ingests those, nothing new to wire up.

Option 2: IAP TCP tunnel to a jump VM

This is the pattern most teams used before DNS endpoints existed, and plenty still use it. You spin up a small private VM in the cluster's VPC, install kubectl, and reach it through IAP's TCP forwarding.

Starting an IAP SSH session to a private jump VM:

The API server itself can stay fully private, with no public endpoint, no authorized networks, and nothing exposed. IAP handles the ingress and enforces IAM at the connection layer.

What's good: The API server is actually private. Google enforces IAM before any TCP bytes reach your VPC. Audit trail is clean in Cloud Audit Logs.

What to watch: You still have a VM. Patch it, monitor it, lock it down. If a user gets access to the jump box, they inherit whatever kubectl context lives there, which is often cluster-admin because nobody wants to manage multiple contexts on a shared VM. IAP solves the ingress problem, not the "shared admin credentials on a Linux box" problem.

Option 3: Connect Gateway

Connect Gateway is Google's answer for teams managing multiple clusters across Fleet, including non-GKE ones. Register the cluster, grant IAM roles, and kubectl requests flow through Google's managed proxy to the control plane.

Registering a cluster with Fleet and using the gateway:

What's good: The API server can stay private. It works across GKE, Anthos, and attached clusters with the same kubectl endpoint pattern for all of them. Google handles the plumbing.

What to watch: Your identity is impersonated into a Kubernetes user by Google's proxy. That's fine, but it means the authorization chain now includes Google's gateway as a translation layer between your IdP and native RBAC. And like the DNS endpoint, the gateway address is a public Google API. IAM gates access, but the endpoint itself is reachable from anywhere. Audit logs are Google's.

Option 4: ZTNA with an in-cluster operator

This is where the architecture meaningfully diverges. Instead of exposing the cluster through a Google-fronted endpoint, a Twingate Connector runs inside the cluster and dials outbound to a broker. You don't need to fiddle with inbound firewall rules, and the need for a public public endpoint or a jump VM are eliminated.

With Twingate's Kubernetes Operator, you deploy the Connector via Helm and register the cluster's API server as a Resource. Users authenticate once through your IdP, and kubectl traffic is proxied to the private control plane over an outbound-only tunnel.

Installing the Twingate Kubernetes Operator with Helm:

Once the operator is running, it reconciles TwingateResource and TwingateConnector CRDs. Register the API server:

Declaring the GKE API server as a Twingate Resource:

A few things worth calling out about this model:

The API server is not reachable from the public internet. Not by IAM, not by DNS resolution, not through a Google-managed proxy. The cluster's control plane endpoint stays private, and the Connector reaches it from inside the VPC. External access requires an authenticated session to the Twingate network first, then the Connector verifies the ACL independently before forwarding the connection.

User identity passes through to Kubernetes RBAC. Twingate handles authentication (who are you, do you have a valid session, does your device meet posture requirements). It does not replace Kubernetes authorization. Your existing RBAC rules, Workload Identity bindings, and namespace-scoped roles continue to apply exactly as they do today. The user hitting the API server is the user your RBAC rules already know about.

Gateway session logs stay on your infrastructure. When you use Twingate's Identity Firewall product with session recording for Kubernetes, the recorded sessions are stored where you deploy the Gateway, not shipped to Twingate. For teams with data residency requirements or compliance frameworks that get nervous about session recordings sitting in a vendor's cloud, this is the differentiator.

What to watch: You're adding a component. The Connector runs as a workload in your cluster or VPC, and like anything else, it needs to be deployed with HA (2+ replicas is the recommendation) and kept updated. It's less operational overhead than a bastion VM, but it's not zero.

So which one do you actually pick

The honest answer: depends on how much of your stack already lives in Google's identity fabric and how much you trust public endpoints gated by IAM.

If you're a GKE-only shop, your developers already live in gcloud, and you're comfortable layering VPC Service Controls, the DNS-based endpoint is probably enough. Google's guidance is reasonable for that profile.

If you have a mix of clusters (GKE, EKS, self-managed, on-prem), or if you want the API server to be architecturally unreachable from the internet rather than "reachable but authenticated," the in-cluster operator pattern gives you one access model across all of them. The user flow is the same whether the cluster is in GCP, AWS, or a colo.

If you're in a regulated industry and your compliance team reads session logs, look carefully at where those logs physically live under each option. Google Cloud Audit Logs are fine for a lot of use cases. They're not fine for all of them.

The common thread: none of these require a bastion. The bastion was always a workaround for the fact that your API server was somewhere you couldn't reach. Fix that problem the right way, and the bastion disappears whether you choose Google's managed path or a ZTNA overlay.

Closing

For more on deploying the Twingate Kubernetes Operator and registering cluster resources, see the Kubernetes Operator documentation and the Identity Firewall overview.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.