Privileged Access for Kubernetes

Twingate Privileged Access for Kubernetes

Twingate Privileged Access for Kubernetes enables secure, auditable access to your most sensitive infrastructure with greater ease, visibility, and control. By extending Zero Trust principles beyond the initial network connection to include specific Kubernetes operations, Twingate Privileged Access for Kubernetes allows organizations to enforce least-privilege access at the application layer.

Built on Twingate’s core architecture, Privileged Access for Kubernetes leverages private networking to keep clusters hidden from the public internet. Access policies are defined using identity, device posture, and other contextual signals, providing a flexible and extensible foundation for access control across your Kubernetes environments.

Key Benefits

• Seamless Identity Propagation: Twingate passes user identity through to your Kubernetes clusters, eliminating the need for separate Kubernetes credentials.
• Streamlined User Experience: End users benefit from fewer authentication steps and more efficient workflows.
• Enhanced Security: DevOps and security teams gain complete end-to-end visibility from network-level access to in-cluster operations.
• Comprehensive Auditing: All user activity is logged and attributed to specific identities. Privileged Access supports session replay for full visibility into actions taken within the cluster.
• Simplified Policy Management: A unified policy engine governs both network and Kubernetes access, reducing management overhead and eliminating credential sprawl.

How It Works

Twingate Privileged Access for Kubernetes introduces a Twingate Gateway, an application-level (Layer 7) reverse proxy deployed within your environment. This Gateway enables identity propagation and session recording for Kubernetes interactions.

When a user connects, Twingate forwards their authenticated identity to the Kubernetes cluster. You can then configure Kubernetes RBAC using ClusterRoleBindings or RoleBindings to authorize user actions based on this identity.

The Twingate Gateway audits all end user actions and commands run on the cluster, exporting them via stdout and trying it to the user identity. Admins can then decide to export or store those logs for further processing and/or storage needs.

After setting up Privileged Access for Kubernetes via the Operator, you will have a new Resource in the Admin Console with the type Kubernetes Cluster. When viewing the Resource in the Admin Console, you will additionally see details specific to the Gateway.

How to set it up

We recommend setting up Privileged Access via the Kubernetes Operator, as it’s both the easiest way to set it up and to keep it updated.

See here for a link to our Kubernetes Operator and additionally here for information on the Gateway.

User configuration

After a user is given access to a Kubernetes Cluster Resource, they will need to sync the Kubernetes configuration file on their machine. This will set up the kubeconfig file on the machine, enabling access. Users can choose to sync a specific Resource, sync all Resources, or set up an auto-sync to keep the configuration updated.

Session Recording

Logs are automatically exported to stdout and can be streamed elsewhere. To note, the logs are not uploaded to Twingate and accessible solely on your infrastructure.

The logs are in Asciinema format and can be replayed via a standalone Twingate Asciinema web player (https://www.twingate.com/sessionplayer). You can either copy and paste the log or upload a file to replay the session.