Privileged Access for Kubernetes Overview

Privileged Access for Kubernetes is the Kubernetes component of Twingate Identity Firewall. It puts the Twingate Gateway in front of a cluster’s API server, so every kubectl request carries the user’s Twingate identity and is authorized by native Kubernetes RBAC.

Use Privileged Access for Kubernetes to:

• Replace long-lived kubeconfig tokens and cloud CLI credentials (gcloud, aws eks, doctl) with the user’s Twingate identity.
• Keep the Kubernetes API server private, with no public endpoint.
• Write RBAC bindings against Twingate usernames and Groups synced from your identity provider.
• Give AI agents scoped, revocable cluster access with no cluster credential on the agent host.
• Audit every kubectl command and replay kubectl exec sessions.

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 Privileged Access for Kubernetes 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.

Requests flow from kubectl on the user’s device to the cluster in this order:

kubectl → Twingate Client → Connector → Twingate Gateway → Kubernetes API server

The Gateway impersonates the authenticated user against the API server, so Kubernetes RBAC and the Kubernetes audit log see the real identity.

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, writing them to stderr by default (the Gateway can also be configured to write them to a file) and tying each entry to the user identity. Admins can then export or store these logs.

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.

Identity sent to the cluster

For a user, the Gateway sends the following identity to the Kubernetes API server. Use these values as the subjects of your RoleBindings and ClusterRoleBindings.

Kubernetes also adds system:authenticated to every authenticated request. To check the identity a user presents, run kubectl auth whoami:

$ kubectl --context twingate-my-kubernetes-cluster auth whoami
ATTRIBUTE   VALUE
Username    jane.doe@example.com
Groups      [Everyone twingate:authenticated system:authenticated]

For the identity sent for AI agents and other Service Accounts, see AI Agent Access.

How to set it up

We recommend setting up Privileged Access via the Kubernetes Operator, which handles both the initial setup and ongoing updates. The setup has these steps:

• In the Admin Console, create a Remote Network for the cluster and note its ID.
• Create an API key with Read, Write & Provision permissions.
• Install the Twingate Kubernetes Operator with its Gateway subchart enabled, using Helm. The operator deploys the Gateway, registers it with Twingate, and creates a Kubernetes Cluster Resource for the cluster’s API server.
  Copy

  helm upgrade twop oci://ghcr.io/twingate/helmcharts/twingate-operator --install --wait -f ./values.yaml

• Deploy at least one Connector in the same Remote Network, for example with a TwingateConnector custom resource.
• In the Admin Console, grant users or Groups access to the Kubernetes Cluster Resource.
• Create Kubernetes RBAC bindings for those users or Groups (see Identity sent to the cluster).
• Users sync their kubeconfig in the Twingate Client, then confirm access with kubectl auth whoami.

The values.yaml contents, and the full steps with example output, are in the guides below:

See the Kubernetes Operator Identity Firewall user guide and the Gateway Kubernetes quick start guide.

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.

For detailed instructions on syncing kubeconfig, including headless and CI/CD usage, see Kubernetes Kubeconfig Sync.

Session Recording

Logs are written to stderr by default (the Gateway can also be configured to write them to a file) and can be streamed elsewhere. The logs are not uploaded to Twingate and are accessible only on your infrastructure.

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