Federated Kubernetes Access with Trusted Clusters
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
For example, consider the following setup:
- There are three Teleport/Kubernetes clusters:
west. These are the names set in
cluster_namesetting in their configuration files.
- The clusters
westare Trusted Clusters for
- Users always authenticate against
mainbut use their certificates to access SSH nodes and the Kubernetes API in all three clusters.
- The DNS name of the main Proxy Service is
In this scenario, users usually log in using this command:
Using login without argumentstsh --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`.
Please use the latest version of Teleport Enterprise documentation.