Skip to content

[v14] docs: Fix a couple of typos and reword scenario descriptions #33397

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
lsgunn-teleport merged 1 commit into from
Oct 17, 2023
Merged

[v14] docs: Fix a couple of typos and reword scenario descriptions #33397

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 15 additions & 13 deletions docs/pages/kubernetes-access/manage-access/federation.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -13,20 +13,20 @@ to federate trust across Kubernetes clusters.
<TabItem scope={["oss", "enterprise"]} label="Self-Hosted">

When multiple trusted clusters are present behind the Teleport Proxy Service, the
`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) will contain the
`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) contains the
Kubernetes API endpoint determined by the `<cluster>` argument to [tsh
login](../../reference/cli/tsh.mdx#tsh-login).

For example, consider the following setup:
For example, consider the following scenario:

- There are three Teleport/Kubernetes clusters: the root cluster named `main` and the leaf clusters
`east` and `west` specified in the `cluster_name` setting in each cluster's configuration file.
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 main Proxy Service is `main.example.com`.
- The DNS name of the root cluster Teleport Proxy Service is `main.example.com`.

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

```code
# Using login without arguments
Expand All @@ -46,19 +46,21 @@ $ tsh --proxy=main.example.com login east
<TabItem scope={["cloud","team"]} label="Cloud-Hosted">

When multiple trusted clusters are present behind the Teleport Proxy Service, the
`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) will contain the
Kubernetes API endpoint determined by the `<cluster>` argument to [tsh
login](../../reference/cli/tsh.mdx#tsh-login).
`kubeconfig` generated by [tsh login](../../reference/cli/tsh.mdx#tsh-login) contains the
Kubernetes API endpoint determined by the `<cluster>` argument to the [tsh
login](../../reference/cli/tsh.mdx#tsh-login) command.

For example, consider the following setup:
For example, consider the following scenario:

- There are two Teleport/Kubernetes clusters, `east` and `west`.
These are the names set in the `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`.
- 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 this command:
In this scenario, users usually log in using the following command:

```code
# Using login without arguments
Expand Down