Teleport 15 Unveiled: Elevating Access and Security Across Infrastructure
Feb 21
Virtual
Register Today
Teleport logoTry For Free
Fork me on GitHub

Teleport

Federated Kubernetes Access with Trusted Clusters

  • 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 contains the Kubernetes API endpoint determined by the <cluster> argument to tsh login.

For example, consider the following scenario:

  • There are three Teleport/Kubernetes clusters: the root cluster named main and the leaf clusters named east and west in the cluster_name setting for each cluster.
  • The clusters east and west trust the main root cluster certificate authority.
  • 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 root cluster Teleport Proxy Service is main.example.com.

In this scenario, users usually log in using the following 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 contains the Kubernetes API endpoint determined by the <cluster> argument to the tsh login command.

For example, consider the following scenario:

  • There are two Teleport/Kubernetes clusters named east and west. Each cluster has its own configuration file with its name specified in the cluster_name field.
  • The clusters east and west are leaf clusters that trust a Teleport Team or Enterprise Cloud account, for example, 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 the following 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