docs: zta doc fixes (#67347)

2026-10-11 22:49:54 +00:00 · 2026-06-02 00:00:59 +00:00
parent 440092e800
commit db12103126
14 changed files with 20 additions and 20 deletions
@@ -139,7 +139,7 @@ spec:
  allow:
    join_sessions:
      - name: Join prod sessions
-        roles : ['prod-access']
+        roles: ['prod-access']
        kinds: ['k8s', 'ssh']
        modes: ['moderator', 'observer']
 ```
@@ -41,7 +41,7 @@ and uses it to complete the original command.

 ## Prerequisites

- A Teleport Cloud cloud or a self-hosted cluster with WebAuthn configured.
+- A Teleport Cloud or a self-hosted cluster with WebAuthn configured.

 <details>
 <summary>Enable WebAuthn</summary>
@@ -53,7 +53,7 @@ spec:
  allow:
    join_sessions:
      - name: Join prod sessions
-        roles : ['prod-access']
+        roles: ['prod-access']
        kinds: ['k8s', 'ssh']
        modes: ['moderator', 'observer']
 ```
@@ -216,7 +216,7 @@ device and `tsh` binary should show the following output:

 ```code
 $ tsh webauthnwin diag
-# WebauthWin available: true
+# WebauthnWin available: true
 # Compile support: true
 # DLL API version: 4
 # Has platform UV: true
@@ -159,7 +159,7 @@ $ tsh ssh [email protected]
 # [email protected] >
 ```

-But when Jerry logs into node `rod3.example.com` (with label `env: prod` as login `jerry`), he
+But when Jerry logs into node `prod3.example.com` (with label `env: prod` as login `jerry`), he
 gets prompted for an MFA check:

 ```code
@@ -116,7 +116,7 @@ Device "(=devicetrust.asset_tag=)"/macOS registered and enrolled
 <Admonition type="tip" title="self enrollment">
  The `--current-device` flag tells `tsh` to enroll the current device. The user must have the preset `editor`
  or `device-admin` role to be able to self-enroll their device. For users without the `editor` or
-  `device-admin` roles, a device admin must generate the an enrollment token, which can then be
+  `device-admin` roles, a device admin must generate the enrollment token, which can then be
  used to enroll the device. Learn more about manual device enrollment in the
  [device management guide](./device-management.mdx#register-a-trusted-device).
 </Admonition>
@@ -138,14 +138,14 @@ Change the following settings, as appropriate:
 - jamf_service.client_id

 Finally, write your Jamf client secret to the
-`/var/lib/teleport/jamf_client_secret` file:
+`/var/lib/teleport/jamf_client_secret.txt` file:

 ```code
-$ sudo nano /var/lib/teleport/jamf_client_secret # or use your favorite editor
+$ sudo nano /var/lib/teleport/jamf_client_secret.txt # or use your favorite editor

 # Only the OS user that runs `teleport` should have access to the secret file.
-$ sudo chmod 400 /var/lib/teleport/jamf_client_secret
-$ sudo chown teleport /var/lib/teleport/jamf_client_secret
+$ sudo chmod 400 /var/lib/teleport/jamf_client_secret.txt
+$ sudo chown teleport /var/lib/teleport/jamf_client_secret.txt
 ```

 ## Step 3/4. Create a join token
@@ -157,7 +157,7 @@ Log into the Teleport Agent server and run the following commands.
       forward_agent: false
       max_session_ttl: 24h0m0s
       port_forwarding: true
-      ssh_file_copy: true
+       ssh_file_copy: true
   version: v7
   ```

@@ -402,7 +402,7 @@ This step describes the sequence of actions you will take in the event that you
   ```

   <Admonition type="note">
-   We use `sudo -u teleport-breakglass ssh` here because the outputted certificates and files in the `/opt/teleport-breakglass-output` directory
+   We use `sudo -u teleport-breakglass ssh` here because the outputted certificates and files in the `/opt/teleport-breakglass/output` directory
   are only readable by the `teleport-breakglass` user and `root`, to improve security.
   </Admonition>

@@ -43,7 +43,7 @@ following order:
   All components will stop trusting the old CA and only trust the new CA.

 Before the final `standby` phase, you can also put the rotation in the
-`rollback` phase to abort the rotation return to the original certificate
+`rollback` phase to abort the rotation and return to the original certificate
 authority. After the `rollback` phase you will then proceed to the `standby`
 phase.

@@ -351,7 +351,7 @@ the `/.well-known/openid-configuration` path of the Web UI and reading the

 ```code
 $ curl https://example.teleport.sh/.well-known/openid-configuration | jq '.jwks_uri'
-"https://example.teleport.sh/.well-known-jwks-oidc"
+"https://example.teleport.sh/.well-known/jwks-oidc"
 ```

 ### `spiffe`
@@ -93,7 +93,7 @@ spec:
          deny: 1
 ```

-The `spec.allow.request.roles` field lists the names of other roles that a user with the `reviewee` role can request. When a reviewee requests access to one of these roles, Teleport notifies reviewers via your access plugins. The `spec.allow.requests.roles.thresholds` field indicates how many reviews are required to approve or deny the request.
+The `spec.allow.request.roles` field lists the names of other roles that a user with the `reviewee` role can request. When a reviewee requests access to one of these roles, Teleport notifies reviewers via your access plugins. The `spec.allow.request.roles.thresholds` field indicates how many reviews are required to approve or deny the request.

 ## Automatically prevent some roles from requesting others
 A malicious Teleport user could request a more privileged role and trick a reviewer into granting access. You can prevent such a scenario by defining roles that prohibit users from even requesting access to particular roles.
@@ -57,7 +57,7 @@ following guidelines:
 - Avoid allowing `sudo` in production environments unless it's necessary.
 - Secure all Teleport executables so that they can't be modified or replaced.
 - Secure Teleport configuration files so that they can't be modified or replaced.
- Ensure the users' client `~/.tsh` directory is secure and should not be copied. If a user's `tsh` client 
+- Ensure the user's client `~/.tsh` directory is secure and should not be copied. If a user's `tsh` client 
  is compromised, it could result in a compromise of that user.

 ## Prevent access to storage
@@ -29,7 +29,7 @@ Teleport locks allow you to permanently or temporarily revoke access to a number
 of different "targets". Supported lock targets include: specific users, roles,
 servers, desktops, or MFA devices. For Machine & Workload Identity bots, this
 additionally includes the join token name (for delegated join methods) and the
-bot instance UUID. After you create a lock, all existing sessions where the loc
+bot instance UUID. After you create a lock, all existing sessions where the lock
 applies are terminated and new sessions are rejected while the lock remains in
 force.

@@ -286,10 +286,10 @@ host server every one hour.

 1. Save your changes and close the file.

-1. Start Teleport with the invitation token you saved in the `INVITE_TOKEN` environment variable:
+1. Start Teleport with the invitation token you saved in the `/tmp/token` file:

   ```code
-   $ sudo teleport start --token=${INVITE_TOKEN?}
+   $ sudo teleport start --token=/tmp/token
   ```

 1. Verify that you have added the label by running the following command on your local
@@ -43,7 +43,7 @@ Let's look at this table:
 | - | - | - |
 | `joe` | `joe`, `root` | Teleport user `joe` can log in as user `joe` or `root` on SSH servers. |
 | `bob` | `bob` | Teleport user `bob` can log in as user `bob` on SSH servers. |
-| `kim` | | Teleport user 'kim' has no designated SSH logins.  |
+| `kim` | | Teleport user `kim` has no designated SSH logins.  |

 SSH logins are some of the user traits available in Teleport roles. For all supported traits, see the reference for [`tctl users add`](../../reference/cli/tctl.mdx#tctl-users-add).