rfd spell fixes (#46628)

Co-authored-by: Steven Martin <[email protected]>

rfd/0057-automatic-user-provisioning.md

@@ -416,7 +416,7 @@ spec:
 ## Update: tag `keep` users and reconcile groups for existing users
 
 This will add a new teleport system group named `teleport-keep` which
-will be assigned to host users created whith `create_host_user_mode: keep`.
+will be assigned to host users created with `create_host_user_mode: keep`.
 Adding a new group will make it possible to differentiate between
 `insecure-drop` users, `keep` users, and users not managed by Teleport.
 This makes it possible to apply any group changes made against the role to

rfd/0103-application-access-web-ui-auth-flow.md

@@ -77,7 +77,7 @@ sequenceDiagram
     Browser->>App Handler: GET dumper.localhost/x-teleport-auth<br>Creates state token
     App Handler->>Browser: REDIRECT /web/launch/dumper.localhost/cluster-name/dumper.localhost?state=<TOKEN><br>set cookie with the same <TOKEN>
     Note left of Browser: Back at AppLauncher.tsx
-    Browser->>Web Handler: POST /v1/webapi/sessions/app with body:<br>{fqdn: dumper.localhost, plubic_addr: dumper.localhost, cluster_name: cluster-name}
+    Browser->>Web Handler: POST /v1/webapi/sessions/app with body:<br>{fqdn: dumper.localhost, public_addr: dumper.localhost, cluster_name: cluster-name}
     Web Handler->>Auth Server: CreateAppSession
     Auth Server->>Web Handler: Returns created session
     Web Handler->>Browser: Returns with the app <SESSION_BEARER_TOKEN> and <SESSION_ID> as JSON response

rfd/0163-vnet.md

@@ -328,7 +328,7 @@ The primary reason for using the CGNAT range is to avoid IP and route conflicts
 with the RFC 1918 private address spaces that are very commonly used in
 enterprises already.
 There are 4 million IP addresses in this range so exhaustion won't be a concern.
-This range can be overriden with a cluster-wide configuration.
+This range can be overridden with a cluster-wide configuration.
 
 One downside of using the CGNAT range is that the Chromium web browser does not
 currently consider it a private address space for the purposes of CORS

rfd/0170-nested-accesslists.md

@@ -61,18 +61,18 @@ from the list of members in the included access list.
 
 ## Cycles within lists
 
-The implementation will not support cycles within the heirarchy as
+The implementation will not support cycles within the hierarchy as
 this would introduce confusing options for configuration. Teleport
 will return an error if a cycle are introduced. It will also only look
 10 layers deep before exiting a lookup to avoid overly complex
-heirarchies.
+hierarchies.
 
-Errors over cycles in the heirarchy will be detected and returned at
+Errors over cycles in the hierarchy will be detected and returned at
 access list insertion/update time.
 
 ### Nesting depth
 
-Access list heirarchys will only recurse up to 10 layers deep
+Access list hierarchies will only recurse up to 10 layers deep
 initially.
 
 ## Access list reviews
@@ -98,7 +98,7 @@ user passes the respective membership/ownership requirements
 ## Other considerations
 
 Access lists will need to be allowed to have empty grants so access
-lists can represent only users and permisisons can be assigned purely
+lists can represent only users and permissions can be assigned purely
 through membership in other lists.
 
 # Examples

rfd/0173-terraform-machine-id.md

@@ -172,7 +172,7 @@ $ terraform apply ...
 - create the 3 bootstrap resources
   - if the call fails because of missing permissions, output a user-friendly error such as:
     ```
-    Failed to create bootstrap resources using your local credentials (user "[email protected]", address "mytenant.telpeort.sh:443").
+    Failed to create bootstrap resources using your local credentials (user "[email protected]", address "mytenant.teleport.sh:443").
     Please check if you have the rights to create role, bot and token resources. You might need to re-log in for new rights to take effect.
     (tsh logout --proxy="mytenant.teleport.sh:443" --user="[email protected]")
     ```