
Teleport
Federated Kubernetes Access with Trusted Clusters
- Version 15.x
- Version 14.x
- Version 13.x
- Version 12.x
- Older Versions
- 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
, andwest
. These are the names set incluster_name
setting in their configuration files. - The clusters
east
andwest
are Trusted Clusters formain
. - 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 loginUser'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 eastUser'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
andwest
. These are the names set incluster_name
setting in their configuration files. - The clusters
east
andwest
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 loginUser'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 eastUser's `kubeconfig` now contains the entry for the "east" Kubernetes
endpoint, i.e. `east.mytenant.teleport.sh`.