Twingate Privileged Access for Kubernetes is Here: Zero Trust Security for the AI Era
Lior Rozner
•
Jun 25, 2025

The future of enterprise computing is being built on Kubernetes.
As organizations scale their AI initiatives and modernize their infrastructure, Kubernetes has become the backbone powering everything from general application development, to machine learning pipelines, to GPU-accelerated workloads.
But with this transformation comes a critical challenge: how do you secure access to these increasingly valuable and complex environments without slowing down your teams?
Today, we're excited to announce that Twingate Privileged Access for Kubernetes is available to test in Early Access. This represents a fundamental evolution in how organizations approach Kubernetes security: moving beyond network perimeters to provide identity-first access control directly within your clusters.
The Kubernetes Security Gap in AI-First Organizations
If you're running AI workloads, you understand the stakes:
Value is increasing: These aren't just dev environments anymore—they're business-critical assets with valuable data and expensive GPU resources.
Complexity is real: Security can't be an afterthought, but it also can't break workflows
Speed matters: In competitive markets, security friction is a competitive disadvantage
Yet traditional security approaches that rely on network segmentation and shared credentials create both friction and risk:
Double authentication friction: Users authenticate with your network security solution, then separately with Kubernetes using certificates, tokens, or service accounts
Credential sprawl: Developers share kubeconfig files, create overprivileged service accounts, or store long-lived secrets in insecure locations
Visibility blind spots: When actions can't be attributed to specific users, incident response becomes guesswork and knowledge sharing suffers
Compliance challenges: Auditors need detailed logs showing exactly who performed which actions within clusters
Identity-First Kubernetes Access: How It Works
Twingate Privileged Access for Kubernetes extends our Zero Trust Network Access platform deep into your clusters themselves. Instead of stopping at the network perimeter, we now seamlessly pass user identity all the way through to Kubernetes operations.
The Technical Architecture
Building on the Twingate Kubernetes Operator that many of you already use, Twingate Privileged Access for Kubernetes introduces an application-aware gateway that sits between your users and the Kubernetes API server. Here's how it works:
Unified Authentication: Users authenticate once through Twingate using your existing identity provider (Okta, Azure AD, etc.)
Identity Propagation: User identity is securely passed through to Kubernetes, eliminating the need for separate cluster credentials
Policy Enforcement: Twingate's comprehensive security policies (device posture, conditional access, time-based restrictions) apply to all cluster operations
Session Recording: Every kubectl command, API call, and cluster interaction is logged with full individual user attribution in asciinema format

The new Gateway acts as an application-aware proxy that propagates identity and logs all activity
Getting Started with Twingate Privileged Access for Kubernetes
If you're already using the Twingate Kubernetes Operator, you're ahead of the game. Twingate Privileged Access for Kubernetes builds directly on this foundation, so your existing configuration becomes the launchpad for richer security capabilities.
For new users, getting started is straightforward:
Deploy the Twingate Kubernetes Operator in your clusters
Configure your Kubernetes resources using familiar YAML objects or service annotations
Join the Early Access Program starting June 23rd to begin testing identity-aware access
The operator handles Connector deployment, resource discovery, and access configuration programmatically, integrating seamlessly with your existing CI/CD pipelines and infrastructure-as-code practices.
As always, you can find more information in our documentation.
New to Twingate? You can try out Twingate for free or request a personalized demo from our team.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Twingate Privileged Access for Kubernetes is Here: Zero Trust Security for the AI Era
Lior Rozner
•
Jun 25, 2025

The future of enterprise computing is being built on Kubernetes.
As organizations scale their AI initiatives and modernize their infrastructure, Kubernetes has become the backbone powering everything from general application development, to machine learning pipelines, to GPU-accelerated workloads.
But with this transformation comes a critical challenge: how do you secure access to these increasingly valuable and complex environments without slowing down your teams?
Today, we're excited to announce that Twingate Privileged Access for Kubernetes is available to test in Early Access. This represents a fundamental evolution in how organizations approach Kubernetes security: moving beyond network perimeters to provide identity-first access control directly within your clusters.
The Kubernetes Security Gap in AI-First Organizations
If you're running AI workloads, you understand the stakes:
Value is increasing: These aren't just dev environments anymore—they're business-critical assets with valuable data and expensive GPU resources.
Complexity is real: Security can't be an afterthought, but it also can't break workflows
Speed matters: In competitive markets, security friction is a competitive disadvantage
Yet traditional security approaches that rely on network segmentation and shared credentials create both friction and risk:
Double authentication friction: Users authenticate with your network security solution, then separately with Kubernetes using certificates, tokens, or service accounts
Credential sprawl: Developers share kubeconfig files, create overprivileged service accounts, or store long-lived secrets in insecure locations
Visibility blind spots: When actions can't be attributed to specific users, incident response becomes guesswork and knowledge sharing suffers
Compliance challenges: Auditors need detailed logs showing exactly who performed which actions within clusters
Identity-First Kubernetes Access: How It Works
Twingate Privileged Access for Kubernetes extends our Zero Trust Network Access platform deep into your clusters themselves. Instead of stopping at the network perimeter, we now seamlessly pass user identity all the way through to Kubernetes operations.
The Technical Architecture
Building on the Twingate Kubernetes Operator that many of you already use, Twingate Privileged Access for Kubernetes introduces an application-aware gateway that sits between your users and the Kubernetes API server. Here's how it works:
Unified Authentication: Users authenticate once through Twingate using your existing identity provider (Okta, Azure AD, etc.)
Identity Propagation: User identity is securely passed through to Kubernetes, eliminating the need for separate cluster credentials
Policy Enforcement: Twingate's comprehensive security policies (device posture, conditional access, time-based restrictions) apply to all cluster operations
Session Recording: Every kubectl command, API call, and cluster interaction is logged with full individual user attribution in asciinema format

The new Gateway acts as an application-aware proxy that propagates identity and logs all activity
Getting Started with Twingate Privileged Access for Kubernetes
If you're already using the Twingate Kubernetes Operator, you're ahead of the game. Twingate Privileged Access for Kubernetes builds directly on this foundation, so your existing configuration becomes the launchpad for richer security capabilities.
For new users, getting started is straightforward:
Deploy the Twingate Kubernetes Operator in your clusters
Configure your Kubernetes resources using familiar YAML objects or service annotations
Join the Early Access Program starting June 23rd to begin testing identity-aware access
The operator handles Connector deployment, resource discovery, and access configuration programmatically, integrating seamlessly with your existing CI/CD pipelines and infrastructure-as-code practices.
As always, you can find more information in our documentation.
New to Twingate? You can try out Twingate for free or request a personalized demo from our team.
Rapidly implement a modern Zero Trust network that is more secure and maintainable than VPNs.
Twingate Privileged Access for Kubernetes is Here: Zero Trust Security for the AI Era
Lior Rozner
•
Jun 25, 2025

The future of enterprise computing is being built on Kubernetes.
As organizations scale their AI initiatives and modernize their infrastructure, Kubernetes has become the backbone powering everything from general application development, to machine learning pipelines, to GPU-accelerated workloads.
But with this transformation comes a critical challenge: how do you secure access to these increasingly valuable and complex environments without slowing down your teams?
Today, we're excited to announce that Twingate Privileged Access for Kubernetes is available to test in Early Access. This represents a fundamental evolution in how organizations approach Kubernetes security: moving beyond network perimeters to provide identity-first access control directly within your clusters.
The Kubernetes Security Gap in AI-First Organizations
If you're running AI workloads, you understand the stakes:
Value is increasing: These aren't just dev environments anymore—they're business-critical assets with valuable data and expensive GPU resources.
Complexity is real: Security can't be an afterthought, but it also can't break workflows
Speed matters: In competitive markets, security friction is a competitive disadvantage
Yet traditional security approaches that rely on network segmentation and shared credentials create both friction and risk:
Double authentication friction: Users authenticate with your network security solution, then separately with Kubernetes using certificates, tokens, or service accounts
Credential sprawl: Developers share kubeconfig files, create overprivileged service accounts, or store long-lived secrets in insecure locations
Visibility blind spots: When actions can't be attributed to specific users, incident response becomes guesswork and knowledge sharing suffers
Compliance challenges: Auditors need detailed logs showing exactly who performed which actions within clusters
Identity-First Kubernetes Access: How It Works
Twingate Privileged Access for Kubernetes extends our Zero Trust Network Access platform deep into your clusters themselves. Instead of stopping at the network perimeter, we now seamlessly pass user identity all the way through to Kubernetes operations.
The Technical Architecture
Building on the Twingate Kubernetes Operator that many of you already use, Twingate Privileged Access for Kubernetes introduces an application-aware gateway that sits between your users and the Kubernetes API server. Here's how it works:
Unified Authentication: Users authenticate once through Twingate using your existing identity provider (Okta, Azure AD, etc.)
Identity Propagation: User identity is securely passed through to Kubernetes, eliminating the need for separate cluster credentials
Policy Enforcement: Twingate's comprehensive security policies (device posture, conditional access, time-based restrictions) apply to all cluster operations
Session Recording: Every kubectl command, API call, and cluster interaction is logged with full individual user attribution in asciinema format

The new Gateway acts as an application-aware proxy that propagates identity and logs all activity
Getting Started with Twingate Privileged Access for Kubernetes
If you're already using the Twingate Kubernetes Operator, you're ahead of the game. Twingate Privileged Access for Kubernetes builds directly on this foundation, so your existing configuration becomes the launchpad for richer security capabilities.
For new users, getting started is straightforward:
Deploy the Twingate Kubernetes Operator in your clusters
Configure your Kubernetes resources using familiar YAML objects or service annotations
Join the Early Access Program starting June 23rd to begin testing identity-aware access
The operator handles Connector deployment, resource discovery, and access configuration programmatically, integrating seamlessly with your existing CI/CD pipelines and infrastructure-as-code practices.
As always, you can find more information in our documentation.
New to Twingate? You can try out Twingate for free or request a personalized demo from our team.
Solutions
Solutions
The VPN replacement your workforce will love.
Solutions