Teleport becomes the universal gateway for SSH and Kubernetes with v3.0

Oct 2, 2018 by Ev Kontsevoy

Today we are bumping the major version number of Gravitational Teleport to 3.0 and for good reason. One of our beta testing customers said it best:

This is too easy, now I can now authenticate once and access both my Kubernetes clusters [via kubectl] and the underlying servers [via SSH]!

That’s right, in addition to being an SSH gateway, Teleport now has native support for Kubernetes. Before we cover this feature in greater detail, let’s introduce Teleport to the new readers of this blog.

What is Teleport?

Teleport is a privileged access management system for elastic (and now Kubernetes) compute infrastructure.

Teleport delivers hardened DevOps & SRE security best practices in a box to companies who have traditionally relied on static keys or complex DIY SSH bastion solutions.

By adopting Teleport in your organization you will:

Teleport allows low-level systems access to be controlled by who the user is within an organization, not based on which private key they have.

Teleport is open source and compatible with OpenSSH clients and servers.

Kubernetes Support

With the 3.0 release, Teleport can be configured as a compliance gateway for Kubernetes clusters. This allows users to authenticate against a Teleport proxy using the tsh login command and retrieve credentials for both SSH and the Kubernetes API:


In the scenario illustrated above a user can execute the following command to log into Teleport:

# Authentication step to retrieve the certificates. tsh login places the SSH
# certificate into `~/.tsh` as usual and updates kubeconfig with Kubernetes
# credentials:
$ tsh login

They then receive the certificates that determine their access and permissions for both SSH and Kubernetes:

# Execute SSH commands to access SSH nodes:
$ tsh ssh [email protected]

# Execute any kubectl commands to access the Kubernetes cluster:
$ kubectl get pods

In other words, a Teleport Proxy can now become a single authentication endpoint for both SSH and Kubernetes. This brings the following advantages to Teleport users:

Better compliance

The unified authentication and audit logging for both SSH and Kubernetes is not merely a convenience feature. It also gives organizations a simple way to reason about their infrastructure security and a single gateway to enforce compliance across traditional and newer, cloud native infrastructure management tools.

Often “compliance enforcement” initiatives bring a fair amount of disruption and inconveniences to day-to-day operations, making it harder for engineers to do their jobs. Teleport, however, stays true to its promise of getting out of the way. Developers can continue to enjoy using familiar commands like ssh and kubectl without having to worry about bastion hosts and complicated authentication mechanisms. This reduces the incentives to go around compliance policies.

How does it work?

When a user executes the tsh login command, they specify a Teleport proxy which asks the Teleport auth server to authenticate (usually via corporate SSO) and issue an SSH certificate which is returned to the user.

The SSH certificate is later used to implement end-to-end encryption between a user and an SSH node.

The Kubernetes integration is turned off by default but when turned on, the Teleport auth service also retrieves a Kubernetes certificate using the Kubernetes CSR API which is kept in memory for the user’s session.

When a user issues the kubectl exec command, it is sent to a Teleport proxy, which updates the audit log and performs the recording of interacive sessions, and user requests are forwarded to the Kubernetes endpoint using the previously issued certificate.

You can dig deeper by taking a look at the relevant sections in the architecture document and the admin manual.

Here is a quick 3 minute demo of the end user’s experience.

Other Improvements

As usual, the full list of improvements and bugfixes can be found on Github.

You can also glance at the CHANGELOG for a quick overview. A few improvements are worth mentioning here:

Upgrading Teleport

Warning: if you are using the etcd backend for Teleport, you must make sure your etcd version is 3.0 or newer prior to upgrading. Teleport 3.0 drops the legacy (v2.x) etcd API support.

As usual, we recommend familiarizing yourself with the recommended upgrade procedure before upgrading to this version.

Additional Information

We are having a live webinar this Thursday 10/04/2018 to talk more about Teleport 3.0 and go through a live demo. You can also take a look at our friendly quickstart documentation or the Teleport overview. Our source code and developer community is wide open, so feel free to dig in. Issues and/or pull requests are always welcome. Also, feel free to reach out via email if you’d like a demo or would like to connect directly with the team: [email protected].

Did you enjoy this post?

Check out how our products can help your company: