Downloads
Sign In

Sign in to Teleport

Teleport Cloud LoginLogin to your Teleport AccountDashboard LoginLegacy Login & Teleport Enterprise Downloads
Get Started
Fork me on GitHub

Teleport

Federated Kubernetes Access with Trusted Clusters

Version 14.x
  • Available for:
  • OpenSource
  • Team
  • Cloud
  • Enterprise

There are cases when you have Kubernetes clusters that have to operate independently, for example, they are part of a different organization or have intermittent connectivity.

You can take advantage of Trusted Clusters to federate trust across Kubernetes clusters.

When multiple Trusted Clusters are present behind the Teleport Proxy Service, the kubeconfig generated by tsh login will contain the Kubernetes API endpoint determined by the <cluster> argument to tsh login.

For example, consider the following setup:

  • There are three Teleport/Kubernetes clusters: main, east, and west. These are the names set in cluster_name setting in their configuration files.
  • The clusters east and west are Trusted Clusters for main.
  • Users always authenticate against main but use their certificates to access SSH nodes and the Kubernetes API in all three clusters.
  • The DNS name of the main Proxy Service is main.example.com.

In this scenario, users usually log in using this command:

Using login without arguments
tsh --proxy=main.example.com login

User's `kubeconfig` now contains one entry for the main Kubernetes
endpoint, i.e. `main.example.com`.

Receive a certificate for "east":
tsh --proxy=main.example.com login east

User's `kubeconfig` now contains the entry for the "east" Kubernetes
endpoint, i.e. `east.main.example.com`.

When multiple Trusted Clusters are present behind the Teleport Proxy Service, the kubeconfig generated by tsh login will contain the Kubernetes API endpoint determined by the <cluster> argument to tsh login.

For example, consider the following setup:

  • There are two Teleport/Kubernetes clusters, east and west. These are the names set in cluster_name setting in their configuration files.
  • The clusters east and west are Trusted Clusters for a Teleport Team or Enterprise Cloud tenant, mytenant.teleport.sh.
  • Users always authenticate against mytenant.teleport.sh but use their certificates to access SSH nodes and the Kubernetes API in all three clusters.

In this scenario, users usually log in using this command:

Using login without arguments
tsh --proxy=mytenant.teleport.sh login

User's `kubeconfig` now contains one entry for the main Kubernetes
endpoint, i.e. `mytenant.teleport.sh`.

Receive a certificate for "east":
tsh --proxy=mytenant.teleport.sh login east

User's `kubeconfig` now contains the entry for the "east" Kubernetes
endpoint, i.e. `east.mytenant.teleport.sh`.
0