* docs: Add instructions on uninstalling Teleport
* Add standalone RPM/DEB instructions and clarification for different OSes
* Language
* Suggestions from code review
* Add more specifics for Teleport Connect
* Address PR feedback
* Add a guide to writing an Access Request plugin
Closes#22227
This guide uses a minimal working example of an Access Request plugin to
demonstrate some of the key libraries that Teleport makes available to
plugin developers. The guide is based on a 270-line plugin that manages
Access Requests using Google Sheets.
* Respond to hugoShaka feedback
* Respond to zmb3 feedback
* Add some minor tweaks
- Update the line of code count in the demo program
- Mention Machine ID
* Respond to alexfornuto PR feedback
* Provide more context in the docs intro page
Closes#22469
The current docs landing page does not include enough context for new
readers. After the general description of Teleport, the rest of the
landing page is series of links, with little guidance for what a new
user should do first (or what an intermediate user should do after
completing the initial setup steps).
This change takes a more narrative approach to the landing page,
briefly describing the content of each top-level docs section and
putting it in context with the rest of the docs. This also helps users
find the right top-level docs section for their needs, since otherwise
the only way to do this is to visit each section.
This change is also more opinionated about which guide new users should
begin with. It recommends the guide to getting started with Teleport
Cloud, since this doesn't require setting up a Teleport cluster and
helps a user register a resource quickly.
The landing page links to the introduction page of each top-level docs
section. If a section does not have an introduction page, this change
adds one.
* Respond to zmb3 feedback
Reorder list items
* Linter fixes
* Respond to alexfornuto PR feedback
OSS Teleport supports access requests in a very limited fashion.
Make this clear by adding a separate page that covers the supported OSS
features.
Closes#4818Closes#13175Closes#14889Closes#15979Closes#22587
* tighten existing audit title in nav
* Move plugin install and config to partials
This move not only consolidates these instructions to a single source of
truth, but also takes the divergent updates from these instructions across
multiple docs.
* init datadog guide
* Update docs/pages/includes/configure-event-handler.mdx
Co-authored-by: Michael Wilson <mike@mdwn.dev>
* respond to review feedback
* add context for Logstash
* add context for Splunk
* update page titles
See https://github.com/gravitational/teleport/pull/21950/files\#r1110311232 for details
* Apply suggestions from code review
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* move link to next steps
* Apply suggestions from code review
* adjust prereqs
* Apply suggestions from code review
* Update docs/pages/management/export-audit-events/datadog.mdx
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* appease pointless linter rule
---------
Co-authored-by: Michael Wilson <mike@mdwn.dev>
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* SAML identity provider docs.
SAML IdP documentation has been added.
* formatting
* spelling
* Zac's and Roman's feedback.
* Valid config.json.
* Linting updates.
* usr Var component
Adding as a unique commit in case it's not desired
* align output with object name
* Roman's feedback, add in a section for disabling the IdP.
* copy edits
* SAML Grafana guide (#22545)
* init Grafana SAML guide
* respond to review feedback
* Correct entity provider to identity provider.
* Note that HSM is not currently supported.
* Fix link.
---------
Co-authored-by: alexfornuto <alex.fornuto@goteleport.com>
* Refresh the Access Controls menu
Closes#19933
- Changes the "Configure Access" menu item to "Manage Access"
- The Access Controls menu page was out of date, so I changed it to
reflect the current sequence of subsections. This more narrative
approach also puts each subsection in the context of a user's overall
Teleport setup.
* Respond to PR feedback
* Explain Kubernetes RBAC more comprehensively
Closes#18230
This change explains Teleport's RBAC system in relation to the Teleport
Kubernetes Service. The docs didn't leave me with a readily available
place to put this information, since explanations of Kubernetes-related
role fields are scattered in asides throughout various pages.
As a result, I have added a more comprehensive, focused explanation of
Teleport's Kubernetes RBAC system in two places:
- A new how-to guide for setting up Kubernetes RBAC with Teleport using
a local `minikube` cluster.
- A reference guide that explains the Kubernetes-related fields within a
Teleport role as well as the logic that the Kubernetes Service uses to
evaluate these fields. This replaces the existing Kubernetes Access
Controls guide.
To make room for the RBAC how-to guide, I've reorganized the other
guides into a logical sequence: enabling auto-discovery, manually
registering clusters, and setting up access controls.
I've also edited the Resource Access Requests guides to explain role
fields for the different resources you can restrict access to via
`search_as_roles`, including `pods`.
* Partially respond to PR feedback
- Add `kubernetes_labels` to example snippets
- Rename a misleading H5 in the Resource Requests guide
- Make the description of impersonation more accurate in the Access
Controls guide
- Move a Notice in the Access Controls guide
- Add an example role to the warning re: namespace restrictions in the
Access Controls guide
- Make resource filtering info more accurate in the CLI reference
* Change the RBAC how-to guide
Use Deployments in the demo cluster instead of Pods, showcasing the use
of regular expressions in per-pod RBAC.
This responds to PR feedback.
* Provide an example of internal traits
This responds to PR feedback
* Add notes about regex support
Responds to PR feedback
* Explain multiple values in labels
Responds to PR feedback
* Document progressively enabling access to pods
In response to PR feedback
* unbreak redirect
* copy edits
* more copy edits
* Respond to alexfornuto feedback
---------
Co-authored-by: alexfornuto <alex.fornuto@goteleport.com>
* rename manual to active directory manual
* rename getting started to active directory
* update titles and descriptions
* first draft of non-AD getting started
Note: I have images but did not yet include them in the commit history. No need to bloat the repo if those steps will be invalidated by a new installer
* update draft
* update links for new paths
* Update based on review feedback
* update config reference
* Apply suggestions from code review
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* post-review edits
* note non-AD as enterprise feature
* expand manual AD process adminition
* Apply suggestions from code review
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
* disable default services for Desktop node
* document cli access, clarify non-AD listing of hosts
* add join token for new node
* update screenshot for new UI
* copy edit...
Based on https://github.com/gravitational/teleport/pull/19311\#discussion_r1095187559
* name and link for windows exe
* Update download link
* note zip format
---------
Co-authored-by: Paul Gottschling <paul.gottschling@goteleport.com>
Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>
* helm: disbale PSPs on 1.23 and document PSA usage
In 1.25 Kubernetes removes PSP support, this has 2 consequences:
- Helm will break after upgrading if PSPs are deployed
- We cannot set security policies anymore
This commit documents those two behaviours and makes the chart disable
PSPs on 1.23 and higher to ensure a smooth upgrade path.
* helm: Remove stale 'migrate from legacy charts' guide
* Improve the Teleport Cloud Getting Started guide
While following the Teleport Enterprise Cloud Getting Started guide to
test v12, I made the following changes to the guide:
- Change the title of the guide--and language throughout our Cloud
docs--to use "Teleport Enterprise Cloud" instead of "Teleport Cloud".
This reflects the usage in our Core Concepts page.
- Add a brief architectural explanation to the guide in case users
arrive here from a search engine.
- Restructure the guide to include a step to start a local Docker
container. This way, we can (a) ensure that all steps are consistent
for all users; and (b) let the user get started quickly without "real"
infra.
- Include instructions to paste a script generated via Teleport Discover
into the container shell.
- Update screenshots.
* Respond to alexfornuto feedback
* Minor wording change
Responding to PR feedback
* Document Google Cloud CLI access
Closes#17584
- Add a guide to configuring and using Google Cloud CLI access via the
Teleport Application Service.
- Since we now have three guides to setting up secure access to cloud
APIs, create a new subsection of the "Application Access" docs section
related to cloud provider APIs.
* Respond to PR feedback
- Capitalize "JSON Web Tokens"
- Edit the AWS guide's nav bar entry
- Fix garbled section in the App Access intro page
- Improve the service account name we use in the how-to guide
- Clarify the way the App Service uses a service account
- Add new env vars to the `tsh proxy` command output
- Other small changes in response to suggestions/comments
* Edit instructions for starting the VM
Add instructions to launch a new VM with a service account attached.
This addresses feedback on the PR.
* Use more precise terminology for service accounts
This addresses feedback on the PR
* Add information about `tsh gsutil`
This adds to both the Google Cloud API access how-to guide and the CLI
reference.
* Respond to PR feedback
* use nobr tags
* fix multiline command
---------
Co-authored-by: alexfornuto <alex.fornuto@goteleport.com>
* Add device trust documentation
* Link to Device Trust from Access Control pages
* Document `device_trust` authentication section
* Document the `tsh device enroll` command
* Document `tctl devices` commands
* Review: Explain macOS restriction in text
* Review: Address Alex's comments
Indents, markdown style, code block style, punctuation and missing
words.
* Review: Use diff blocks on `tctl edit` example
* Review: Use diff blocks in other examples
* Review: Use standard example names
* Review: Address Alex's comments (2)
Uppercase SERIAL, macOS enroll notice, config example tabs.
* Review: Sort `tctl devices` commands alphabetically
* Review: Use config variables for asset_tag and enroll_token
* Review: Remove '#' from code blocks in cli.mdx
* combine warning and ScopedBlock
A ScopedBlock for OSS will never render on a page not scoped for OSS. This way, it's always visible. Once the feature is out of preview, we can just remove the first line.
* clarify device trust between trusted clusters
This addition dispells any assumptions made by the reader that applying device trust to root clusters would enforece the setting on leaf clusters.
* update enterprise tctl version output
---------
Co-authored-by: alexfornuto <alex.fornuto@goteleport.com>
The changes in #17405 added a section to the docs for guides to
exporting audit events, and moved guides from
`docs/pages/management/guides`, but failed to add redirects. This change
adds the missing redirects.
* Reorganize early-stage docs sections
Closes#18127
Currently, there are two sections of the docs related to the earliest
stages of setting up Teleport, "Try out Teleport" and "Deploy a
Cluster". While the organization of our top-level docs sections attempts
to correspond to the stages a user goes through when setting up
Teleport, these combine some tasks that should probably be separated:
- **Choosing an edition and deploying a production cluster**: While the
"Deploy a Cluster" section includes our deployment guides as well as
our edition guides, user will likely commit to setting up Teleport
Cloud, Open Source, or Enterprise before they plan a full HA
production deployment.
- **Deploying a production cluster and deploying a small-scale Teleport
cluster:** While the "Deploy a Cluster" section includes the Linux
Server and Digital Ocean 1-Click guides, these two guides are more for
small-scale deployments than full production clusters.
This change improves the early-stage docs experience for new Teleport
users by:
Splitting the "Deploy a Cluster" section
----------------------------------------
The "Deploy a Cluster" section includes subsections related to choosing
a Teleport edition as well as subsections related to deploying a
production cluster. The problem with this approach is that it leaves no
room for adding introductory guides to help users with these two
purposes.
By splitting the "Deploy a Cluster" section into two top-level sections,
one related to choosing an edition and the other to dpeloying to
production, we can add introductory pages that put the subsections of
these sections in context.
_This change accompanies the work on #16751 to write a general guide to
HA Teleport deployments, since the new guide will have a prominent
place in the reorganized "Deploy a Cluster" section._
Adding introductory pages
-------------------------
Sections related to getting started with Teleport, "Try out Teleport"
and "Deploy a Cluster", were missing introductory pages. This change
adds them, and also adds one to the new "Choose an Edition" section.
Moving the Linux Server and Digital Ocean guides
------------------------------------------------
Move these to "Try out Teleport". The Digital Ocean guide didn't fit
with the rest of the deployment guides, since it's not about
architecting an HA deployment.
This is also a better home for the "Linux Server" guide, so this change
moves that as well.
Removing the "getting-started.mdx" page
---------------------------------------
This page is not reachable via the navigation menu.
* Respond to PR feedback
* Respond to PR feedback
Also minor text tweaks
At one point, we had moved the Ansible Server Access guide to the
Machine ID section and added a redirect. Since we restored the Ansible
Server Access guide, the redirect is no longer correct.
* Add a guide to deploying an HA cluster
Closes#16751
This is a general guide that prefaces our HA deployment guides.
Also adds an introduction to the "deploy-a-cluster" section.
* Respond to some PR feedback
- Add mentions of specific services (Auth and Proxy) where it would help
with clarity.
- Edit port tables to remove ports that shouldn't be publicly exposed.
- Clarify the supported backends.
- Clarify that Let's Encrypt is not required for TLS credential
management.
* Respond to more PR feedback
- Add context around DNS records
- Use "Layer 4" instead of "Layer Four"
- Explain optional ports more explicitly
- Fix spacing issues
- Indicate that you can use an S3-compatible object store
- Clarify cert-fetching behavior for applications
- Describe separate port configs depending on whether TLS Routing is
enabled, and add a brief section re: whether to enable TLS Routing
- Expand the Teleport configuration section to accommodate TLS Routing
and separate listeners
* Add more context to the "Deploy a Cluster" intro
* Small language tweaks
* Add an image
* Respond to zmb3 feedback
- Use "cluster state backend" and "session recording backend"
- Mention cross-zone load balancing
- Link to the Backends Reference instead of including example backend
configurations
- Use v3 for example configs
- Fix example config indentation
* Add CTA for Teleport Cloud and forScopes
* Add a guide to exporting events to Splunk
Closes#13158
Since there are multiple guides to exporting audit events now, this also
adds a new section of the docs for these guides.
Also fixes a tiny error in the Elastic Stack guide.
* Respond to PR feedback
* Fix linter issues
* Respond to PR feedback
- Use consistent naming
- Mention the `--ttl` flag for `tctl auth sign`
- Mention Machine ID
- Add a quick Troubleshooting section
- Fix `chmod` command
- Add systemd configs (also added this to the Elastic Stack Event
Handler guide. I didn't do this to the Fluentd guide because the
structure of the guide is different from the Splunk guide's).
* Document Azure CLI access
Closes#17583
- Create a guide to Azure CLI access
- Update references to reflect changes to roles, commands, and the file
config
* Respond to alexfornuto feedback
* Add a section to the guide on `tsh proxy azure`
* Respond to smaller feedback items from Tener
* Switch the order of role approaches
Responds to one item of feedback from Tener.
* Respond to zmb3 feedback
* Document new behavior
- Wildcards in `deny` rules
- The `tsh proxy az` alias
* Add SSO instructions for defining a role
* Update env var values
* optimize images
Co-authored-by: alexfornuto <alex.fornuto@goteleport.com>
* Add a glossary of Teleport terms
Closes#16121Closes#13363
- Create a Core Concepts page based on the Architecture Overview page.
The Overview page is an outline of core concepts, so I thought it
would make a good starting point for the glossary.
- Add the Core Concepts page to the Home section to make it more
prominent for users who are visiting the docs homepage. This should
give it more traffic than leaving it in the Architecture section.
- Move definitions out of the "Definitions" table. Since this table
repeats content from the body sections and comes after them, it makes
sense to condense all content into brief body sections.
- Alphabetize sections
- Bold the first instance of each keyword within a given section. Not
adding links since these are all to the same page. It might get a bit
confusing to click a link and not see a change in view, since the
target section would already be on the page.
- Remove the intro paragraph of the old Overview page, since it's not
strictly related to core concepts.
* Respond to PR feedback and add further edits
- Group definitions into H3-level sections organized into H2s, improving
readability by presenting the more central components first.
- Group "Machine ID" with "Teleport Services" to simplify the glossary.
- Call instances of a Teleport Service an "agent". This is consistent
with our source and informal language about Teleport. This also
removes the "Node" terminology, which is prone to misuse (does it mean
"a Service instance"? An "SSH Service instance"? Both are present in
the docs) and easily confused with the lowercase "node" (i.e., a
host).
- For simplicity, remove the term "Teleport Process" and simply explain
that multiple Teleport Services can run via the same binary.
- Add a section on Teleport's editions, including the terms "Community
Edition", "Enterprise", and "Enterprise Cloud".
- Remove the mention of Teleport Discover, which isn't documented yet.
- Minor wording/readability changes.
* Respond to PR feedback
* Respond to zmb3 feedback
Russell Jones