[v17] docs: new product messaging for marketing launch (#52959)

* product name changes from marketing

* correcting duplications

* post-marketing review

* review changes

* Update docs/pages/admin-guides/infrastructure-as-code/managing-resources/access-list.mdx

Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>

* revisions

* cleanup and reverting use-cases of 'Zero Trust Access x'

* Trust Access corrections

* removing 2 images already in master

* post-feedback changes

* Update docs/pages/admin-guides/teleport-policy/teleport-policy.mdx

Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>

* post G2 review feedback

* Lint helm appeasement

* adding two images from marketing

* moving 2 images to getting-started directory

---------

Co-authored-by: Zac Bergquist <zac.bergquist@goteleport.com>

Author: mmcallister

docs/pages/admin-guides/access-controls/access-monitoring.mdx

@@ -31,7 +31,7 @@ Users are able to write their own custom access monitoring queries by querying t
 <Tabs>
 <TabItem scope={["cloud","team"]} label="Teleport Enterprise (cloud-hosted)">
 
-Teleport Access Monitoring is enabled by default for all Teleport Enterprise (cloud-hosted) accounts.
+Access Monitoring is enabled by default for all Teleport Enterprise (cloud-hosted) accounts.
 
 </TabItem>
 <TabItem scope={["enterprise", "oss"]} label="Self-Hosted">
@@ -181,7 +181,7 @@ spec:
 
 ## Query Editor
 
-The Query Editor in Teleport Access Monitoring provides users with an interface to interactively query audit logs and generate reports.
+The Query Editor in Access Monitoring provides users with an interface to interactively query audit logs and generate reports.
 Users can write custom SQL queries for these views to build custom reports akin to querying a relational database.
 
 Within the Query Editor, users have access to a number of SQL views representing audit events captured by Teleport.

docs/pages/admin-guides/access-controls/access-request-plugins/datadog-hosted.mdx

@@ -19,7 +19,7 @@ The Teleport Datadog Incident Management integration connects to the Teleport
 gRPC API and listens for Role Access Requests. When the integration receives a
 status change for a Role Access Request, it either creates a new incident in
 Datadog or, if an incident exists, updates it. The integration also reads
-annotations on each Teleport Access Request and, depending on the annotations,
+annotations on each Access Request and, depending on the annotations,
 may approve the Access Request automatically.
 
 ## Prerequisites
@@ -124,7 +124,7 @@ to view your organization's service accounts. To create a new service account, c
 on **New Service Account** and name it "Teleport Access". You can provide whatever
 email you'd like to associate with the service account, then assign the role
 "Datadog Standard Role". This role provides the required permissions necessary to
-manage the Teleport Access Request incidents.
+manage the incidents in Datadog.
 
 ![Datadog dashboard for Service Accounts](../../../../img/enterprise/plugins/datadog/dashboard-service-accounts.png)
 

docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-email.mdx

@@ -1,5 +1,5 @@
 ---
-title: Teleport Access Requests with Email
+title: Access Requests with Email
 description: How to set up the Teleport email plugin to notify users when another user requests elevated privileges.
 ---
 

docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-jira.mdx

@@ -4,7 +4,7 @@ description: How to set up the Teleport Jira plugin to notify users when another
 ---
 
 This guide explains how to set up the Teleport Access Request plugin for Jira.
-Teleport's Jira integration allows you to manage Teleport Access Requests as
+Teleport's Jira integration allows you to manage Access Requests as
 Jira issues.
 
 The Teleport Jira plugin synchronizes a Jira project board with the Access
@@ -139,7 +139,7 @@ Click **Back to board** to review your changes.
 
 ### Retrieve your Jira API token
 
-Obtain an API token that the Teleport Access Request plugin uses to make
+Obtain an API token that the Access Request plugin uses to make
 changes to your Jira project. Click the gear menu at the upper right of the
 screen, then click **Atlassian account settings**. Click **Security** >
 **Create and manage API tokens** > **Create API token**. 
@@ -385,8 +385,7 @@ Access Request:
 
 (!docs/pages/includes/plugins/create-request.mdx!)
 
-When you create the request, you will see a new task in the "Pending" column of
-the Teleport Access Requests board:
+When you create the request, you will see a new task in the "Pending" column of the Access Requests board:
 
 ![New Access Request](../../../../img/enterprise/plugins/jira/new-request.png)
 

docs/pages/admin-guides/access-controls/access-request-plugins/ssh-approval-mattermost.mdx

@@ -5,7 +5,7 @@ description: How to set up Teleport's Mattermost plugin for privilege elevation
 
 import BotLogo from "/static/avatar_logo.png";
 
-This guide explains how to integrate Teleport Access Requests with Mattermost, an open 
+This guide explains how to integrate Access Requests with Mattermost, an open 
 source messaging platform. The Teleport Mattermost plugin notifies individuals of
 Access Requests. Users can then approve and deny Access Requests by following the
 message link, making it easier to implement security best practices without

docs/pages/admin-guides/access-controls/access-requests/access-requests.mdx

@@ -20,7 +20,7 @@ consider [Access Lists](../access-lists/access-lists.mdx).
 
 ## See how Access Requests work
 
-Teleport Access Requests support two main use cases: **Role Access Requests**
+Access Requests support two main use cases: **Role Access Requests**
 and **Resource Access Requests**.
 
 With Role Access Requests, engineers can request temporary credentials with

docs/pages/admin-guides/access-controls/access-requests/resource-requests.mdx

@@ -307,8 +307,7 @@ below, edit one of the user's roles so the `search_as_roles` field includes the
 role you have created.
 
 For full details on how to use Teleport roles to configure RBAC, see the
-[Teleport Access Controls
-Reference](../../../reference/access-controls/roles.mdx).
+[Access Controls Reference](../../../reference/access-controls/roles.mdx).
 
 #### `node`
 

docs/pages/admin-guides/access-controls/device-trust/guide.mdx

@@ -153,6 +153,6 @@ Device Trust enforcement.
 - The role we illustrated in this guide uses the `internal.logins` trait,
   which Teleport replaces with values from the Teleport local user
   database. For full details on how traits work in Teleport roles,
-  see the [Teleport Access Controls
+  see the [Access Controls
   Reference](../../../reference/access-controls/roles.mdx).
 

docs/pages/admin-guides/access-controls/getting-started.mdx

@@ -1,6 +1,6 @@
 ---
 title: Getting Started With Access Controls
-description: Get started using Teleport Access Controls.
+description: Get started using Access Controls.
 ---
 
 In Teleport, any local, SSO, or robot user can be assigned one or several roles.

docs/pages/admin-guides/access-controls/sso/adfs.mdx

@@ -208,6 +208,6 @@ automatically in a browser.
 In the Teleport role we illustrated in this guide, `external` traits
 are replaced with values from the single sign-on provider that the user
 used to authenticate to Teleport. For full details on how traits
-work in Teleport roles, see the [Teleport Access Controls
+work in Teleport roles, see the [Access Controls
 Reference](../../../reference/access-controls/roles.mdx).
 

docs/pages/admin-guides/access-controls/sso/azuread.mdx

@@ -413,6 +413,6 @@ Change the Name ID format to use email instead:
 - In the Teleport role we illustrated in this guide, `external` traits
   are replaced with values from the single sign-on provider that the
   user used to authenticate to Teleport. For full details on how traits
-  work in Teleport roles, see the [Teleport Access Controls
+  work in Teleport roles, see the [Access Controls
   Reference](../../../reference/access-controls/roles.mdx).
 

docs/pages/admin-guides/access-controls/sso/github-sso.mdx

@@ -481,6 +481,6 @@ shows the slug is `my-team`. Update the teams to roles mapping.
 The role we illustrated in this guide uses the `internal.logins` trait,
 which Teleport replaces with values from the Teleport local user
 database. For full details on how traits work in Teleport roles,
-see the [Teleport Access Controls
+see the [Access Controls
 Reference](../../../reference/access-controls/roles.mdx).
 

docs/pages/admin-guides/access-controls/sso/gitlab.mdx

@@ -178,7 +178,7 @@ spec:
   *"email"* GitLab claim and use that field as an allowed login for each user.
   The `email.local(external.trait)` function removes the `@domain` and preserves
   the username prefix. For full details on how variable expansion works in
-  Teleport roles, see the [Teleport Access Controls
+  Teleport roles, see the [Access Controls
   Reference](../../../reference/access-controls/roles.mdx).
 - Developers also do not have any "allow rules" i.e. they will not be able to
   see/replay past sessions or re-configure the Teleport cluster.

docs/pages/admin-guides/access-controls/sso/okta.mdx

@@ -235,7 +235,7 @@ Notice the `{{external.username}}` login. It configures Teleport to look at the
 This example uses email as the username format.  The
 `email.local(external.username)` function call will remove the `@domain` and
 leave the username prefix. For full details on how variable expansion works in
-Teleport roles, see the [Teleport Access Controls
+Teleport roles, see the [Access Controls
 Reference](../../../reference/access-controls/roles.mdx).
 
 Use `tctl` to create this role in the Teleport Auth Service:

docs/pages/admin-guides/access-controls/sso/one-login.mdx

@@ -168,6 +168,6 @@ $ tctl create -f dev.yaml
 In the Teleport role we illustrated in this guide, `external` traits
 are replaced with values from the single sign-on provider that the user
 used to authenticate to Teleport. For full details on how traits
-work in Teleport roles, see the [Teleport Access Controls
+work in Teleport roles, see the [Access Controls
 Reference](../../../reference/access-controls/roles.mdx).
 

docs/pages/admin-guides/access-controls/sso/sso.mdx

@@ -663,5 +663,5 @@ version: v5
 The roles we illustrated in this guide use `external` traits,
 which Teleport replaces with values from the single sign-on provider that the
 user used to authenticate with Teleport. For full details on how variable
-expansion works in Teleport roles, see the  [Teleport Access Controls
+expansion works in Teleport roles, see the  [Access Controls
 Reference](../../../reference/access-controls/roles.mdx).

docs/pages/admin-guides/api/access-plugin.mdx

@@ -357,7 +357,7 @@ so, it calls `createRow`. If not, it calls `updateSpreadsheet`.
 The Teleport API client type, `client.Client`, has a `NewWatcher` method that
 listens for new audit events from the Auth Service API via a gRPC stream. The
 second parameter of the method indicates the type of audit event to watch for,
-in this case, events having to do with Teleport Access Requests.
+in this case, events having to do with Access Requests.
 
 The result of `NewWatcher`, a `types.Watcher`, enables `Run` to respond to new
 audit events by calling the `Events` method. This returns a Go **channel**, a

docs/pages/admin-guides/deploy-a-cluster/access-graph/access-graph.mdx

@@ -1,10 +1,10 @@
 ---
 title: "Self-Hosting Teleport Access Graph"
-description: Explains how to deploy Teleport Access Graph alongside a self-hosted Teleport cluster.
+description: Explains how to deploy Access Graph alongside a self-hosted Teleport cluster.
 ---
 
-If you run a self-hosted Teleport cluster, using Teleport Access Graph (part of
-Teleport Policy) requires running the Access Graph Service on your own
+If you run a self-hosted Teleport cluster, using Access Graph (part of
+Teleport Identity Security) requires running the Access Graph Service on your own
 infrastructure. The following guides show you how to deploy the Access Graph
 Service.
 

docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted-helm.mdx

@@ -1,9 +1,9 @@
 ---
-title: Run Teleport Policy's Access Graph feature on Self-Hosted Clusters with Helm
+title: Run Teleport Identity Security with Access Graph on Self-Hosted Clusters with Helm
 description: How to deploy Access Graph on self-hosted clusters using Helm.
 ---
 
-Using Teleport Policy's Access Graph with a self-hosted Teleport cluster requires
+Using Teleport Identity Security with Access Graph on a self-hosted Teleport cluster requires
 setting up the Access Graph, a dedicated service which uses PostgreSQL 
 as its backing storage and communicates with Auth Service and Proxy Service
 to collect information about resources and access.
@@ -13,7 +13,7 @@ and enable the Access Graph feature in your Teleport cluster.
 
 The full listing of supported parameters can be found in the [Helm chart reference](../../../reference/helm-reference/teleport-access-graph.mdx).
 
-Access Graph is a feature of the [Teleport Policy](https://goteleport.com/platform/policy/) product that is only available
+Access Graph is a feature of the [Identity Security](https://goteleport.com/platform/policy/) product that is only available
 to Teleport Enterprise customers.
 
 ## Prerequisites
@@ -24,7 +24,7 @@ to Teleport Enterprise customers.
   - For the purposes of this guide, we assume that the Teleport cluster is set up
     [using the `teleport-cluster` Helm chart](../helm-deployments/helm-deployments.mdx)
     in the same Kubernetes cluster that will be used to deploy Access Graph.
-- An updated `license.pem` with Teleport Policy enabled.
+- An updated `license.pem` with Identity Security enabled.
 - A PostgreSQL database server v14 or later.
   - Access Graph needs a dedicated [database](https://www.postgresql.org/docs/current/sql-createdatabase.html) to store its data.
     The user that Teleport connects to the database with needs to be the owner of this database, or have similar broad permissions:

docs/pages/admin-guides/deploy-a-cluster/access-graph/self-hosted.mdx

@@ -1,9 +1,9 @@
 ---
-title: Run Teleport Policy on Self-Hosted Clusters
+title: Run Teleport Identity Security on Self-Hosted Clusters
 description: Describes how to deploy Access Graph on self-hosted clusters.
 ---
 
-Teleport Policy's Access Graph with a self-hosted Teleport cluster requires setting up 
+Identity Security with Access Graph on a self-hosted Teleport cluster requires setting up 
 Access Graph, a dedicated service which uses PostgreSQL as its backing storage and communicates 
 with Auth Service and Proxy Service to collect information about resources and access.
 
@@ -12,7 +12,7 @@ This guide will help you set up the service and enable Access Graph in your Tele
 ## Prerequisites
 
 - A running Teleport Enterprise cluster v14.3.6 or later.
-- An updated `license.pem` with Teleport Policy enabled.
+- An updated `license.pem` with Identity Security enabled.
 - Docker version v(=docker.version=) or later.
 - A PostgreSQL database server v14 or later.
   - Access Graph needs a dedicated [database](https://www.postgresql.org/docs/current/sql-createdatabase.html) to store its data.

docs/pages/admin-guides/infrastructure-as-code/infrastructure-as-code.mdx

@@ -69,7 +69,7 @@ Operator by following:
 - the ["Registering Agentless OpenSSH Servers with IaC" guide](managing-resources/agentless-ssh-servers.mdx)
 
 For more information on Teleport roles, including the `internal.logins`
-trait we use in these example roles, see the [Teleport Access
+trait we use in these example roles, see the [Access
 Controls Reference](../../reference/access-controls/roles.mdx).
 
 ### YAML documents with `tctl`

docs/pages/admin-guides/infrastructure-as-code/managing-resources/access-list.mdx

@@ -1,6 +1,6 @@
 ---
 title: Creating Access Lists with IaC
-description: Use Infrastructure-as-Code tooling to create Teleport AccessLists.
+description: Use Infrastructure-as-Code tooling to create Access Lists.
 ---
 
 Access Lists allow Teleport users to be granted long-term access to resources

docs/pages/admin-guides/infrastructure-as-code/terraform-starter/terraform-starter.mdx

@@ -26,7 +26,7 @@ provided to each Agent.
 Part Two of the Terraform starter module shows you how to configure Teleport
 role-based access controls to provide different levels of access to the
 resources you enrolled in Part One. It also configures Access Requests,
-available in Teleport Identity, so that users authenticate with less privileged
+available in Teleport Identity Governance, so that users authenticate with less privileged
 roles by default but can request access to more privileged roles. An
 authentication connector lets users authenticate to Teleport using a Single
 Sign-On provider.

docs/pages/admin-guides/management/admin/trustedclusters.mdx

@@ -695,7 +695,7 @@ node_labels:
 ```
 
 For full details on how variable expansion works in Teleport roles, see the
-[Teleport Access Controls
+[Access Controls
 Reference](../../../reference/access-controls/roles.mdx).
 
 ### Update role mappings

docs/pages/admin-guides/management/guides/aws-iam-identity-center.mdx

@@ -7,9 +7,7 @@ Teleport's integration with [AWS IAM Identity Center](https://aws.amazon.com/iam
 allows you to organize and manage your users' short- and long-term access to AWS
 accounts and their permissions.
 
-With the Identity Center integration you can grant or revoke persistent access
-to AWS accounts and resources using Teleport Access Lists, or use Teleport
-Access Requests for scenarios requiring temporary elevated AWS privileges.
+With the AWS Identity Center integration, you can manage AWS access by granting short term or long term access with Identity Governance.
 
 ## How it works
 
@@ -266,8 +264,7 @@ regardless of when the user assumes the associated role(s).
 
 ### Just-in-time access with role Access Requests
 
-For short-term privilege elevation, Identity Center integration works with
-Teleport Access Requests.
+The Identity Center integration allows Teleport users to submit Access Requests for short-term privilege elevation.
 
 When an Access Request for a role granting Identity Center privileges is
 approved, Teleport creates an individual assignment for that user in the

docs/pages/admin-guides/management/security/reduce-blast-radius.mdx

@@ -222,6 +222,6 @@ Two `user`s can grant elevated privileges to another `user` temporarily without
 - [Auth Service](../../../reference/architecture/authentication.mdx)
 - The roles we illustrated in this guide use `internal` traits, which Teleport
   replaces with values from the Teleport local user database.  For full details
-  on how variable expansion works in Teleport roles, see the [Teleport Access
+  on how variable expansion works in Teleport roles, see the [Access
   Controls Reference](../../../reference/access-controls/roles.mdx).
 

docs/pages/admin-guides/teleport-policy/crown-jewels.mdx

@@ -22,7 +22,7 @@ log in via Teleport Auth Connectors.
 </Admonition>
 
 - A running Teleport Enterprise cluster v16.2.0 or later.
-- For self-hosted clusters, an updated `license.pem` with Teleport Policy enabled.
+- For self-hosted clusters, an updated `license.pem` with Teleport Identity Security enabled.
 - For self-hosted clusters, a running Access Graph node v1.24.0 or later.
 Check [Access Graph page](teleport-policy.mdx) for details on
 how to set up Access Graph.
@@ -50,7 +50,7 @@ version: v7
 ## Creating a Crown Jewel
 
 To create a Crown Jewel, you need to mark a resource or user as critical. Only changes to marked resources
-and users will be logged by Teleport Policy.
+and users will be logged by Identity Security.
 To mark a resource or user as Crown Jewel, open the Access Graph and navigate to the "Crown Jewels" tab.
 
 ![Create Page](../../../img/access-graph/crown-jewels/create-page.webp)

docs/pages/admin-guides/teleport-policy/integrations/aws-sync.mdx

@@ -1,12 +1,12 @@
 ---
-title: Discover AWS Access Patterns with Teleport Policy
-description: Describes how to import and visualize AWS accounts access patterns using Teleport Policy and Access Graph.
+title: Discover AWS Access Patterns with Teleport Identity Security
+description: Describes how to import and visualize AWS accounts access patterns using Identity Security and Access Graph.
 ---
 
-Teleport Policy streamlines and centralizes access management across your entire infrastructure. You can view access relationships in seconds,
+Identity Security streamlines and centralizes access management across your entire infrastructure. You can view access relationships in seconds,
 viewing unified, up-to-date relationships and policies between all users, groups, and computing resources.
 
-Teleport Policy with Access Graph offers insights into access patterns within your AWS account. By scanning IAM
+Identity Security with Access Graph offers insights into access patterns within your AWS account. By scanning IAM
 permissions, users, groups, resources, and identities, it provides a visual representation and aids in
 enhancing the permission model within your AWS environment. This functionality enables you to address queries such as:
 
@@ -24,7 +24,7 @@ service, a Discovery Service, and integration with your AWS account.
 Access Graph discovers AWS access patterns, synchronizes various AWS resources,
 including IAM Policies, Groups, Users, User Groups, EC2 instances, EKS clusters, and RDS databases.
 These resources are then visualized using the graph representation detailed in the
-[Teleport Policy usage page](../policy-how-to-use.mdx).
+[Identity Security usage page](../policy-how-to-use.mdx).
 
 The importing process involves two primary steps:
 
@@ -48,19 +48,19 @@ Access Graph, ensuring that it remains updated with the latest information from
 
 ### Importing resources
 
-Teleport Policy’s Access Graph feature delves into the IAM policies, identities,
+Identity Security’s Access Graph feature delves into the IAM policies, identities,
 and resources retrieved from your AWS account, crafting a
 graphical representation thereof.
 
 
 ## Prerequisites
 
 - A running Teleport Enterprise cluster v14.3.9/v15.2.0 or later.
-- Teleport Policy enabled for your account.
+- Identity Security enabled for your account.
 - For self-hosted clusters:
   - Ensure that an up-to-date `license.pem` is used in the Auth Service configuration.
   - A running Access Graph node v1.17.0 or later.
-Check the [Teleport Policy page](../teleport-policy.mdx) for details on
+Check the [Identity Security page](../teleport-policy.mdx) for details on
 how to set up Access Graph.
   - The node running the Access Graph service must be reachable from the Teleport Auth Service.