diff --git a/docs/pages/access-controls/access-graph/aws-sync.mdx b/docs/pages/access-controls/access-graph/aws-sync.mdx index 640dea9d76705..ded736eab7eeb 100644 --- a/docs/pages/access-controls/access-graph/aws-sync.mdx +++ b/docs/pages/access-controls/access-graph/aws-sync.mdx @@ -14,20 +14,18 @@ enhancing the permission model within your AWS environment. This functionality e - Which resources can be reached via identities associated with EC2 instances? - What AWS resources can Teleport users access when connecting to EC2 nodes? -Utilizing the Access Graph to analyze IAM permissions within an AWS -account necessitates the setup of the Teleport Access Graph (TAG) +Utilizing the Access Graph to analyze IAM permissions within an AWS account necessitates the setup of the Access Graph (AG) service, a Discovery Service, and integration with your AWS account. -Teleport Access Graph is a feature of the [Teleport -Policy](https://goteleport.com/platform/policy/) product that is only available -to Teleport Enterprise customers. +Access Graph is a feature of the [Teleport Policy](https://goteleport.com/platform/policy/) product that is +available to Teleport Enterprise customers. After logging in to the Teleport UI, go to the Management tab. If enabled, Access Graph options can be found under the Permission Management section. ## How it works -Teleport Access Graph discovers AWS access patterns, synchronizes various AWS resources, +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 [Access Graph page](../teleport-policy/getting-started-policy.mdx). @@ -49,14 +47,12 @@ At intervals of 15 minutes, it retrieves the following resources from your AWS a - RDS Databases - S3 Buckets -Once all the necessary resources are fetched, the Teleport Discovery -Service pushes them to the Teleport Access Graph (TAG) service, -ensuring that the Access Graph remains updated with the latest -information from your AWS environment. +Once all the necessary resources are fetched, the Teleport Discovery Service pushes them to the +Access Graph, ensuring that it remains updated with the latest information from your AWS environment. ### Importing resources -Teleport Access Graph delves into the IAM policies, identities, +Teleport Policy’s Access Graph feature delves into the IAM policies, identities, and resources retrieved from your AWS account, crafting a graphical representation thereof. @@ -65,9 +61,9 @@ graphical representation thereof. - A running Teleport Enterprise cluster v14.3.9/v15.2.0 or later. - For self-hosted clusters, an updated `license.pem` with Teleport Policy enabled. -- For self-hosted clusters, a running Teleport Access Graph node v1.17.0 or later. +- For self-hosted clusters, a running Access Graph node v1.17.0 or later. Check [Access Graph page](../teleport-policy/getting-started-policy.mdx) for details on -how to setup Teleport Access Graph. +how to set up Access Graph. - The node running the Access Graph service must be reachable from Teleport Auth Service and Discovery Service. diff --git a/docs/pages/access-controls/access-graph/self-hosted-helm.mdx b/docs/pages/access-controls/access-graph/self-hosted-helm.mdx index ee7c207b05be0..06391364d7ed8 100644 --- a/docs/pages/access-controls/access-graph/self-hosted-helm.mdx +++ b/docs/pages/access-controls/access-graph/self-hosted-helm.mdx @@ -1,21 +1,19 @@ --- -title: Run Teleport Access Graph on Self-Hosted Clusters with Helm +title: Run Teleport Policy's Access Graph feature on Self-Hosted Clusters with Helm +description: How to deploy Access Graph on self-hosted clusters using Helm. --- -Using Access Graph with a self-hosted Teleport cluster requires -setting up the Teleport Access Graph (TAG) service. -TAG is a dedicated service which uses PostgreSQL as its backing storage -and communicates with Auth Service and Proxy Service +Using Teleport Policy's Access Graph with 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. -This guide will help you set up the TAG service -in a Kubernetes cluster using a Helm Chart, +This guide will help you set up the Access Graph service in a Kubernetes cluster using a Helm Chart, and enable the Access Graph feature in your Teleport cluster. -The full listing of supported parameters can be found in the [`teleport-access-graph` Helm chart reference](../../reference/helm-reference/teleport-access-graph.mdx). +The full listing of supported parameters can be found in the [Helm chart reference](../../reference/helm-reference/teleport-access-graph.mdx). -Teleport 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 [Teleport Policy](https://goteleport.com/platform/policy/) product that is only available to Teleport Enterprise customers. ## Prerequisites @@ -25,16 +23,16 @@ to Teleport Enterprise customers. - A running Teleport Enterprise cluster v14.3.6 or later. - For the purposes of this guide, we assume that the Teleport cluster is set up [using the `teleport-cluster` Helm chart](../../deploy-a-cluster/helm-deployments.mdx) - in the same Kubernetes cluster that will be used to deploy Teleport Access Graph. + in the same Kubernetes cluster that will be used to deploy Access Graph. - An updated `license.pem` with Teleport Policy 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 TAG connects to the database with needs to be the owner of this database, or have similar broad permissions: + The user that Teleport connects to the database with needs to be the owner of this database, or have similar broad permissions: at least the `CREATE TABLE` privilege on the `public` schema, and the `CREATE SCHEMA` privilege. - Amazon RDS for PostgreSQL is supported. - A TLS certificate for the Access Graph service - The TLS certificate must be issued for "server authentication" key usage, - and must contain an X.509 v3 `subjectAltName` extension with the Kubernetes service name for TAG + and must contain an X.509 v3 `subjectAltName` extension with the Kubernetes service name for Access Graph (`teleport-access-graph.teleport-access-graph.svc.cluster.local` by default). @@ -42,10 +40,10 @@ to Teleport Enterprise customers. (!docs/pages/includes/kubernetes-access/helm/helm-repo-add.mdx!) -## Step 2/4. Set up the Teleport Access Graph service +## Step 2/4. Set up Access Graph You will need a copy of your Teleport cluster's host certificate authority (CA). -TAG requires incoming connections to be authenticated via host certificates that the host CA issues to the Auth Service and Proxy Service. +Access Graph requires incoming connections to be authenticated via host certificates that the host CA issues to the Auth Service and Proxy Service. The host CA can be retrieved in one of the following ways: @@ -74,9 +72,9 @@ MIIDqjCCApKgAwIBAgIQMIK8/WiQ/rUOrjlmB0IHVTANBgkqhkiG9w0BAQsFADBv -Then, create the namespace and required secrets for the TAG deployment. +Then, create the namespace and required secrets for the Access Graph deployment. You can skip the final command if you are instead using cert-manager to issue the certificate, -or otherwise have already provisioned the TLS certificate for Teleport Access Graph in your Kubernetes cluster. +or otherwise have already provisioned the TLS certificate for Access Graph in your Kubernetes cluster. ```code $ kubectl create namespace teleport-access-graph @@ -85,10 +83,10 @@ $ kubectl -n teleport-access-graph create secret generic teleport-access-graph-p $ kubectl -n teleport-access-graph create secret tls teleport-access-graph-tls --cert=./certs/cert.crt --key=./certs/cert.key ``` -The above commands assume that you have the TLS certificate and private key for the TAG server stored under the `./certs` directory. +The above commands assume that you have the TLS certificate and private key for the Access Graph server stored under the `./certs` directory.
-The following script can be used to quickly generate a certificate authority and server TLS certificate for deploying TAG. +The following script can be used to quickly generate a certificate authority and server TLS certificate for deploying Access Graph. ```sh #!/usr/bin/env bash @@ -110,13 +108,13 @@ echo "Certificates issued successfully" The script will ask to input the same password 4 times: twice to create and confirm the password to encrypt the CA private key material with, then once to use the private key to self-sign the CA certificate, -and finally once to use for signing the TAG server certificate. +and finally once to use for signing the Access Graph server certificate. Please note that this script is only provided for proof-of-concept deployments, and may not follow the best security practices.
-After provisioning the secrets, create the following file named `tag-values.yaml` file for the TAG deployment, +After provisioning the secrets, create the following file named `tag-values.yaml` file for the Access Graph deployment, replacing the value under the `clusterHostCAs` key with the Teleport Host CA certificate retrieved previously. ```yaml @@ -138,7 +136,7 @@ clusterHostCAs: -----END CERTIFICATE----- ``` -Finally, deploy the TAG service using Helm: +Finally, deploy the Access Graph service using Helm: ```code $ helm install -n teleport-access-graph -f tag-values.yaml --version (=access_graph.version=) teleport-access-graph teleport/teleport-access-graph @@ -147,10 +145,10 @@ $ kubectl -n teleport-access-graph rollout status deployment/teleport-access-gra ## Step 3/4. Update the Teleport Auth Service configuration -To enable connectivity between the Teleport Auth Service and the Teleport Access Graph Service, +To enable connectivity between the Teleport Auth Service and the Access Graph Service, the Auth Service configuration needs to be updated with: -- The TAG service address -- The path to the CA which issued the TAG service TLS certificate. +- The Access Graph service address +- The path to the CA which issued the Access Graph service TLS certificate. - This path must refer to a volume containing the CA, mounted on the Teleport pods. - Specifying the CA certificate file can be skipped if you are using a CA that is already trusted by the Teleport cluster (e.g. via the [`tls.existingCASecretName` option](../../reference/helm-reference/teleport-cluster.mdx#tlsexistingcasecretname)), @@ -170,14 +168,14 @@ auth: teleportConfig: # <...> - # Add a section for configuring the Teleport Access Graph connection. + # Add a section for configuring the Access Graph connection. access_graph: enabled: true endpoint: teleport-access-graph.teleport-access-graph.svc.cluster.local:443 # Omit the `ca` key if your Teleport cluster already trusts the issuing CA. ca: /var/run/access-graph/ca.pem -# Provide the TAG CA to the Teleport Auth Service as a volume. +# Provide the Access Graph CA to the Teleport Auth Service as a volume. # Omit all of the below if your Teleport cluster already trusts the issuing CA. extraVolumes: - name: tag-ca diff --git a/docs/pages/access-controls/access-graph/self-hosted.mdx b/docs/pages/access-controls/access-graph/self-hosted.mdx index c722f5f6294cb..c9a1b87d45c21 100644 --- a/docs/pages/access-controls/access-graph/self-hosted.mdx +++ b/docs/pages/access-controls/access-graph/self-hosted.mdx @@ -1,20 +1,13 @@ --- -title: Run Teleport Access Graph on Self-Hosted Clusters -description: Describes how to deploy Teleport Access Graph on self-hosted clusters. +title: Run Teleport Policy on Self-Hosted Clusters +description: Describes how to deploy Access Graph on self-hosted clusters. --- -Using Access Graph with a self-hosted Teleport cluster requires -setting up the Teleport Access Graph (TAG) service. -TAG is 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. +Teleport Policy's Access Graph with 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. -This guide will help you set up the TAG service -and enable the Access Graph feature in your Teleport cluster. - -Teleport Access Graph is a feature of the [Teleport -Policy](https://goteleport.com/platform/policy/) product that is only available -to Teleport Enterprise customers. +This guide will help you set up the service and enable Access Graph in your Teleport cluster. ## Prerequisites @@ -23,12 +16,12 @@ to Teleport Enterprise customers. - 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. - The user that TAG connects to the database with needs to be the owner of this database, or have similar broad permissions: + The user that Access Graph connects to the database with needs to be the owner of this database, or have similar broad permissions: at least the `CREATE TABLE` privilege on the `public` schema, and the `CREATE SCHEMA` privilege. - Amazon RDS for PostgreSQL is supported. - A TLS certificate for the Access Graph service - The TLS certificate must be issued for "server authentication" key usage, - and must list the IP or DNS name of the TAG service in an X.509 v3 `subjectAltName` extension. + and must list the IP or DNS name of the Access Graph service in an X.509 v3 `subjectAltName` extension. - Starting from version 1.20.4 of the Access Graph service, the container runs as a non-root user by default. Make sure the certificate files are readable by the user running the container. You can set correct permissions with the following command: ```code @@ -38,14 +31,14 @@ to Teleport Enterprise customers. The deployment with Docker is suitable for testing and development purposes. For production deployments, - consider using the Teleport Access Graph Helm chart to deploy this service on Kubernetes. + consider using the Access Graph Helm chart to deploy this service on Kubernetes. Refer to [Helm chart for Access Graph](self-hosted-helm.mdx) for instructions. -## Step 1/3. Set up the Teleport Access Graph service +## Step 1/3. Set up Access Graph You will need a copy of your Teleport cluster's host certificate authority (CA) on the machine that hosts the Access Graph service. -TAG requires incoming connections to be authenticated via host certificates that the host CA issues to the Auth Service and Proxy Service. +The service requires incoming connections to be authenticated via host certificates that the host CA issues to the Auth Service and Proxy Service. The host CA can be retrieved and saved into a file in one of the following ways: @@ -68,7 +61,7 @@ $ tctl get cert_authorities --format=json \ -Then, on the same machine, create a configuration file for the TAG service, similar to this: +Then, on the same machine, create a configuration file for the Access Graph service, similar to this: ```yaml backend: @@ -83,22 +76,22 @@ backend: # iam: # aws_region: us-west-2 -# IP address (optional) and port for the TAG service to listen to. +# IP address (optional) and port for the Access Graph service to listen to. # This is the default value. This key can be omitted to listen on port 50051 on all interfaces. address: ":50051" tls: - # File paths of PEM-encoded TLS certificate and private key for the TAG server. + # File paths of PEM-encoded TLS certificate and private key for the Access Graph server. cert: /etc/access_graph/tls.crt key: /etc/access_graph/tls.key -# This lists the file paths for host CAs of Teleport clusters that are allowed to register with this TAG service. -# Several paths can be included to allow several Teleport clusters to connect to the TAG service. +# This lists the file paths for host CAs of Teleport clusters that are allowed to register with this Access Graph service. +# Several paths can be included to allow several Teleport clusters to connect to the Access Graph service. registration_cas: - /etc/access_graph/teleport_host_ca.pem # A full path to the file containing the Teleport cluster's host CA certificate. ``` -Finally, start the TAG service using Docker as follows: +Finally, start the Access Graph service using Docker as follows: ```console $ docker run -p 50051:50051 -v :/app/config.yaml -v /etc/access_graph:/etc/access_graph public.ecr.aws/gravitational/access-graph:(=access_graph.version=) @@ -111,9 +104,9 @@ In the YAML config for the Auth Service, add a new top-level section for Access ```yaml access_graph: enabled: true - # host:port where the TAG service is listening + # host:port where the Access Graph service is listening endpoint: access-graph.example.com:50051 - # Specify a trusted CA we expect the TAG server certificate to be signed by. + # Specify a trusted CA we expect the Access Graph server certificate to be signed by. # If not specified, the system trust store will be used. ca: /etc/access_graph_ca.pem ``` diff --git a/docs/pages/access-controls/teleport-policy/getting-started-policy.mdx b/docs/pages/access-controls/teleport-policy/getting-started-policy.mdx index 29219305e0fca..9d627f1b67490 100644 --- a/docs/pages/access-controls/teleport-policy/getting-started-policy.mdx +++ b/docs/pages/access-controls/teleport-policy/getting-started-policy.mdx @@ -3,8 +3,8 @@ title: Teleport Policy description: A reference for Access Graph with Teleport Policy. --- -Teleport Policy streamlines and centralizes access management across your entire infrastructure. Access Graph provides a -visual representation of the relationships between users, roles, and resources in your organization. +Teleport Policy unifies management of access policies across your infrastructure. +It hardens your access controls and visually shows up-to-date relationships and policies of all users, groups, and computing resources It can help you answer questions like: - What resources can a specific user access? @@ -13,15 +13,16 @@ It can help you answer questions like: ## Getting started with Teleport Policy -Access Graph is a feature of the Teleport Policy product that is only -available to Teleport Enterprise customers. +Teleport Policy is a separately licensed product and is available to Teleport Enterprise customers. +Access Graph is a major capability of Teleport Policy that visually shows the relationships of +policies of users, groups, and computing resources. -After logging into the Teleport UI, go to the Management tab. If enabled, Access Graph options can be found -under the Permission Management section. +After logging into the Teleport UI, go to the Management tab. If enabled, Teleport Policy’s Access Graph options +can be found under the Permission Management section. -Note: For managed Teleport Enterprise customers, Access Graph is enabled by default. -If you are a self-hosted Teleport customer, you will need to set up [Access Graph](../access-graph/self-hosted.mdx) and ensure you have an updated +Note: For managed Enterprise customers, Teleport Policy is enabled by default. +If you are a self-hosted Teleport customer, you will need to set up [Teleport Policy’s Access Graph](../access-graph/self-hosted.mdx) and ensure you have an updated `license.pem` with Teleport Policy enabled to use it. diff --git a/docs/pages/access-controls/teleport-policy/policy-connections.mdx b/docs/pages/access-controls/teleport-policy/policy-connections.mdx index 3d9000872ced2..37fae4539620d 100644 --- a/docs/pages/access-controls/teleport-policy/policy-connections.mdx +++ b/docs/pages/access-controls/teleport-policy/policy-connections.mdx @@ -3,9 +3,9 @@ title: Teleport Policy Connections description: Connections in Access Graph with Teleport Policy. --- -Teleport Access Graph shows the relationships between users, roles, and -resources. It does this by showing paths between nodes. Paths are the -relationships between nodes. Paths always connect nodes in the following order: +Teleport Policy's Access Graph feature feature shows the relationships between users, roles, and resources. +It does this by showing paths between nodes. Paths are the relationships between nodes. +Paths always connect nodes in the following order: ## Connecting to resources @@ -32,7 +32,7 @@ Deny paths connect identities to resources. They show what an identity cannot ac ## How resources and identities are represented Access Graph imports all resources and identities from Teleport and keeps them up to date, so every time you make a change -to your Teleport resources, the Access Graph will reflect those changes. +to your Teleport resources, the Graph will reflect those changes. ### Identities @@ -76,4 +76,4 @@ Resource Groups are created from Teleport roles. Resources are created from Teleport resources like nodes, databases, and Kubernetes clusters. ## Next steps -- Uncover [privileges, permissions, and construct SQL queries](./policy-how-to-use.mdx) in Access Graph. \ No newline at end of file +- Uncover [privileges, permissions, and construct SQL queries](./policy-how-to-use.mdx) in Teleport Policy. \ No newline at end of file diff --git a/docs/pages/access-controls/teleport-policy/policy-how-to-use.mdx b/docs/pages/access-controls/teleport-policy/policy-how-to-use.mdx index 1dc801a7a09fb..c93ef36bb218e 100644 --- a/docs/pages/access-controls/teleport-policy/policy-how-to-use.mdx +++ b/docs/pages/access-controls/teleport-policy/policy-how-to-use.mdx @@ -3,16 +3,15 @@ title: Teleport Policy Usage description: Using Access Graph with Teleport Policy. --- -Policy use with the Access Graph provides a framework for visualizing and managing -access controls across an organization’s infrastructure. +Teleport Policy provides a framework for visualizing and managing access controls across an organization’s infrastructure. This interface allows administrators to quickly identify and address potential security risks, such as overly broad permissions or conflicting roles, ensuring that access is granted on principles of least privilege. -## How to use Policy with Access Graph +## How to use Teleport Policy feature -Teleport Access Graph can help you to answer questions like: +Teleport Policy's Access Graph feature can help you to answer questions like: - Who can access a specific resource? @@ -50,7 +49,7 @@ You can then search through all node types and all imported entities. ## Graph nodes -Teleport Access Graph divides your infrastructure into six main components: +Access Graph divides your infrastructure into six main components: 1. Identities diff --git a/docs/pages/access-controls/teleport-policy/policy-integrations.mdx b/docs/pages/access-controls/teleport-policy/policy-integrations.mdx index 6da759e2d91dd..a3b2a732f6754 100644 --- a/docs/pages/access-controls/teleport-policy/policy-integrations.mdx +++ b/docs/pages/access-controls/teleport-policy/policy-integrations.mdx @@ -12,11 +12,11 @@ enabling administrators to better understand and control access policies. ![Integrations](../../../img/access-graph/integrations.png) -Integrations page shows integrations that can be enabled or are already enabled in Access Graph. +The integrations page shows integrations that can be enabled or are already enabled in Access Graph. Resources imported into Teleport through Teleport enabled integrations are automatically imported into -Access graph without any additional configuration. +Teleport Policy without any additional configuration. ## Set up a new integration @@ -70,4 +70,4 @@ The preset `editor` role has the required permissions by default. Teleport can also import and grant access to resources from an Okta organizations, such as user profiles, groups and applications. You can view connection data in Access Graph. Follow the steps here to add an (../../enroll-resources/application-access/okta/hosted-guide.mdx) in your cluster. ## Next steps -- Explore [connections and resource paths](./policy-connections.mdx) with Access Graph. +- Explore [connections and resource paths](./policy-connections.mdx) with Teleport Policy. diff --git a/docs/pages/index.mdx b/docs/pages/index.mdx index 058563e2f7e15..ec8f5ea9e4660 100644 --- a/docs/pages/index.mdx +++ b/docs/pages/index.mdx @@ -102,7 +102,7 @@ Get started with Teleport Identity: ### Teleport Policy **Teleport Policy** unifies and controls access policies across all your -infrastructure. With Teleport Access Graph, you gain insights into role-based +infrastructure. With Teleport Policy’s Access Graph feature, you gain insights into role-based access control policies within Teleport and your cloud provider. Get started with [Teleport Policy](./access-controls/teleport-policy/getting-started-policy.mdx). diff --git a/docs/pages/reference/helm-reference.mdx b/docs/pages/reference/helm-reference.mdx index 0ce1c64dc2991..06ecd477ee012 100644 --- a/docs/pages/reference/helm-reference.mdx +++ b/docs/pages/reference/helm-reference.mdx @@ -13,7 +13,7 @@ layout: tocless-doc - [teleport-operator](./helm-reference/teleport-operator.mdx): Deploy the Teleport Kubernetes Operator. - [teleport-access-graph](./helm-reference/teleport-access-graph.mdx): Deploy the - Teleport Access Graph service. + Teleport Policy Access Graph service. - [teleport-plugin-event-handler](./helm-reference/teleport-plugin-event-handler.mdx): Deploy the Teleport Event Handler plugin which sends events and session logs to Fluentd. diff --git a/docs/pages/reference/helm-reference/includes/zz_generated.teleport-access-graph.mdx b/docs/pages/reference/helm-reference/includes/zz_generated.teleport-access-graph.mdx index ebf3e078a56ad..bcfb1f5ef105a 100644 --- a/docs/pages/reference/helm-reference/includes/zz_generated.teleport-access-graph.mdx +++ b/docs/pages/reference/helm-reference/includes/zz_generated.teleport-access-graph.mdx @@ -14,7 +14,7 @@ containing the certificate and its private key to use for the gRPC listener. The secret must be of type `kubernetes.io/tls`, see [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for more details. -Setting this is required, as Teleport Access Graph always operates via TLS-protected connections. +Setting this is required, as Access Graph always operates via TLS-protected connections. ## `clusterHostCAs` @@ -22,7 +22,7 @@ Setting this is required, as Teleport Access Graph always operates via TLS-prote |------|---------| | `array` | `[]` | -`clusterHostCAs` is a list of strings containing PEM-encoded Host CA certificates of Teleport clusters that are allowed to use this instance of TAG. +`clusterHostCAs` is a list of strings containing PEM-encoded Host CA certificates of Teleport clusters that are allowed to use this instance of Access Graph. Setting this to a non-empty array is required. ## `service` @@ -31,7 +31,7 @@ Setting this to a non-empty array is required. |------|---------| | `object` | `{"grpcPort":443,"type":"ClusterIP"}` | -`service` contains options for the TAG Kubernetes service that the Chart exposes. +`service` contains options for the Access Graph Kubernetes service that the Chart exposes. ### `service.type` @@ -41,7 +41,7 @@ Setting this to a non-empty array is required. `service.type` the type of Kubernetes service to create. The `LoadBalancer` type is only supported when using a Layer 4 (TCP) or lower load balancer. -TAG expects to terminate its own TLS, as it uses mTLS to authenticate its clients. +Access Graph expects to terminate its own TLS, as it uses mTLS to authenticate its clients. ### `service.grpcPort` @@ -50,7 +50,7 @@ TAG expects to terminate its own TLS, as it uses mTLS to authenticate its client | `int` | `443` | `service.grpcPort` the port that the gRPC service is exposed on. -This is the port that Teleport Auth Service and Proxy Service will need to connect to TAG on. +This is the port that Teleport Auth Service and Proxy Service will need to connect to Access Graph on. ## `replicaCount` @@ -58,7 +58,7 @@ This is the port that Teleport Auth Service and Proxy Service will need to conne |------|---------| | `int` | `2` | -`replicaCount` the number of TAG pods that should be deployed. +`replicaCount` the number of Access Graph pods that should be deployed. ## `image` @@ -68,8 +68,8 @@ This is the port that Teleport Auth Service and Proxy Service will need to conne |------|---------| | `string` | `""` | -`image.tag` sets the version of the Teleport Access Graph image used. -By default, this is the same as the Helm Chart version, i.e. TAG will be upgraded when you upgrade the Helm chart. +`image.tag` sets the version of the Access Graph image used. +By default, this is the same as the Helm Chart version, i.e. Access Graph will be upgraded when you upgrade the Helm chart. ## `podAnnotations` diff --git a/docs/pages/reference/helm-reference/teleport-access-graph.mdx b/docs/pages/reference/helm-reference/teleport-access-graph.mdx index ea7fb54acad25..80cf463094fc2 100644 --- a/docs/pages/reference/helm-reference/teleport-access-graph.mdx +++ b/docs/pages/reference/helm-reference/teleport-access-graph.mdx @@ -3,13 +3,13 @@ title: teleport-access-graph Chart Reference description: Values that can be set using the teleport-access-graph Helm chart --- -The `teleport-access-graph` Helm chart deploys the Teleport Access Graph service. +The `teleport-access-graph` Helm chart deploys the Access Graph service. -See [Run Teleport Access Graph on Self-Hosted Clusters with Helm](../../access-controls/access-graph/self-hosted-helm.mdx) +See [Teleport Policy's Access Graph on Self-Hosted Clusters with Helm](../../access-controls/access-graph/self-hosted-helm.mdx) for more details. -The chart is versioned with the Teleport Access Graph service. No compatibility +The chart is versioned with the Access Graph service. No compatibility guarantees are ensured if the service and chart versions differ. It is strongly recommended to always align the chart and service versions by using the `--version` Helm flag. diff --git a/docs/pages/reference/user-types.mdx b/docs/pages/reference/user-types.mdx index c1a9b47c2ff89..3469815511c0b 100644 --- a/docs/pages/reference/user-types.mdx +++ b/docs/pages/reference/user-types.mdx @@ -82,7 +82,7 @@ integration are: - Automatic user locking and deletion if the user is suspended or removed in the IdP. - Ability to see all users within Teleport regardless of the last login date. -- All IdP users are displayed in Teleport Access Graph. +- All IdP users are displayed in Teleport Policy's Access Graph. The Okta synchronization service is in charge of creating new users when they are created in Okta, and locking/deleting users if they get deactivated/removed