-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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.
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
Convert the Trusted Clusters guide to a tutorial (and edit for different scopes) #10708
Conversation
df22110
to
6c015cc
Compare
6c015cc
to
506b5f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
df50c14
to
68236c8
Compare
8795dac
to
9f70eed
Compare
2a9b39c
to
ba32aa6
Compare
3166c27
to
0054cce
Compare
|
||
## Introduction | ||
If you have a large number of devices on different networks, such as managed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the criteria for using tunneling is "a large number of devices."
Technically, node tunneling consumes more resources than direct dial, so your cluster would better handle a large number of devices if you did not use tunneling.
I would recommend we reword this so that networking is the main driver for tunneling.
Something like:
If your nodes are deployed behind a firewall or otherwise not reachable by the Teleport Proxy Service, you can connect your nodes via Teleport Node Tunneling. Instead of connection to the Auth Service directly, ...
## How Trusted Clusters work | ||
|
||
Teleport can partition compute infrastructure into multiple clusters. A cluster | ||
is a group of Teleport SSH Nodes connected to the cluster's Auth Service, which |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is a group of Teleport SSH Nodes connected to the cluster's Auth Service, which | |
is a group of Teleport resources connected to the cluster's Auth Service, which |
Not sure of term (resources, agents, etc), but let's be clear that a cluster is more than SSH nodes and an Auth Service.
- Tries to find a local role that maps to the list of principals found in the certificate. | ||
- Checks if the local role allows the requested identity (UNIX login) to have access. | ||
- Checks if the local role allows the requested identity (Unix login) to have access. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: in the PRs I've reviewed today, we've used all of these interchangeably:
- Unix login
- OS login
- Host login
Should we standardize on a term here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure we need to have a standard for this unless this is a Teleport-specific technical term. We use logins
in user/role resource definitions, but the docs also sometimes use the term outside of that context. I'll add it to my list of possible topics to include in a style guide.
0054cce
to
dc417d1
Compare
7019b0e
to
451f720
Compare
d49b6c4
to
c4964c6
Compare
Since I need to audit this guide to complete #11841 and this PR has only received one review, I am going to use this branch to make my changes. Turning this into a draft PR until I finish this work. |
c4964c6
to
be1cc1e
Compare
ed92701
to
300b93e
Compare
300b93e
to
4da03a4
Compare
4da03a4
to
782e81f
Compare
See #10633 - Misc style/grammar/clarity tweaks - Turn the Teleport Node Tunneling Admonition into a Details box so it can be invisible for Cloud users. In Cloud, Nodes must connect via Node Tunneling. - Use Tabs components to add Cloud versions of CLI commands - Only show the static join token method for self-hosted users via Tabs - Use a Details box to show content relevant only for Enterprise and Cloud users - Remove an Admonition that was duplicated in the Troubleshooting section
See: #11841 The Trusted Clusters guide is organized as a conceptual introduction, with configuration/command snippets used as illustrations. To make this guide easier to follow, I have structured it as a step-by-step tutorial where a user should be able to copy each command/config snippet on their own environment, establish trust between clusters, and connect to a remote Node. Some more specific changes: - Remove Details box re: Node Tunneling: This isn't strictly relevant to Trusted Clusters, so removing it shortens and simplifies what is quite a long guide. - Make "How Trusted Clusters work" more concise and add the information to the introduction. - Move long explanatory passages into Details boxes. Eventually, it would be great to split this guide into multiple guides that explain different topics in more depth (e.g., a section of the docs devoted to Trusted Clusters). For now, this is the quickest way to organize conceptual information without detracting from the tutorial structure.
782e81f
to
1ba5103
Compare
Backports #10708 * Edit the Trusted Clusters guide for Cloud See #10633 - Misc style/grammar/clarity tweaks - Turn the Teleport Node Tunneling Admonition into a Details box so it can be invisible for Cloud users. In Cloud, Nodes must connect via Node Tunneling. - Use Tabs components to add Cloud versions of CLI commands - Only show the static join token method for self-hosted users via Tabs - Use a Details box to show content relevant only for Enterprise and Cloud users - Remove an Admonition that was duplicated in the Troubleshooting section * Respond to PR feedback * Address PR feedback * Turn the Trusted Clusters guide into a tutorial See: #11841 The Trusted Clusters guide is organized as a conceptual introduction, with configuration/command snippets used as illustrations. To make this guide easier to follow, I have structured it as a step-by-step tutorial where a user should be able to copy each command/config snippet on their own environment, establish trust between clusters, and connect to a remote Node. Some more specific changes: - Remove Details box re: Node Tunneling: This isn't strictly relevant to Trusted Clusters, so removing it shortens and simplifies what is quite a long guide. - Make "How Trusted Clusters work" more concise and add the information to the introduction. - Move long explanatory passages into Details boxes. Eventually, it would be great to split this guide into multiple guides that explain different topics in more depth (e.g., a section of the docs devoted to Trusted Clusters). For now, this is the quickest way to organize conceptual information without detracting from the tutorial structure.
Backports #10708 * Edit the Trusted Clusters guide for Cloud See #10633 - Misc style/grammar/clarity tweaks - Turn the Teleport Node Tunneling Admonition into a Details box so it can be invisible for Cloud users. In Cloud, Nodes must connect via Node Tunneling. - Use Tabs components to add Cloud versions of CLI commands - Only show the static join token method for self-hosted users via Tabs - Use a Details box to show content relevant only for Enterprise and Cloud users - Remove an Admonition that was duplicated in the Troubleshooting section * Respond to PR feedback * Address PR feedback * Turn the Trusted Clusters guide into a tutorial See: #11841 The Trusted Clusters guide is organized as a conceptual introduction, with configuration/command snippets used as illustrations. To make this guide easier to follow, I have structured it as a step-by-step tutorial where a user should be able to copy each command/config snippet on their own environment, establish trust between clusters, and connect to a remote Node. Some more specific changes: - Remove Details box re: Node Tunneling: This isn't strictly relevant to Trusted Clusters, so removing it shortens and simplifies what is quite a long guide. - Make "How Trusted Clusters work" more concise and add the information to the introduction. - Move long explanatory passages into Details boxes. Eventually, it would be great to split this guide into multiple guides that explain different topics in more depth (e.g., a section of the docs devoted to Trusted Clusters). For now, this is the quickest way to organize conceptual information without detracting from the tutorial structure.
Convert the Trusted Clusters guide to a tutorial Backports #10708 * Edit the Trusted Clusters guide for Cloud See #10633 - Misc style/grammar/clarity tweaks - Turn the Teleport Node Tunneling Admonition into a Details box so it can be invisible for Cloud users. In Cloud, Nodes must connect via Node Tunneling. - Use Tabs components to add Cloud versions of CLI commands - Only show the static join token method for self-hosted users via Tabs - Use a Details box to show content relevant only for Enterprise and Cloud users - Remove an Admonition that was duplicated in the Troubleshooting section * Respond to PR feedback * Address PR feedback * Turn the Trusted Clusters guide into a tutorial See: #11841 The Trusted Clusters guide is organized as a conceptual introduction, with configuration/command snippets used as illustrations. To make this guide easier to follow, I have structured it as a step-by-step tutorial where a user should be able to copy each command/config snippet on their own environment, establish trust between clusters, and connect to a remote Node. Some more specific changes: - Remove Details box re: Node Tunneling: This isn't strictly relevant to Trusted Clusters, so removing it shortens and simplifies what is quite a long guide. - Make "How Trusted Clusters work" more concise and add the information to the introduction. - Move long explanatory passages into Details boxes. Eventually, it would be great to split this guide into multiple guides that explain different topics in more depth (e.g., a section of the docs devoted to Trusted Clusters). For now, this is the quickest way to organize conceptual information without detracting from the tutorial structure.
* Edit the Trusted Clusters guide for Cloud See #10633 - Misc style/grammar/clarity tweaks - Turn the Teleport Node Tunneling Admonition into a Details box so it can be invisible for Cloud users. In Cloud, Nodes must connect via Node Tunneling. - Use Tabs components to add Cloud versions of CLI commands - Only show the static join token method for self-hosted users via Tabs - Use a Details box to show content relevant only for Enterprise and Cloud users - Remove an Admonition that was duplicated in the Troubleshooting section * Respond to PR feedback * Address PR feedback * Turn the Trusted Clusters guide into a tutorial See: #11841 The Trusted Clusters guide is organized as a conceptual introduction, with configuration/command snippets used as illustrations. To make this guide easier to follow, I have structured it as a step-by-step tutorial where a user should be able to copy each command/config snippet on their own environment, establish trust between clusters, and connect to a remote Node. Some more specific changes: - Remove Details box re: Node Tunneling: This isn't strictly relevant to Trusted Clusters, so removing it shortens and simplifies what is quite a long guide. - Make "How Trusted Clusters work" more concise and add the information to the introduction. - Move long explanatory passages into Details boxes. Eventually, it would be great to split this guide into multiple guides that explain different topics in more depth (e.g., a section of the docs devoted to Trusted Clusters). For now, this is the quickest way to organize conceptual information without detracting from the tutorial structure.
See #10633
box so it can be invisible for Cloud users. In Cloud, Nodes
must connect via Node Tunneling.
via Tabs
and Cloud users
section