Privileged access, finally built for Kubernetes & SSH.
Replace static SSH keys, kubeconfigs, and standing admin with short‑lived, audited access, all without changing how your engineers work.
Your identity is the perimeter. Treat it like one.
Kill standing access
Long‑lived SSH keys and kubeconfigs are hard to revoke and easy to steal. Twingate binds every session to identity and expires it in minutes, not months.
Audit every action
Every kubectl call and SSH session is tied to a real human and recorded, giving your team identity-specific forensics in seconds, not days.
Eliminate workflow tax
Engineers keep using `ssh` and `kubectl`. No bastion juggling, no custom CLIs, no jump hosts. Off‑boarding drops access globally in one click.
Stop sharing kubeconfigs.
Start shipping.
Twingate extends Zero Trust past the network connection into every kubectl verb, namespace, and resource. Available now, free for up to five resources.
~/twingate · privileged access
jane@laptop · ~
RECORDING
Your identity is the new SSH key.
Zero trust controls on every SSH session without keys, bastions, or custom tooling. Currently in early access, free for up to five resources.
No SSH keys on devices
Twingate authenticates the user, then issues a short‑lived certificate per connection. Nothing to distribute, nothing to leak, nothing to rotate.
Full session auditing
Every keystroke and command is attributed to a real identity. Recordings are stored in asciicast v2 on your infrastructure for replay and compliance.
Plain ssh, no new tools
Engineers connect with the standard ssh command. No custom CLI, no bastion choreography, no behavior change to roll out.
Instant offboarding
Revoke a user's Twingate access and all SSH access disappears in the same instant, across every host. No manual SSH server clean-up
Privileged Access · Web Apps
Internal web apps, identity all the way down.
Bring the same identity‑bound, fully audited model to your internal dashboards, admin panels, and HTTP APIs, all without navigating reverse proxies, fighting with VPNs, or deploying a single line of app code.
Coming soon
POST /admin/users/42/delete
PREVIEW
One control plane. Every privileged session.
1
User authenticates
Engineer signs in once via your IdP. Device posture, group, and context are evaluated continuously.
2
Gateway brokers identity
A Layer‑7 reverse proxy inside your environment receives the request, validates policy, and propagates the user's identity downstream.
3
Short‑lived cert issued
For SSH and Kubernetes, a per‑session certificate is minted with the precise scopes the policy allows.
4
Session is recorded
Activity streams to your storage in asciicast v2 — replayable, attributed, ready for audit and incident response.
Frequently Asked Questions
What is Twingate Identity Firewall, and how is it different from a traditional firewall?
Traditional firewalls control access based on network perimeters: IP addresses, ports, and rules that treat all users inside the boundary the same. Twingate Identity Firewall is a privileged access solution that operates at the application layer, extending Zero Trust controls to individual sessions. Identity Firewall introduces the Twingate Gateway, an open-source Layer 7 reverse proxy deployed within your environment. The Twingate Gateway enables identity propagation and session recording within those environments. Before any request hits your protected environment, Twingate authenticates the user and enforces access policies with no static credentials or separate authentication tokens required. Access is granted just-in-time, and permissions are automatically revoked when no longer needed. Every SSH command, Kubernetes API call, and database query is tied to a verified user identity, device posture, location, and context, giving you forensic-level visibility that perimeter security simply can't provide.
Will my developers have to change how they work?
No. Developers continue using standard tools and commands exactly as they do today. That means they can use standard ssh, kubectl, etc. without needing to learn a new custom CLI or workflow. Instead, Twingate handles authentication automatically and silently behind the scenes. Twingate Identity Firewall ensures access always reflects current group membership, that credentials are always fresh, and that the Twingate Gateway maintains its audit trail. This leads to additional benefits for developers, especially those working in Kubernetes. Twingate automatically syncs cluster access without any manual setup: when someone joins a team, their cluster access appears automatically, and when clusters are created or retired, everyone's configuration updates on its own. There are no more copied connection strings, no stale configs causing mysterious failures, and no cleanup required when infrastructure changes. Your team spends less time managing access and more time building.
How does Twingate handle SSH access without distributing SSH keys?
First off, why should you move away from traditional approaches like SSH key distribution or bastion hosts? If you’re going with manual key management, if you have to maintain authorized_key files across dozens or hundreds of servers, with no reliable way to know which keys are in use, you have both a security and administrative problem. Bastion hosts are a typical workaround, but they introduce a shared public endpoint that’s a high-value target (plus, double-hop connections frustrate developers). Instead of issuing long-lived SSH keys that get copied to devices and forgotten, Twingate issues short-lived certificates on a per-connection basis. In practice a developer runs ssh my-server.int. The Twingate Client routes the connection to a Gateway, a Layer 7 reverse proxy deployed in your environment. The Gateway verifies the user's identity against your IdP (including Okta, Entra ID, and Google Workspace), fetches a short-lived SSH certificate from the SSH CA, and authenticates to the target server. The user never touches a key.
How does Twingate Identity Firewall protect Kubernetes environments?
Twingate keeps your Kubernetes API servers completely private. That’s more than hiding behind IP allowlists or bastions. Twingate eliminates public internet exposure of your cluster APIs entirely. Instead, Twingate Connectors are deployed inside the cluster via Helm Chart, and internal services are mapped as Twingate Resources using private IPs or cluster-internal DNS. The Twingate Gateway acts as a Layer 7 reverse proxy that propagates verified user identities directly into the cluster, enabling native Kubernetes RBAC (ClusterRoleBindings/RoleBindings) to enforce least-privilege access per user rather than per shared credential. All commands and sessions are recorded for auditing, with logs staying on your own infrastructure. The same zero trust model that governs human access to Kubernetes clusters extends naturally to automated pipelines using Twingate Headless Clients. Pipeline jobs for tools like GitHub Actions and CircleCI can reach private Kubernetes API servers, run kubectl commands, verify deployments, or access any other protected resource, all without exposing those resources to the internet.
Where is session recording data stored? Does Twingate have access to it?
Twingate Identity Firewall stores session recordings on your own infrastructure in the open asciicast v2 format and never uploads them to Twingate. Your team retains full ownership and control of your audit data, with no dependency on Twingate's systems for storage or retrieval. For Kubernetes environments, logs are written to stdout and can be captured by your existing logging infrastructure. For SSH, session recordings capture terminal I/O for interactive shell sessions and command output. The Gateway also logs SSH events such as channel open and close, giving you a detailed record of session activity. From there, you can keep logs on your own infrastructure or sync them to SIEMs like Datadog or object storage like AWS S3 for long-term retention and compliance purposes. To visualize any session recording, use the Twingate session player at twingate.com/sessionplayer. Regardless of where you choose to store them, Twingate never has access to your session recordings.
How does this compare to traditional Privileged Access Management (PAM) tools?
Modern cloud PAM tools have improved on legacy appliances, but they typically operate as a separate access layer: one set of policies for privileged access and another for network access, with additional tooling and operational overhead to manage each. Costs scale quickly, and developers often have to adopt new CLI workflows specific to the individual PAM platform. Credentials are time-limited but often still span hours, leaving a window of exposure if a session is compromised. Comparatively, Twingate fuses network access and privileged access into a single solution governed by a single unified policy. Twingate can be deployed and managed programmatically via Terraform or the Twingate Kubernetes Operator. Identity propagates natively from your existing IdP, developers use the tools and commands they already know, and certificates are issued per-connection (not per-session) so there are no standing credentials to exploit.
Does Twingate Identity Firewall work with our existing identity provider?
Yes. Twingate works with your existing IdP. Twingate supports automatic user provisioning via SCIM 2.0, allowing seamless integration with your organization’s existing identity provider solution, whether that's Okta, Entra ID, Google Workspace, or others. Users authenticate once through the IdP they already use, and that identity is tied to each specific resource they access. There's no second login or separate credential store, and no disruption to your existing authentication workflows. Because Twingate operates on both the network and application layers, a single authentication grants users access to and into a specific resource. Access is just-in-time and revoked automatically when a user is offboarded from your IdP. For Kubernetes environments, this extends to cluster access as well. When a new user is onboarded, their cluster access appears automatically based on the permissions of their IdP user group, and is removed automatically when access policies or infrastructure change.
What protocols does Twingate Identity Firewall support?
Twingate Identity Firewall currently supports the Kubernetes API and SSH, two of the most widely used protocols for infrastructure access. Kubernetes API support means that cluster access is governed by the same identity-aware policies that control the rest of your network, ensuring that only the right people reach the right clusters at the right time. SSH support brings the same principles to server access, so every connection is authenticated, audited, and tied to a verified identity rather than a static key or credential. Additional protocol support is on the roadmap for later this year, including web applications over HTTP/HTTPS, database protocols, and MCP (Model Context Protocol) for remote AI server access. As coverage expands, teams will be able to apply consistent identity-based access controls across a broader range of resources without managing separate policies or tools for each protocol.