diff --git a/docs/pages/reference/access-controls/access-lists.mdx b/docs/pages/reference/access-controls/access-lists.mdx index 033f03a6c7001..2b1ee353d64ce 100644 --- a/docs/pages/reference/access-controls/access-lists.mdx +++ b/docs/pages/reference/access-controls/access-lists.mdx @@ -4,7 +4,7 @@ description: An explanation and overview of Access Lists in Teleport. --- Access Lists allow Teleport users to be granted long term access to resources -managed within Teleport. With Access Lists, administrators and access list +managed within Teleport. With Access Lists, administrators and Access List owners can regularly audit and control membership to specific roles and traits, which then tie easily back into Teleport's existing RBAC system. @@ -31,7 +31,7 @@ to live on the order of hours or days. Access List owners are Teleport users or nested Access Lists who are granted special privileges over an Access List. These owners are defined explicitly as part of the Access List, and -must be added by a Teleport user who has RBAC access to access lists, which the preset `editor` +must be added by a Teleport user who has RBAC access to Access Lists, which the preset `editor` role has. Owners must meet requirements in order for their ownership to be effective. Provided owners meet requirements, owners are able to do the following: @@ -178,7 +178,7 @@ Roles intended to reduce privileges should be assigned directly to users. ## Managing Access Lists from the CLI In addition to using the web UI, Access Lists can be created and managed from the CLI -as well. To create an access list from the CLI, create an Access List YAML file (as described +as well. To create an Access List from the CLI, create an Access List YAML file (as described above) and run `tctl create `. Access Lists can be updated by using `tctl create -f `. `tctl` also supports a subset of Access List focused commands under the `tctl acl` subcommand. diff --git a/docs/pages/reference/access-controls/authentication.mdx b/docs/pages/reference/access-controls/authentication.mdx index bb05f0ab722e0..6568df2c1e211 100644 --- a/docs/pages/reference/access-controls/authentication.mdx +++ b/docs/pages/reference/access-controls/authentication.mdx @@ -17,10 +17,10 @@ possible values (types) of MFA: - `otp` is the default. It implements the [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm) standard. You can use [Google Authenticator](https://en.wikipedia.org/wiki/Google_Authenticator), [Authy](https://www.authy.com/) or any other TOTP client. - `webauthn` implements the [Web Authentication standard](https://webauthn.guide) for utilizing - second factor authenticators and hardware devices. + multi-factor authenticators and hardware devices. You can use [YubiKeys](https://www.yubico.com/), [SoloKeys](https://solokeys.com/) or any other authenticator that implements FIDO2 or FIDO U2F standards. - See our [Second Factor - WebAuthn](../../admin-guides/access-controls/guides/webauthn.mdx) guide for detailed + See our [Harden your Cluster Against IdP Compromises](../../admin-guides/access-controls/guides/webauthn.mdx) guide for detailed instructions on setting up WebAuthn for Teleport. - `on` enables both TOTP and WebAuthn, and all local users are required to have at least one MFA device registered. - `optional` enables both TOTP and WebAuthn but makes it optional for users. Local users that register a MFA device will diff --git a/docs/pages/reference/access-controls/roles.mdx b/docs/pages/reference/access-controls/roles.mdx index 012ecafa6a2c7..86029bff5012b 100644 --- a/docs/pages/reference/access-controls/roles.mdx +++ b/docs/pages/reference/access-controls/roles.mdx @@ -574,7 +574,7 @@ You can specify an external trait in dot syntax if it begins with a letter and contains only letters, numbers, and underscores. Otherwise, you must use bracket syntax to specify a trait. -When using Azure AD or ADFS as your IdP, you must use bracket notation, as these +When using Microsoft Entra ID or ADFS as your IdP, you must use bracket notation, as these IdPs assign attribute keys to URLs such as the following: ```text diff --git a/docs/pages/reference/agent-services/desktop-access-reference/configuration.mdx b/docs/pages/reference/agent-services/desktop-access-reference/configuration.mdx index 563ce10d829c6..1f487b4e828ca 100644 --- a/docs/pages/reference/agent-services/desktop-access-reference/configuration.mdx +++ b/docs/pages/reference/agent-services/desktop-access-reference/configuration.mdx @@ -21,10 +21,10 @@ The Windows Desktop Service can be deployed in two modes. ### Direct mode In *direct* mode, Windows Desktop Services registers directly with the Teleport -Auth Server, and listens for desktop connections from the Teleport Proxy. To +Auth Service, and listens for desktop connections from the Teleport Proxy. To enable direct mode, set `windows_desktop_service.listen_addr` in `teleport.yaml`, and ensure that `teleport.auth_server` points directly at the -Auth Server. +Auth Service. Direct mode requires network connectivity both: @@ -38,7 +38,7 @@ self-hosted Teleport clusters. In *IoT mode*, Windows Desktop Service only needs to be able to make an outbound connection to a Teleport Proxy. The Windows Desktop Service establishes a -reverse tunnel to the proxy, and both registration with the Auth Server and +reverse tunnel to the proxy, and both registration with the Auth Service and desktop sessions are performed over this tunnel. To enable this mode, ensure that `windows_desktop_service.listen_addr` is *unset*, and point `teleport.proxy_server` at a Teleport Proxy. @@ -65,4 +65,4 @@ spec: screen_size: width: 1024 height: 768 -``` \ No newline at end of file +``` diff --git a/docs/pages/reference/agent-services/kubernetes-application-discovery.mdx b/docs/pages/reference/agent-services/kubernetes-application-discovery.mdx index 4e5c673c26043..56bf490e0714f 100644 --- a/docs/pages/reference/agent-services/kubernetes-application-discovery.mdx +++ b/docs/pages/reference/agent-services/kubernetes-application-discovery.mdx @@ -8,7 +8,7 @@ Teleport Application Service, and annotations on Kubernetes services. This guide shows you how to configure each of these to manage Kubernetes Application Discovery in your Kubernetes cluster. -## Configuring Teleport agent Helm chart +## Configuring Teleport Agent Helm chart You can configure scope of services discovery by setting value `kubernetesDiscovery` of the chart. For more information please see [helm chart documentation](../helm-reference/teleport-kube-agent.mdx). diff --git a/docs/pages/reference/architecture/agent-update-management.mdx b/docs/pages/reference/architecture/agent-update-management.mdx index 1c8da5a0017ae..5779bd462be85 100644 --- a/docs/pages/reference/architecture/agent-update-management.mdx +++ b/docs/pages/reference/architecture/agent-update-management.mdx @@ -54,16 +54,16 @@ The agent version is subject to the following constraints: - the agent must always be no more than one major version below the Proxy or Auth Service version. -The best practice is to always align the agent version with the Proxy and Auth -ones. To upgrade Auth and Proxy, follow [the Teleport Cluster upgrade guide -](../../upgrading/upgrading.mdx). +The best practice is to always align the agent version with the version of the +Proxy Service and Auth Service. To upgrade the Auth Service and Proxy Service, +follow [the Teleport Cluster upgrade guide](../../upgrading/upgrading.mdx). For this reason, all updaters must subscribe to a release channel targeting versions that are compatible with their Teleport cluster. Teleport Cloud users must use the Teleport Cloud version server with the `stable/cloud` release channel. Self-hosted Teleport users must host their own version server and -either update their release channel each time they update their Auth and Proxy -instances, or use the `stable/rolling` channel. +either update their release channel each time they update their Auth Service and +Proxy Service instances, or use the `stable/rolling` channel. ### Teleport Cloud diff --git a/docs/pages/reference/architecture/agents.mdx b/docs/pages/reference/architecture/agents.mdx index bd71e13c2480a..1603abeef56db 100644 --- a/docs/pages/reference/architecture/agents.mdx +++ b/docs/pages/reference/architecture/agents.mdx @@ -180,13 +180,13 @@ Teleport cluster: - [OpenSSH servers](../../enroll-resources/server-access/openssh/openssh.mdx) - [Windows desktops](../../enroll-resources/desktop-access/getting-started.mdx) -## Clients to agents +## Clients to Agents -Client tools authenticate to Teleport agent by presenting certificates signed by -a Teleport certificate authority, forwarding traffic to the agent through an SSH -reverse tunnel established between the Teleport Proxy Service and the agent. +Client tools authenticate to Teleport Agents by presenting certificates signed by +a Teleport certificate authority, forwarding traffic to the Agent through an SSH +reverse tunnel established between the Teleport Proxy Service and the Agent. Clients need to retrieve a certificate, then connect to an infrastructure -resource through the agent. +resource through the Agent. ### Credentials for Teleport clients @@ -275,5 +275,5 @@ Reference](../monitoring/audit.mdx). ## Further reading -- For instructions on deploying agents, see the [Teleport agent +- For instructions on deploying agents, see the [Teleport Agent guides](../../enroll-resources/agents/introduction.mdx). diff --git a/docs/pages/reference/architecture/api-architecture.mdx b/docs/pages/reference/architecture/api-architecture.mdx index 0efa625a3f109..0185c28a1c727 100644 --- a/docs/pages/reference/architecture/api-architecture.mdx +++ b/docs/pages/reference/architecture/api-architecture.mdx @@ -12,12 +12,12 @@ Started](../../admin-guides/api/getting-started.mdx). ## Authentication The Auth API uses mTLS to authenticate a client-server connection. Therefore, the client must provide -TLS certificates signed by the Auth server to access the API. These are easy to create and provide using +TLS certificates signed by the Auth Service to access the API. These are easy to create and provide using [Credential loaders](#credentials). ## Authorization -The client certificates signed by the Auth server will be associated with a specific user. This user will +The client certificates signed by the Auth Service will be associated with a specific user. This user will be used to authorize API requests made by the client. It is recommended to make a new user and role for each client. This makes it easier to track client actions, @@ -77,7 +77,7 @@ benefits, here's a quick breakdown: underlying identity files. - Key pair credentials have a much simpler implementation than the other Credentials listed and may feel more familiar. These are good for - authenticating clients hosted directly on the auth server. + authenticating clients hosted directly on the Auth Service. - TLS credentials leave everything up to the client user. This is mostly used internally, but some advanced users may find it useful. @@ -97,11 +97,12 @@ on pkg.go.dev for more information and examples for Credentials and Credential L ## Client connection -The API client makes requests through an open connection to the Teleport Auth server. +The API client makes requests through an open connection to the Teleport Auth +Service. -If the Auth server is isolated behind a +If the Auth Service is isolated behind a [Proxy Server](../architecture/proxy.mdx), a reverse tunnel connection can be -made using SSH certificates signed by the auth server. You can either provide +made using SSH certificates signed by the Auth Service. You can either provide the server's reverse tunnel address directly or provide the web proxy address and have the client automatically retrieve the reverse tunnel address. diff --git a/docs/pages/reference/architecture/authentication.mdx b/docs/pages/reference/architecture/authentication.mdx index 313cdbf9cfe14..9600dc8a6d665 100644 --- a/docs/pages/reference/architecture/authentication.mdx +++ b/docs/pages/reference/architecture/authentication.mdx @@ -57,8 +57,9 @@ identity to the public key with a certificate authority's signature. -Teleport uses x.509 certificates for Kubernetes, databases, web services and its own internal -components - proxies, auth services to establish mutually authenticated TLS connections - mTLS. +Teleport uses x.509 certificates for Kubernetes clusters, databases, web +services and its own internal components, such as the Proxy Service and Auth +Service, to establish mutually authenticated TLS connections (mTLS). ### OpenSSH certificates @@ -154,8 +155,10 @@ Take a look at the [Certificate Rotation Guide](../../admin-guides/management/op learn how to do certificate rotation in practice. -To quickly lock out the node, proxy or auth service that may be compromised without rotating the entire -cluster certificates, use node [session and identity locking](../../admin-guides/access-controls/guides/locking.mdx). +To quickly lock out a potentially compromised Auth Service instance, Proxy +Service instance, or Teleport Agent without rotating the entire cluster +certificates, use [session and identity +locking](../../admin-guides/access-controls/guides/locking.mdx). ## More concepts diff --git a/docs/pages/reference/architecture/authorization.mdx b/docs/pages/reference/architecture/authorization.mdx index 6fd5e012a9b63..4c4bdb9262c60 100644 --- a/docs/pages/reference/architecture/authorization.mdx +++ b/docs/pages/reference/architecture/authorization.mdx @@ -252,8 +252,9 @@ Reference](../access-controls/roles.mdx). **How role templates are evaluated** -Role templates are evaluated at the time of access to any resource either by proxy or node. -Every Teleport component - proxy, auth server or node has up to date copy of all roles. +Every Teleport component - whether a Proxy Service instance, Auth Service +instance, or Agent -has up to date copy of all roles. Teleport components +evaluate role templates at the time of access to any resource. Let's review a case with the following role template: diff --git a/docs/pages/reference/architecture/kubernetes-applications-architecture.mdx b/docs/pages/reference/architecture/kubernetes-applications-architecture.mdx index a87861d7253be..f3db513a74627 100644 --- a/docs/pages/reference/architecture/kubernetes-applications-architecture.mdx +++ b/docs/pages/reference/architecture/kubernetes-applications-architecture.mdx @@ -9,7 +9,7 @@ Kubernetes application auto-discovery consists of two parts: - Creating Teleport apps based on that list and proxying requests to them. - This will only work when the Teleport agent runs inside the target Kubernetes cluster + This will only work when the Teleport Agent runs inside the target Kubernetes cluster ### Polling Kubernetes services diff --git a/docs/pages/reference/architecture/machine-id-architecture.mdx b/docs/pages/reference/architecture/machine-id-architecture.mdx index 9182e5f4fb5a5..36142ff26568d 100644 --- a/docs/pages/reference/architecture/machine-id-architecture.mdx +++ b/docs/pages/reference/architecture/machine-id-architecture.mdx @@ -25,7 +25,7 @@ they comprise three linked resources. These are: - Token: for [onboarding](#joining-and-authentication), a token must exist that allows the Machine ID agent to initially authenticate as the bot user. If an existing token is not specified, then a single-use token will be created by - the Auth Server. + the Auth Service. - Bot instance: a single instance of a bot. As multiple `tbot` clients can join with a single Bot user or a single token, Bot Instances keep a running record of unique bot joins. diff --git a/docs/pages/reference/architecture/proxy-peering.mdx b/docs/pages/reference/architecture/proxy-peering.mdx index 4ad13d13c27b5..4a081e6edef89 100644 --- a/docs/pages/reference/architecture/proxy-peering.mdx +++ b/docs/pages/reference/architecture/proxy-peering.mdx @@ -8,7 +8,7 @@ every Teleport Proxy Service. This allows Teleport Proxy instances to scale horizontally without increasing the number of connections created by agents. - A Teleport agent is a Teleport instance that provides access to resources in your infrastructure, i.e., by running the SSH, + A Teleport Agent is a Teleport instance that provides access to resources in your infrastructure, i.e., by running the SSH, Kubernetes, Database, Application, or Desktop Services. diff --git a/docs/pages/reference/backends.mdx b/docs/pages/reference/backends.mdx index 2ad66568dbde2..662f03c3a9b64 100644 --- a/docs/pages/reference/backends.mdx +++ b/docs/pages/reference/backends.mdx @@ -276,7 +276,7 @@ To configure Teleport to use PostgreSQL: `storage` section of `teleport.yaml` as shown below. - Deploy several Auth Service instances connected to the PostgreSQL storage backend. - Deploy several Proxy Service nodes. -- Make sure that the Proxy Service instances and all Teleport agent services that +- Make sure that the Proxy Service instances and all Teleport Agent services that connect directly to the Auth Service have the `auth_server` configuration setting populated with the address of a load balancer for Auth Service instances. @@ -361,9 +361,10 @@ If the use of passwords is unavoidable, we recommend configuring them in [the `~/.pgpass` file](https://www.postgresql.org/docs/current/libpq-pgpass.html) rather than storing them in Teleport's configuration file. -### Azure AD authentication +### Microsoft Entra ID authentication -If you are running Teleport on Azure, Teleport can make use of [Azure AD +If you are running Teleport on Azure, Teleport can make use of [Microsoft Entra +ID authentication](https://learn.microsoft.com/azure/postgresql/flexible-server/concepts-azure-ad-authentication) to connect to an Azure Database for PostgreSQL server without having to manage any secrets: @@ -383,13 +384,13 @@ teleport: When `auth_mode` is set to `azure`, Teleport will automatically fetch short-lived tokens from the credentials available to it, to be used as database passwords. The database user must be [configured to allow connections using -Azure -AD](https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-configure-sign-in-azure-ad-authentication). +Microsoft Entra ID](https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-configure-sign-in-azure-ad-authentication). -Teleport will make use of the Azure AD credentials specified by [environment +Teleport will make use of the Microsoft Entra ID credentials specified by +[environment variables](https://learn.microsoft.com/azure/developer/go/azure-sdk-authentication#2-authenticate-with-azure), -[Azure AD Workload -Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview) +[Microsoft Entra Workload +ID](https://learn.microsoft.com/azure/aks/workload-identity-overview) credentials, or [managed identity](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview) credentials. @@ -1390,10 +1391,10 @@ to define a custom role for it. ### Authentication -Teleport will make use of the Azure AD credentials specified by [environment +Teleport will make use of the Microsoft Entra ID credentials specified by [environment variables](https://learn.microsoft.com/azure/developer/go/azure-sdk-authentication#2-authenticate-with-azure), -[Azure AD Workload -Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview) +[Microsoft Entra Workload +ID](https://learn.microsoft.com/azure/aks/workload-identity-overview) credentials, or [managed identity](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview) credentials. @@ -1495,7 +1496,7 @@ To configure Teleport to use CockroachDB as a storage backend: `storage` section of `teleport.yaml` as shown below. - Deploy several Auth Service instances connected to the CockroachDB storage backend. - Deploy several Proxy Service instances. -- Make sure that the Proxy Service instances and all Teleport agent services that +- Make sure that the Proxy Service instances and all Teleport Agent services that connect directly to to the Auth Service have the `auth_server` configuration setting populated with the address of a load balancer for Auth Service instances. diff --git a/docs/pages/reference/cli/tbot.mdx b/docs/pages/reference/cli/tbot.mdx index 4c474a7e96252..46b303846c946 100644 --- a/docs/pages/reference/cli/tbot.mdx +++ b/docs/pages/reference/cli/tbot.mdx @@ -154,7 +154,7 @@ $ tbot proxy --destination-dir=./tbot-user --proxy-server=proxy.example.com:3080 - `3022` is the remote SSH port, which is `3022` for Nodes running the Teleport SSH service. -**Example using Database Access** +**Example using a Teleport-protected database** The following example opens a local proxy server to the given database. Your database client must still be configured with client TLS certificates: @@ -192,7 +192,7 @@ using database proxies. | `-a/--auth-server` | Address of the Teleport Auth Service. Prefer using --proxy-server where possible | | `--proxy-server` | Address of the Teleport Proxy Server. | | `--token` | A bot join token, if attempting to onboard a new bot; used on first connect. Can also be an absolute path to a file containing the token. | -| `--ca-pin` | CA pin to validate the Teleport Auth Server; used on first connect. | +| `--ca-pin` | CA pin to validate the Teleport Auth Service; used on first connect. | | `--data-dir` | Directory to store internal bot data. In production environments access to this directory should be limited only to an isolated linux user as an owner with `0600` permissions. | | `--destination-dir` | Directory to write short-lived machine certificates. | | `--certificate-ttl` | TTL of short-lived machine certificates. | @@ -305,7 +305,7 @@ another dedicated mode instead. | `-a/--auth-server` | Address of the Teleport Auth Service. Prefer using --proxy-server where possible | | `--proxy-server` | Address of the Teleport Proxy Server. | | `--token` | A bot join token, if attempting to onboard a new bot; used on first connect. Can also be an absolute path to a file containing the token. | -| `--ca-pin` | CA pin to validate the Teleport Auth Server; used on first connect. | +| `--ca-pin` | CA pin to validate the Teleport Auth Service; used on first connect. | | `--data-dir` | Directory to store internal bot data. In production environments access to this directory should be limited only to an isolated linux user as an owner with `0600` permissions. | | `--destination-dir` | Directory to write short-lived machine certificates. | | `--certificate-ttl` | TTL of short-lived machine certificates. | diff --git a/docs/pages/reference/cli/tctl.mdx b/docs/pages/reference/cli/tctl.mdx index e7f65fd3017c8..3240431b58fc4 100644 --- a/docs/pages/reference/cli/tctl.mdx +++ b/docs/pages/reference/cli/tctl.mdx @@ -107,7 +107,7 @@ which could result in the error, ## tctl acl get -Gets and displays information about a particular access list. +Gets and displays information about a particular Access List. ```code $ tctl acl get @@ -123,7 +123,7 @@ $ tctl acl ls ## tctl acl users add -Adds a user to an access list. +Adds a user to an Access List. ```code $ tctl acl users add [] [] @@ -131,7 +131,7 @@ $ tctl acl users add [] [] ## tctl acl users ls -Lists the users in an access list. +Lists the users in an Access List. ```code $ tctl acl users ls @@ -139,7 +139,7 @@ $ tctl acl users ls ## tctl acl users rm -Removes a user from an access list. +Removes a user from an Access List. ```code $ tctl acl users rm @@ -1435,7 +1435,7 @@ Supported presets: |------------|--------------------------------------|-----------| | `okta` | Okta | Okta | | `onelogin` | OneLogin | OneLogin | -| `ad` | Azure Active Directory | Microsoft | +| `ad` | Microsoft Entra ID | Microsoft | | `adfs` | Active Directory Federation Services | ADFS | ### Global flags @@ -1745,7 +1745,7 @@ $ tctl users ls [] ## tctl users reset -Reset local user account password and any associated second factor with expiring link to populate values. **Usage**: `tctl users reset ` +Reset local user account password and any associated multi-factor devices with expiring link to populate values. **Usage**: `tctl users reset ` ### Arguments diff --git a/docs/pages/reference/cli/teleport.mdx b/docs/pages/reference/cli/teleport.mdx index 8e97e813deb40..d551947d42743 100644 --- a/docs/pages/reference/cli/teleport.mdx +++ b/docs/pages/reference/cli/teleport.mdx @@ -57,9 +57,9 @@ we recommend using a [configuration file](../config.mdx) in production. | `--pid-file` | none | **string** filepath | create a PID file at the path | | `--advertise-ip` | none | **string** IP | advertise IP to clients, often used behind NAT | | `-l, --listen-ip` | `0.0.0.0` | [**net. IP**](https://golang.org/pkg/net/#IP) | binds services to IP | -| `--auth-server` | none | **string** IP | proxy attempts to connect to a specified auth server instead of local auth, disables `--roles=auth` if set | -| `--token` | none | **string** | set invitation token to register with an auth server on start, used once and ignored afterwards. Obtain it by running `tctl nodes add` on the auth server.*We recommend to use tools like `pwgen` to generate sufficiently random tokens of 32+ byte length.* | -| `--ca-pin` | none | **string** `sha256:` | set CA pin to validate the Auth Server. Generated by `tctl status` | +| `--auth-server` | none | **string** IP | proxy attempts to connect to a specified Auth Service instance instead of local auth, disables `--roles=auth` if set | +| `--token` | none | **string** | set invitation token to register with an Auth Service instance on start, used once and ignored afterwards. Obtain it by running `tctl nodes add` on the Auth Service instance. *We recommend to use tools like `pwgen` to generate sufficiently random tokens of 32+ byte length.* | +| `--ca-pin` | none | **string** `sha256:` | set CA pin to validate the Auth Service. Generated by `tctl status` | | `--nodename` | value returned by the `hostname` command on the machine | **string** | assigns an alternative name for the node which can be used by clients to log in. | | `-c, --config` | `/etc/teleport.yaml` | **string** `.yaml` filepath | starts services with config specified in the YAML file, overrides CLI flags if set | | `--apply-on-startup` | none | **string** `.yaml` filepath | On startup, always apply resources described in the file at the given path. Only supports the following kinds: `token`, `role`, `user`, `cluster-auth-preference`, `cluster-networking-config`. | @@ -67,7 +67,7 @@ we recommend using a [configuration file](../config.mdx) in production. | `--labels` | none | **string** comma-separated list | assigns a set of labels to a node, for example env=dev,app=web. See the explanation of labeling mechanism in the [Labeling Nodes](../../admin-guides/management/admin/labels.mdx) section. | | `--insecure` | none | none | disable certificate validation on Proxy Service, validation still occurs on Auth Service. | | `--fips` | none | none | start Teleport in FedRAMP/FIPS 140-2 mode. | -| `--skip-version-check` | `false` | `true` or `false` | Skips version checks between the Auth Server this Teleport instance | +| `--skip-version-check` | `false` | `true` or `false` | Skips version checks between the Auth Service and this Teleport instance | | `--diag-addr` | none | none | Enable diagnostic endpoints | | `--permit-user-env` | none | none | flag reads in environment variables from `~/.tsh/environment` when creating a session. | | `--app-name` | none | none | Name of the application to start | diff --git a/docs/pages/reference/cli/tsh.mdx b/docs/pages/reference/cli/tsh.mdx index dac5863a853f6..6d5311e89f023 100644 --- a/docs/pages/reference/cli/tsh.mdx +++ b/docs/pages/reference/cli/tsh.mdx @@ -899,7 +899,7 @@ in their [storage backend](../../reference/backends.mdx). The following error can occur if a session recording file is not available or when employing multiple auth servers with directory storage backend for recorded sessions. When using a directory storage backend for audit logs and recorded sessions, -only the auth server with that recorded session can retrieve it. +only the Auth Service with that recorded session can retrieve it. ```code $ tsh play c8e1b2c5-322a-4095-89e3-391edfd2da9b @@ -953,7 +953,7 @@ lifetime. ## tsh request drop -Drop one or more access requests from current identity +Drop one or more Access Requests from current identity ```code $ tsh request drop [...] diff --git a/docs/pages/reference/cloud-faq.mdx b/docs/pages/reference/cloud-faq.mdx index a15a3828e6fbc..c6ce43df8e05b 100644 --- a/docs/pages/reference/cloud-faq.mdx +++ b/docs/pages/reference/cloud-faq.mdx @@ -43,7 +43,7 @@ Password hashes are generated using [bcrypt](https://pkg.go.dev/golang.org/x/cry ### Do you encrypt data at rest? -Each deployment is using at-rest encryption using AWS DynamoDB and S3 at-rest encryption +Each deployment is using at-rest encryption using Amazon DynamoDB and S3 at-rest encryption for customer data including session recordings and user records. ### Can I get a list of IP addresses that my infrastructure will need to allow connections to? diff --git a/docs/pages/reference/helm-reference/teleport-cluster.mdx b/docs/pages/reference/helm-reference/teleport-cluster.mdx index e852ca2cff451..f1dfa6b81cc11 100644 --- a/docs/pages/reference/helm-reference/teleport-cluster.mdx +++ b/docs/pages/reference/helm-reference/teleport-cluster.mdx @@ -16,7 +16,7 @@ The `teleport-cluster` chart runs three Teleport services, split into two sets o | Teleport service | Running in | Purpose | Documentation | | - | - | - | - | | `auth_service` | auth `Deployment` | Authenticates users and hosts, and issues certificates. | [Auth documentation](../architecture/authentication.mdx) -| `kubernetes_service` | auth `Deployment` | Provides secure access to the Kubernetes
cluster where the Teleport cluster is hosted. | [Kubernetes Access documentation](../../enroll-resources/kubernetes-access/introduction.mdx) | +| `kubernetes_service` | auth `Deployment` | Provides secure access to the Kubernetes
cluster where the Teleport cluster is hosted. | [Enrolling Kubernetes clusters](../../enroll-resources/kubernetes-access/introduction.mdx) | | `proxy_service` | proxy `Deployment` | Runs the externally-facing parts of a Teleport
cluster, such as the web UI, SSH proxy and reverse tunnel service. | [Proxy documentation](../architecture/proxy.mdx) | @@ -309,7 +309,7 @@ Defaults to Teleport's binary default when empty: `best_effort`. |----------|---------------|-----------|---------------------------------------------| | `string` | `otp` | Yes | `auth_service.authentication.second_factor` | -`authentication.secondFactor` controls the second factor used for local user authentication. Possible values supported by this chart +`authentication.secondFactor` configures multi-factor authentication for local users. Possible values supported by this chart are `on`, `otp`, and `webauthn`. When set to `on` or `webauthn`, the `authenticationSecondFactor.webauthn` section can also be used. @@ -335,7 +335,7 @@ Changing the RP ID will invalidate all already registered webauthn second factor ### `authentication.webauthn` -See [Second Factor - WebAuthn](../../admin-guides/access-controls/guides/webauthn.mdx) for more details. +See [Harden your Cluster Against IdP Compromises](../../admin-guides/access-controls/guides/webauthn.mdx) for more details. #### `authentication.webauthn.attestationAllowedCas` @@ -993,7 +993,7 @@ to inject your custom configuration. `podMonitor` controls [the PodMonitor CR (from monitoring.coreos.com/v1) ](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#monitoring.coreos.com/v1.PodMonitor) -that monitors the workload (Auth and Proxy Services) deployed by the chart. +that monitors the workload (Auth Service and Proxy Service) deployed by the chart. This custom resource configures Prometheus and makes it scrape Teleport metrics. The CRD is deployed by the prometheus-operator and allows workload to diff --git a/docs/pages/reference/machine-id/configuration.mdx b/docs/pages/reference/machine-id/configuration.mdx index 5974df5f81038..6b21fceb51462 100644 --- a/docs/pages/reference/machine-id/configuration.mdx +++ b/docs/pages/reference/machine-id/configuration.mdx @@ -207,7 +207,7 @@ type: identity The `application` output is used to generate credentials that can be used to access applications that have been configured with Teleport. -See the [Machine ID with Application Access guide](../../enroll-resources/machine-id/access-guides/applications.mdx) +See the [Machine ID with Applications guide](../../enroll-resources/machine-id/access-guides/applications.mdx) to see the `application` output used in context. ```yaml @@ -227,7 +227,7 @@ app_name: grafana The `database` output is used to generate credentials that can be used to access databases that have been configured with Teleport. -See the [Machine ID with Database Access guide](../../enroll-resources/machine-id/access-guides/databases.mdx) +See the [Machine ID with Databases guide](../../enroll-resources/machine-id/access-guides/databases.mdx) to see the `database` output used in context. ```yaml @@ -273,7 +273,7 @@ access Kubernetes clusters that have been configured with Teleport. It outputs a `kubeconfig.yaml` in the output destination, which can be used with `kubectl`. -See the [Machine ID with Kubernetes Access guide](../../enroll-resources/machine-id/access-guides/kubernetes.mdx) +See the [Machine ID with Kubernetes Clusters guide](../../enroll-resources/machine-id/access-guides/kubernetes.mdx) to see the `kubernetes` output used in context. ```yaml diff --git a/docs/pages/reference/machine-id/github-actions.mdx b/docs/pages/reference/machine-id/github-actions.mdx index 7d7b82979157e..86a033d56ef3e 100644 --- a/docs/pages/reference/machine-id/github-actions.mdx +++ b/docs/pages/reference/machine-id/github-actions.mdx @@ -19,7 +19,7 @@ You can read step-by-step guides on using Machine ID and GitHub Actions: The `token` resource sets out rules for what is allowed to join a Teleport cluster. Joining clients must specify which `token` they want to use, and then information included in their join request is compared to the rules contained -within the token by the Auth Server to determine whether or not they should be +within the token by the Auth Service to determine whether or not they should be admitted. The following snippet shows all available options in the `token` resource when