Set up a SSH+Kubernetes bastion for AWS EKS with Teleport 3.2

Apr 1, 2019 by Ev Kontsevoy

Today we are announcing the release 3.2 of Gravitational Teleport, the open source privileged access management (PAM) solution.

What is Teleport?

Teleport is a modern, cloud-native PAM, designed for distributed teams running applications on distributed infrastructure. This means that Teleport users can remotely access any servers or VMs of their organization, from any device, from any location, regardless with cloud a server is located in, including behind-NAT environments, without the need for VPN.

ssh kubernetes proxy

The hallmark features of Teleport are:

Feel free to watch this high level explainer video, demo video or read the docs for more information.

AWS EKS Bastion Host Support

The major new feature of this release is full support for Amazon Elastic Container Service for Kubernetes (AWS EKS). Prior to 3.2, Teleport has been relying on a CSR API to issue certificates for Kubernetes users. Unfortunately, EKS never supported CSR.

In this version, we are switching to the Impersonation API, which allows RBAC to be set up in a more fine-grained way allowing Teleport to only assume identities with limits, as shown in the example below:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: limited-impersonator
rules:
# Can impersonate the groups "developers" and "admins" only
- apiGroups: [""]
  resources: ["groups"]
  verbs: ["impersonate"]
  resourceNames: ["developers","admins"]

Why Support Bastions for AWS EKS?

Many of Teleport customers are using Kubernetes across multiple clouds, like AWS EKS, Google’s GKE and Microsoft’s AKS.

An average organization uses 5 different infrastructure form-factors today, and developers need to be productive across all of them. Yet, they face the following challenges:

Identity Fragmentation

Every public cloud provider wants its users to be locked into a provider’s IAM when using Kubernetes. Meanwhile, most users are already using and quite happy with identity providers of their choice (e.g. Auth0, Okta or NetIQ) and would like to continue doing so.

Teleport has been offering an elegant way to provide SSH access across all clouds to all approved employees, but with this release, we are finally extending these powerful features to all major Kubernetes vendors. This greatly reduces the operational overhead of managing access, allows customers to enforce compliance using a single pane of glass, and increases visibility into distributed infrastructure.

Compliance-friendly control plane

With many clusters across distributed infrastructure, there is a need to reduce the surface area of attack by avoiding exposure of the Kubernetes API directly to the internet and aggregating all access through a single highly available entry point (aka, a “Bastion” or “Jump Host”).

Teleport 3.2 makes it easy to achieve that by connecting all clusters using Teleport’s trusted clusters feature.

Also, with the 3.2 release, administrators gain additional controls to terminate idle long-running connections to the clusters, a feature required by customers going through compliance audits.

Upgrading

Teleport 3.2 is meant to be a drop-in replacement for the 3.x series. (If you’re not already using Teleport, you can download the open source edition or get a demo of Teleport Enterprise). However, if your Teleport cluster already has Kubernetes integration turned on, you will need to update /etc/teleport.yaml configuration file for the proxy service:

You can see the full list of changes in the CHANGELOG.

Get Teleport

Teleport gives you security best-practices out of the box for the privileged access management of your cloud-native infrastructure.

Learn More About Teleport