We're excited to announce the upcoming launch of Twingate Kubernetes Access, an evolution of the Twingate platform that takes Kubernetes security beyond the network perimeter and into your clusters themselves. 

We're developing this capability as an open-source project, and to help gather more feedback we're opening an Early Access Program for customers who want to get involved to help shape the future of Kubernetes security at Twingate.

Providing richer access controls into Kubernetes is a natural evolution of the Twingate platform. We already secure network access to your infrastructure, and moving deeper into the application layer allows us to follow zero trust principles from initial connection all the way through to specific cluster operations.

Why Kubernetes?

Kubernetes has become the de-facto standard for enterprise container orchestration, and this popularity makes it an attractive target for bad actors.

Even more significant, it's rapidly emerging as the backbone for how companies build and deliver AI-powered applications and run their infrastructure. 

As organizations build increasingly sophisticated AI pipelines, Kubernetes provides the scalable, resilient infrastructure needed to handle varied AI workloads, ranging from model training and inference services to distributed computing jobs and GPU-accelerated tasks.

The computational resources that power AI workloads make these clusters particularly attractive targets for attackers seeking to hijack processing power or access sensitive training data. 

If your clusters remain hidden from the public internet, that risk is significantly reduced - attackers aren't able to even find a surface to attempt to exploit.

As a connectivity layer for your Kubernetes clusters, Twingate already keeps your clusters secure by hiding them on private networks, and our extensible access policies based on identity, device posture, and other contextual signals provide extensible and flexible access controls for your Kubernetes environment.

Twingate's approach keeps your clusters protected from exposure, but until now it left a gap: once users reach the "front door" of your Kubernetes cluster, they still need to authenticate separately to gain access inside.

The Identity Challenge in Kubernetes

Currently, users authenticate with Twingate to reach your Kubernetes API server, then have to re-authenticate using Kubernetes credentials—typically through separate certificate-based authentication, service accounts, or token-based methods. 

This double authentication introduces friction for your team and can lead to security risks when developers inevitably look for shortcuts to maintain productivity by sharing kubeconfig files, granting over-permissive access, or storing long-lived secrets in insecure locations.

When we first began exploring expanding Twingate’s Kubernetes capabilities, we focused on a number of specific recurring challenges tied to identity in Kubernetes environments:

• Managing separate sets of credentials for network and Kubernetes access

• Creating and maintaining a separate identity system just for Kubernetes

• Dealing with the operational overhead of keeping Kubernetes authentication methods in sync with your company’s identity provider

• Losing visibility into which specific users performed which actions inside the cluster

That last bullet was of particular interest. If you don’t know who is doing what within your cluster, you can’t pinpoint the source of both good and bad behavior.

If you know that a specific engineer is a Kubernetes wizard, a lack of identity data makes it a slog to find their specific session recordings to use for knowledge sharing and training.

On the flip side, when misconfigurations or bugs can’t be easily and directly attributed to a specific user, risk mitigation and corrective training become much more difficult unless someone proactively fesses up.

Identity-First Kubernetes Access

Instead of stopping at the network level, Twingate now passes user identity seamlessly to your Kubernetes cluster, extending identity from network access all the way through to cluster operations.

For your end users, this means:

• One authentication step instead of two

• No more managing separate Kubernetes credentials

• A smoother, more productive workflow

For DevOps and security teams, this provides:

• Complete identity context from network to cluster activities

• End-to-end audit logging that attributes cluster actions to specific users

• Comprehensive session recording and logs available in ASCII NEMA format that you can plug into your preferred ASCII NEMA viewer

• Simplified management through a single policy engine

• Elimination of credential sprawl and associated security risks

It also means you’re able to go beyond simple identity verification and extend Twingate’s robust Security Policies all the way through to clusters themselves.

These security policies are comprehensive and allow you to apply powerful and granular controls including:

• Identity context: Ensuring users are who they claim to be through your existing identity provider

• Device posture: Verifying devices meet security requirements before granting access

• Dynamic policy enforcement: Automatically adjusting access based on real-time conditions like date, time, and usage

Built on the Twingate Kubernetes Operator

This new capability builds upon the Twingate Kubernetes Operator that many of you are already using. 

The Operator—which previously focused on managing Twingate's network access functionality within Kubernetes—will now serve as the foundation for this enhanced identity-aware access control.

This allows you to bake network and application-layer access management directly into the Kubernetes workflow, meaning access policies can be defined, applied, and removed automatically as part of your standard Kubernetes operations.

Twingate Kubernetes Access in Action

We’ve loved seeing how customers are using Twingate with Kubernetes and the use cases these new capabilities enable. Some of the exciting use cases we’re seeing from our early design partners include:

• AI Model Training on GPU Clusters: Provide engineers and data scientists secure access to GPU resources from anywhere without exposing these high-value assets to the internet, with access policies that adjust automatically based on workload priority.

• On-Call Production Debugging with Just-in-Time Access: Grant temporary elevated access to production environment clusters for on-call engineers, eliminating persistent admin credentials while maintaining rapid incident response.

• Security Incident Investigation with Full Session Recording: Streamline incident response with session recordings tied directly to individual identities, so that you can immediately see which commands were run, by whom, and when.

…and more! 

Join the Early Access Program

We're building Twingate Kubernetes Access with your needs in mind, and we're taking a community-driven approach to its development.

Here's how to get started:

1. First step: Get started with our Kubernetes Operator, which will serve as the engine powering Twingate Kubernetes Access

2. Next: Sign up for our Early Access Program to be among the first to test and provide feedback

Your feedback and community insights will be instrumental in shaping this product to better meet real-world needs.