mirror of
https://github.com/gravitational/teleport.git
synced 2026-10-12 02:15:01 +00:00
docs: fixes for grammar and references (#64668)
* docs: fixes for grammer and references * docs: fix grammer for okta guided * docs: reverting auto generated file * docs: correct roles-requests, user-sync and ssh-keys-scan * docs: restore troubleshooting
This commit is contained in:
+2
-2
@@ -66,9 +66,9 @@ When you click "Deploy Teleport Service" the wizard creates an ECS task
|
||||
definition that includes various settings for configuring and starting a
|
||||
Teleport Database Service instance.
|
||||
The task definition uses the IAM role created in the first step as both the
|
||||
[ECS task execution role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html).
|
||||
[ECS task execution role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html)
|
||||
and the
|
||||
[ECS task role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)
|
||||
[ECS task role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html).
|
||||
|
||||
The wizard then creates an ECS deployment in the same AWS VPC as your RDS
|
||||
databases, configured to use the subnets and security groups you chose.
|
||||
|
||||
@@ -14,7 +14,7 @@ tags:
|
||||
|
||||
In this guide, you will:
|
||||
|
||||
1. Create an Azure managed identity for user access and attach it your VM.
|
||||
1. Create an Azure managed identity for user access and attach it to your VM.
|
||||
1. Deploy the Teleport Application Service with an Azure app in your Teleport cluster.
|
||||
1. Assume the managed identity and run `az` commands via `tsh`.
|
||||
|
||||
|
||||
@@ -404,7 +404,7 @@ service accounts you have assigned to the user.
|
||||
Create the role:
|
||||
|
||||
```code
|
||||
$ tctl create -f google-cloud-cli-access
|
||||
$ tctl create -f google-cloud-cli-access.yaml
|
||||
```
|
||||
|
||||
(!docs/pages/includes/create-role-using-web.mdx!)
|
||||
|
||||
@@ -32,7 +32,7 @@ joins your Teleport cluster with a secure token. You configure the Application
|
||||
Service to protect a web application using a configuration file. After the
|
||||
Application Service joins the cluster, the Teleport Proxy Service routes
|
||||
requests from end users to the Teleport Application Service, and responses from
|
||||
the Application Serve back to end users.
|
||||
the Application Service back to end users.
|
||||
|
||||
The Application Service authenticates user requests by validating a JSON web
|
||||
token (JWT) in the request against a CA maintained by the Teleport Auth Service.
|
||||
|
||||
@@ -221,7 +221,7 @@ will depend on your specific networking setup.
|
||||
|
||||
### Create a Teleport config file
|
||||
|
||||
Create a `teleport.yaml` config file on the host that will run the Discovery
|
||||
Create a `teleport.yaml` config file on the host that will run the Database
|
||||
Service:
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -95,7 +95,7 @@ discovery_service:
|
||||
# 'elasticache' - Amazon ElastiCache Redis and Valkey databases.
|
||||
# 'elasticache-serverless' - Amazon ElastiCache Serverless Redis or Valkey databases.
|
||||
# 'memorydb' - Amazon MemoryDB Redis databases.
|
||||
# 'opensearch' - Amazon OpenSearch Redis databases.
|
||||
# 'opensearch' - Amazon OpenSearch databases.
|
||||
# 'docdb' - Amazon DocumentDB databases.
|
||||
- types: ["rds"]
|
||||
# AWS regions to search for resources from
|
||||
|
||||
@@ -67,8 +67,8 @@ app_service:
|
||||
enabled: true
|
||||
resources:
|
||||
- labels:
|
||||
"teleport.dev/kubernetes-cluster": "main-cluster"
|
||||
"teleport.dev/origin": "discovery-kubernetes"
|
||||
"teleport.dev/kubernetes-cluster": "main-cluster"
|
||||
"teleport.dev/origin": "discovery-kubernetes"
|
||||
```
|
||||
|
||||
Label `teleport.dev/kubernetes-cluster` should match value of `discovery_group` field in the Discovery Service config.
|
||||
|
||||
+1
-1
@@ -234,7 +234,7 @@ $ sudo teleport discovery bootstrap
|
||||
Restart the Teleport service to start discovering new instances:
|
||||
|
||||
```code
|
||||
$ sudo systemd restart teleport
|
||||
$ sudo systemctl restart teleport
|
||||
```
|
||||
|
||||
You can check the status of the Discovery Service with `systemctl status teleport`
|
||||
|
||||
+1
-1
@@ -217,7 +217,7 @@ mainSteps:
|
||||
Restart the Teleport service to start discovering new instances:
|
||||
|
||||
```code
|
||||
$ sudo systemd restart teleport
|
||||
$ sudo systemctl restart teleport
|
||||
```
|
||||
|
||||
You can check the status of the Discovery Service with `systemctl status teleport`
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Databases
|
||||
description: Provide secure connections to database by improving access control and visibility
|
||||
description: Provide secure connections to databases by improving access control and visibility
|
||||
template: doc-page
|
||||
tags:
|
||||
- zero-trust
|
||||
|
||||
@@ -211,7 +211,7 @@ $ tsh db connect --db-user=teleport-docdb-user --db-name=test my-docdb
|
||||
Log out of the database and remove credentials:
|
||||
|
||||
```code
|
||||
$ tsh db logout rds-example
|
||||
$ tsh db logout my-docdb
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
@@ -92,7 +92,7 @@ GRANT rds_iam TO alice;
|
||||
For more information about connecting to the PostgreSQL instance directly,
|
||||
see the AWS [documentation](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToPostgreSQLInstance.html).
|
||||
|
||||
See the [Automatic User Provisioning](./rbac.mdx) guide for how to configure Teleport to create accounts for your PostgreSQL users on demand.
|
||||
See the [Automatic User Provisioning](./auto-user-provisioning/postgres.mdx) guide for how to configure Teleport to create accounts for your PostgreSQL users on demand.
|
||||
|
||||
## Step 2/5. Configure the Teleport Database Service
|
||||
|
||||
|
||||
@@ -1291,4 +1291,5 @@ spec:
|
||||
- kind: pod
|
||||
namespace: "default"
|
||||
name: "*"
|
||||
``` # ...
|
||||
# ...
|
||||
```
|
||||
|
||||
@@ -211,7 +211,7 @@ metadata:
|
||||
name: default-kube
|
||||
spec:
|
||||
match:
|
||||
disable: true
|
||||
disabled: true
|
||||
kubernetes_labels:
|
||||
- name: '*'
|
||||
values:
|
||||
|
||||
@@ -13,7 +13,7 @@ and one or more Kubernetes clusters.
|
||||
|
||||
In this guide, we will use a local Kubernetes cluster to show you how to
|
||||
configure Teleport's role-based access control (RBAC) system to manage access to
|
||||
Kubernetes clusers, groups, users, and resources.
|
||||
Kubernetes clusters, groups, users, and resources.
|
||||
|
||||
## How it works
|
||||
|
||||
|
||||
+1
-1
@@ -52,7 +52,7 @@ Use this command to switch to the cluster assigned to
|
||||
|
||||
```code
|
||||
# e.g., my-context
|
||||
$ kubectl config use-context <Var name="context-name" />}
|
||||
$ kubectl config use-context <Var name="context-name" />
|
||||
```
|
||||
|
||||
### Run the script
|
||||
|
||||
@@ -125,7 +125,7 @@ another group is used instead.
|
||||
|
||||
Per the description above, the solution is to configure a different group for
|
||||
impersonation in Teleport. This can be done by setting the role's
|
||||
`kubernetes_group` parameter to a Group that the Autopilot cluster allows to
|
||||
`kubernetes_groups` parameter to a Group that the Autopilot cluster allows to
|
||||
impersonate.
|
||||
|
||||
The `teleport-kube-agent` chart configures a Kubernetes Group with the same access
|
||||
|
||||
@@ -10,7 +10,7 @@ tags:
|
||||
|
||||
Teleport can provide secure access to MCP servers with SSE transport.
|
||||
|
||||
This guides shows you how to:
|
||||
This guide shows you how to:
|
||||
|
||||
- Enroll a MCP server with SSE transport in your Teleport cluster.
|
||||
- Connect to the SSE MCP server via Teleport.
|
||||
|
||||
@@ -10,7 +10,7 @@ tags:
|
||||
|
||||
Teleport can provide secure access to MCP servers with stdio transport.
|
||||
|
||||
This guides shows you how to:
|
||||
This guide shows you how to:
|
||||
|
||||
- Enroll a MCP server with stdio transport in your Teleport cluster.
|
||||
- Connect to the stdio MCP server via Teleport.
|
||||
|
||||
@@ -10,10 +10,10 @@ tags:
|
||||
|
||||
Teleport can provide secure access to MCP servers with streamable-HTTP transport.
|
||||
|
||||
This guides shows you how to:
|
||||
This guide shows you how to:
|
||||
|
||||
- Enroll a MCP server with streamable-HTTP transport in your Teleport cluster.
|
||||
- Connect to the stdio MCP server via Teleport.
|
||||
- Connect to the streamable-HTTP MCP server via Teleport.
|
||||
|
||||
## How it works
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ tags:
|
||||
Teleport can provide secure connections to your MCP (Model Context Protocol)
|
||||
servers while improving both access control and visibility.
|
||||
|
||||
This guides shows you how to:
|
||||
This guide shows you how to:
|
||||
|
||||
- Enroll the Teleport demo MCP server in your Teleport cluster.
|
||||
- Connect to the MCP server via Teleport.
|
||||
|
||||
@@ -103,7 +103,7 @@ spec:
|
||||
|
||||
Create the `app` resource with:
|
||||
```code
|
||||
$ tctl create -f app-bedrock-app.yaml
|
||||
$ tctl create -f app-bedrock-mcp.yaml
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ spec:
|
||||
|
||||
(!docs/pages/includes/mcp-access/integration-tsh.mdx service="github" serviceName="GitHub" !)
|
||||
|
||||

|
||||

|
||||
|
||||
## Connect to GitHub without service account
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ tags:
|
||||
You can protect a server with Teleport by running the Teleport SSH Service on
|
||||
the server and enrolling it in your Teleport cluster.
|
||||
|
||||
This guides shows you how to:
|
||||
This guide shows you how to:
|
||||
|
||||
- Enroll a server in your Teleport cluster.
|
||||
- SSH into a server using Teleport.
|
||||
|
||||
@@ -76,7 +76,7 @@ ssh_service:
|
||||
service_name: "sshd"
|
||||
```
|
||||
|
||||
PAM-generated events depend on your `sshd` configuration when the integration is enabled. Most system generates events
|
||||
PAM-generated events depend on your `sshd` configuration when the integration is enabled. Most systems generate events
|
||||
like `USER_ACCT` or `USER_START`. Additionally, TTY input can be logged by enabling the `pam_tty_audit.so` module.
|
||||
|
||||
For more details please refer to [PAM](ssh-pam.mdx#set-up-pam-on-a-linux-machine-running-teleport) or your operating system
|
||||
|
||||
@@ -94,7 +94,7 @@ Below, you can find the IAM permissions that allow the Auth Service to execute A
|
||||
],
|
||||
"Effect": "Allow",
|
||||
"Resource": [
|
||||
"arn:aws:s3::::audit-transient/results/*",
|
||||
"arn:aws:s3:::audit-transient/results/*",
|
||||
"arn:aws:s3:::audit-long-term/report_results/*"
|
||||
]
|
||||
},
|
||||
|
||||
@@ -55,7 +55,7 @@ roles—by using the following configuration options:
|
||||
- `deny.request.claims_to_roles`
|
||||
|
||||
Here is an example, which allows the `employee` user to request the `dev` and
|
||||
`dba` role, and specifies some more complex restrictions that we will explain
|
||||
`dba` roles, and specifies some more complex restrictions that we will explain
|
||||
below:
|
||||
|
||||
```yaml
|
||||
@@ -436,7 +436,7 @@ Each threshold includes the following fields:
|
||||
|
||||
In the `devops` role above, there are two thresholds associated with the
|
||||
`dbadmin` role. As a result, one of the following conditions must obtain before
|
||||
the request is approved is denied:
|
||||
the request is approved or denied:
|
||||
|
||||
1. Three users must approve the request, and two users must deny it, as long as
|
||||
those users do not have a `team` trait with the value `dev`.
|
||||
@@ -764,7 +764,7 @@ func getMyAnnotation(req types.AccessRequest) ([]string, error) {
|
||||
|
||||
This function uses the `GetSystemAnnotations` method of the
|
||||
`types.AccessRequest` type to get all the annotation values of an Access
|
||||
Requests with the key `my-annotation`.
|
||||
Request with the key `my-annotation`.
|
||||
|
||||
## Further reading
|
||||
|
||||
|
||||
@@ -208,7 +208,7 @@ approve or deny the request:
|
||||
|
||||
When the Datadog plugin sends a notification, anyone who receives the
|
||||
notification can follow the enclosed link to an Access Request URL. While users
|
||||
must be authorized via their Teleport roles to review Access Request, you
|
||||
must be authorized via their Teleport roles to review Access Requests, you
|
||||
should still check the Teleport audit log to ensure that the right users are
|
||||
reviewing the right requests.
|
||||
|
||||
|
||||
@@ -265,7 +265,7 @@ the spreadsheet ID, visit your spreadsheet in Google Drive. The ID will be in
|
||||
the URL path segment called `SPREADSHEET_ID` below:
|
||||
|
||||
```text
|
||||
https://docs.google.com/spreadsheets/d/SPREADHSEET_ID/edit#gid=0
|
||||
https://docs.google.com/spreadsheets/d/SPREADSHEET_ID/edit#gid=0
|
||||
```
|
||||
|
||||
### The `AccessRequestPlugin` type
|
||||
|
||||
@@ -120,7 +120,7 @@ or in the schedules specified by `teleport.dev/notify-services` annotation in th
|
||||
|
||||
When the Opsgenie plugin sends a notification, anyone who receives the
|
||||
notification can follow the enclosed link to an Access Request URL. While users
|
||||
must be authorized via their Teleport roles to review Access Request, you
|
||||
must be authorized via their Teleport roles to review Access Requests, you
|
||||
should still check the Teleport audit log to ensure that the right users are
|
||||
reviewing the right requests.
|
||||
|
||||
|
||||
@@ -540,7 +540,7 @@ $ kubectl logs deploy/teleport-plugin-pagerduty
|
||||
```
|
||||
|
||||
Debug logs can be enabled by setting `log.severity` to `DEBUG` in
|
||||
`teleport-pagerduty-helm.yaml` and executing the `helm upgrade ...` command
|
||||
`teleport-pagerduty-values.yaml` and executing the `helm upgrade ...` command
|
||||
above again. Then you can restart the plugin with the following command:
|
||||
|
||||
```code
|
||||
|
||||
@@ -29,7 +29,7 @@ ServiceNow.
|
||||
|
||||
(!docs/pages/includes/edition-prereqs-tabs.mdx edition="Teleport Enterprise"!)
|
||||
|
||||
- An ServiceNow account with access to read and write to and from the 'incident' table.
|
||||
- A ServiceNow account with access to read and write to and from the 'incident' table.
|
||||
- (!docs/pages/includes/tctl.mdx!)
|
||||
|
||||
## Step 1/4. Create services
|
||||
|
||||
@@ -183,7 +183,7 @@ iot:~ alice$
|
||||
```
|
||||
|
||||
Note that in order to make a Role Access Request this way, the role you request
|
||||
access with must have `search_as_role` set so you can read the node you want to
|
||||
access with must have `search_as_roles` set so you can read the node you want to
|
||||
ssh into.
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -114,14 +114,14 @@ As a first step of the SAML Application setup wizard, the Teleport Web UI displa
|
||||
the Teleport SAML IdP metadata values.
|
||||
|
||||
The process of SAML service provider configuration varies from service provider
|
||||
to service provider. Some service provider may ask to provide Teleport SAML IdP's
|
||||
entity ID, SSO URL and X.509 certificate explicitly. Other's may ask to upload
|
||||
to service provider. Some service providers may ask to provide Teleport SAML IdP's
|
||||
entity ID, SSO URL and X.509 certificate explicitly. Others may ask to upload
|
||||
the Teleport SAML IdP metadata (SAML entity descriptor) file .
|
||||
|
||||

|
||||
|
||||
In the case of IAMShowcase app, which this guide is
|
||||
based on, it is designed to grant access protected page for any well formatted
|
||||
based on, it is designed to grant access to the protected page for any well formatted
|
||||
IdP federated SAML assertion data.
|
||||
|
||||
As such, we will move to the next step in the setup wizard to add the IAMShowcase app to Teleport.
|
||||
|
||||
@@ -95,7 +95,7 @@ the SAML IdP service provider resource.
|
||||
In this case, the role needs to target `saml_idp_service_provider` resource with
|
||||
either `create,update,read,list,delete` or all of them as needed.
|
||||
|
||||
The role should also grants access to the `app_labels` that matches with the
|
||||
The role should also grant access to the `app_labels` that matches with the
|
||||
resource label configured for the `saml_idp_service_provider` resource.
|
||||
|
||||
`saml_idp_service_provider` resource access verb
|
||||
|
||||
@@ -57,7 +57,7 @@ Create it with `tctl`:
|
||||
|
||||
```code
|
||||
$ tctl create sp-manager.yaml
|
||||
role 'saml-idp-service-provider-manager' has been created
|
||||
role 'sp-manager' has been created
|
||||
```
|
||||
|
||||
(!docs/pages/includes/create-role-using-web.mdx!)
|
||||
|
||||
@@ -26,10 +26,10 @@ Teleport.
|
||||
|
||||
Authentication is based on the [interactive sign-in](
|
||||
https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli-interactively)
|
||||
process. User audit events in Azure are tagged on behalf of Teleport user account,
|
||||
process. User audit events in Azure are tagged on behalf of the Teleport user account,
|
||||
providing better audit visibility.
|
||||
|
||||
Alternatively, you can also manage access to Azure API and CLI by deploying the
|
||||
Alternatively, you can also manage access to the Azure API and CLI by deploying the
|
||||
[Teleport Application Service](../../../enroll-resources/application-access/cloud-apis/azure.mdx).
|
||||
This approach supports access based on [managed identity](
|
||||
https://learn.microsoft.com/en-us/cli/azure/authenticate-azure-cli-managed-identity),
|
||||
@@ -100,7 +100,7 @@ You can locate **Microsoft Entra External ID** in Azure portal under Azure servi
|
||||
|
||||

|
||||
|
||||
Note that while adding Teleport as an identity provider, you need to provide domain name
|
||||
Note that while adding Teleport as an identity provider, you need to provide a domain name
|
||||
as explained in the Step 1 of this guide.
|
||||
|
||||
Once you add Teleport as SAML IdP in Microsoft Entra External ID, you will need to copy the Entra ID `Tenant ID` from
|
||||
@@ -136,7 +136,7 @@ From the **Users** page, click `+ New User` button and select "Invite external u
|
||||
|
||||

|
||||
|
||||
Enter the details for this user as needed to set up the account. You will notice that the a default value for
|
||||
Enter the details for this user as needed to set up the account. You will notice that the default value for
|
||||
the "Invite redirect URL" field that points to `https://myapplications.microsoft.com/` is set for this user.
|
||||
This URL is where Microsoft will redirect the user after their first authentication. You can update this URL
|
||||
if you wish to redirect user to a different URL or keep it as it is.
|
||||
@@ -193,7 +193,7 @@ resource under the `teleport-dev-vm-pool` resource group with the privilege gran
|
||||
|
||||
The Microsoft Entra External ID must be linked with an existing billing subscription.
|
||||
|
||||
This is required so the users can access and billed for Azure resources available under the linked subscription.
|
||||
This is required so the users can access and be billed for Azure resources available under the linked subscription.
|
||||
|
||||

|
||||
|
||||
@@ -258,7 +258,7 @@ Note that the rules of DNS update apply here as well.
|
||||
|
||||
### Issues related to identity provider configuration
|
||||
|
||||
Refer to official the [Microsoft Entra External ID SAML federation](https://learn.microsoft.com/en-us/entra/external-id/direct-federation) docs for general configuration.
|
||||
Refer to the official [Microsoft Entra External ID SAML federation](https://learn.microsoft.com/en-us/entra/external-id/direct-federation) docs for general configuration.
|
||||
|
||||
### Issues related to user invitation and user type conversion
|
||||
For issues related to user invitation, or internal to external user type conversion, refer to the [Microsoft Entra B2B collaboration](https://learn.microsoft.com/en-us/entra/external-id/troubleshoot) troubleshooting docs.
|
||||
|
||||
+1
-1
@@ -9,7 +9,7 @@ enterprise: Identity Governance
|
||||
---
|
||||
|
||||
The Identity Center Integration can be configured to handle various advanced use
|
||||
cases that are ot necessarily supported by the default installation flow. This
|
||||
cases that are not necessarily supported by the default installation flow. This
|
||||
guide describes these advanced options and use cases.
|
||||
|
||||
## Disabling Account Assignment role creation
|
||||
|
||||
@@ -363,7 +363,7 @@ into a single Identity Center group containing all members reachable from the
|
||||
top-level Access List.
|
||||
|
||||
The flattened Identity Center group will be kept updated as members are added to
|
||||
or removed from nested
|
||||
or removed from nested Access Lists.
|
||||
|
||||
### How does Teleport handle failures caused by transient network or load issues?
|
||||
|
||||
|
||||
+3
-3
@@ -14,7 +14,7 @@ This guide describes how to introduce Teleport into an existing Okta-managed AWS
|
||||
IAM Identity Center configuration. It specifically describes two scenarios: one where
|
||||
Teleport shares control of your Identity Center managed resources in conjunction
|
||||
with Okta, and another where Teleport replaces Okta as the Identity Center SSO
|
||||
Provider and user provisioner
|
||||
Provider and user provisioner.
|
||||
|
||||
## How it works
|
||||
|
||||
@@ -51,7 +51,7 @@ Center groups and manage Group membership.
|
||||
|
||||
We will start by setting up Teleport, Okta and Identity Center in a Partial hand-off
|
||||
configuration, covering
|
||||
- integrating Okta and Teleport, ensuring that all users Okta users provisioned
|
||||
- integrating Okta and Teleport, ensuring that all Okta users provisioned
|
||||
into Identity Center are also provisioned into Teleport,
|
||||
- configuring Teleport to manage groups and account assignments in Identity Center
|
||||
- setting up Teleport group import rules so that Identity Center groups managed
|
||||
@@ -394,7 +394,7 @@ restart the Identity Center integration in Full Hand-Off mode.
|
||||
Once Teleport has full control over provisioning into Identity Center, you can
|
||||
deactivate the Identity Center integration in Okta. Leaving the Okta Identity
|
||||
Center integration in place will cause Teleport and Okta to both try and control
|
||||
the user information
|
||||
the user information.
|
||||
|
||||
## Extending the integration
|
||||
|
||||
|
||||
+4
-4
@@ -18,7 +18,7 @@ access granted via Teleport and AWS Identity Center.
|
||||
For a deep dive into how Teleport manages AWS Identity Center access works you can
|
||||
read the main [AWS IAM Identity Center guide](./aws-iam-identity-center.mdx). For the
|
||||
purposes of this guide, it's enough to understand that Teleport manages the creation
|
||||
and deletion of AWS Account Assignments based on a users's Account Assignment grants,
|
||||
and deletion of AWS Account Assignments based on a user's Account Assignment grants,
|
||||
either from their standing Teleport Roles, Access List membership or approved
|
||||
Access Requests.
|
||||
|
||||
@@ -214,9 +214,9 @@ $ aws sts get-caller-identity --profile admin-on-staging
|
||||
}
|
||||
```
|
||||
|
||||
Once you have validated that the profile is configured correctly, you can use
|
||||
the `--profile` argument in any `aws` subcommand to select it and use the
|
||||
corresponding Identity Center Account assignment in that operation.
|
||||
Once you have validated that the profile is configured correctly, you can use the
|
||||
`--profile` argument in any `aws` subcommand select it and use the corresponding
|
||||
Identity Center Account assignment in that operation.
|
||||
|
||||
<Admonition type="info">
|
||||
You can also use this profile with other tools that support the standard AWS client
|
||||
|
||||
@@ -55,7 +55,7 @@ Teleport Auth Service is running. The setup typically involves configuring a man
|
||||
for Teleport Auth Service and assigning that managed identity with the Microsoft Graph API
|
||||
permissions required by the Teleport Entra ID integration.
|
||||
|
||||
This method is best suited for an air-gapped Teleport clusters where the Teleport Proxy Service
|
||||
This method is best suited for an air-gapped Teleport cluster where the Teleport Proxy Service
|
||||
is not publicly accessible.
|
||||
|
||||
### Choosing guided or manual Entra ID configuration method
|
||||
|
||||
@@ -36,14 +36,14 @@ Enter a name for your application and create the application.
|
||||
Open the newly created enterprise application.
|
||||
|
||||
Under “Manage” menu select “Single sign-on”. In this configuration UI, you will need to set up Teleport
|
||||
as an SAML servicer provider.
|
||||
as an SAML service provider.
|
||||
|
||||
Click edit button to configure “Basic SAML Configuration”.
|
||||
Enter the SAML assertion endpoint as Entity ID and ACS URL value.
|
||||
- **Entity ID and ACS URL:** SAML ACS endpoint of your Teleport cluster.
|
||||
E.g. `https://example.teleport.sh/v1/webapi/saml/acs/entra-id`
|
||||
|
||||
For “Attributes & Claims”, attributes with user will already be available for you but you will need to
|
||||
For “Attributes & Claims”, attributes for the user will already be available for you but you will need to
|
||||
add a `groups` claim.
|
||||
|
||||

|
||||
|
||||
@@ -56,7 +56,7 @@ $ az login --allow-no-subscriptions
|
||||
|
||||
## Step 2/3. Configure and apply
|
||||
|
||||
The example Terraform module provides Entra ID configuration options are based on the
|
||||
The example Terraform module provides Entra ID configuration options that are based on the
|
||||
Microsoft Graph API authentication method you wish to configure for the Teleport Entra ID integration.
|
||||
|
||||
Teleport supports two types of Microsoft Graph API authentication methods:
|
||||
@@ -179,7 +179,7 @@ $ terraform apply
|
||||
</Tabs>
|
||||
|
||||
Once the changes are applied, the Terraform module will produce an application client ID and
|
||||
Entra ID tenant ID values as an output. You will need these values in the next step.
|
||||
the Entra ID tenant ID values as an output. You will need these values in the next step.
|
||||
|
||||
Entra ID is now configured with the required attributes needed for the Teleport Entra ID integration.
|
||||
|
||||
@@ -219,7 +219,7 @@ $ tctl plugins install entraid \
|
||||
in Teleport based on the groups imported from the Entra ID.
|
||||
- `--no-access-graph` flag specifies Identity Security integration is to be skipped.
|
||||
- `--use-system-credentials` flag specifies to use system credential configured using Managed Identity. Use this flag only
|
||||
if you with to set up system credential based authentication.
|
||||
if you wish to set up system credential based authentication.
|
||||
- `--manual-setup` flag specifies a manual Entra ID configuration is selected by the user.
|
||||
|
||||
`tctl` will then prompt for an Entra ID tenant ID and an application client ID of the enterprise
|
||||
|
||||
@@ -18,7 +18,7 @@ roles to go along with them.
|
||||
|
||||
With the synchronization of Okta apps and groups as Teleport Access List feature in the Okta
|
||||
integration, this work is performed for you. This guide explains how to set up
|
||||
Okta app and the sync.
|
||||
the Okta app and group sync.
|
||||
|
||||
## How it works
|
||||
|
||||
@@ -78,7 +78,7 @@ integration, ensure that:
|
||||
- (Optional) You have organized your Okta applications and groups into [Okta
|
||||
resource
|
||||
sets](https://help.okta.com/en-us/content/topics/security/custom-admin-role/create-resource-set.htm),
|
||||
which allow you to limit the scope your Okta access token.
|
||||
which allow you to limit the scope of your Okta access token.
|
||||
|
||||
## Step 1/2. Set default list owner(s)
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ enterprise: Identity Governance
|
||||
{/* lint disable page-structure remark-lint */}
|
||||
|
||||
The Teleport Okta SSO integration allows Teleport users to authenticate using
|
||||
Okta as an identity provider. Teleport. The guided enrollment flow for the Okta
|
||||
Okta as an identity provider. The guided enrollment flow for the Okta
|
||||
SSO integration is part of the [guided Okta integration](./okta.mdx). This
|
||||
guide is a companion to the guided Okta SSO integration, showing you how to
|
||||
perform required actions within Okta.
|
||||
@@ -98,7 +98,7 @@ Okta Integration Network support is still in beta. If unsure please proceed with
|
||||
|
||||
4. Give your app a name, e.g. "Teleport" and optionally upload a logo and click **Next**.
|
||||
|
||||
5. That will bring you to the "Configure SAML" step where you'll have to provide a several values:
|
||||
5. That will bring you to the "Configure SAML" step where you'll have to provide several values:
|
||||
|
||||
- Single sign on URL:
|
||||
|
||||
@@ -198,7 +198,7 @@ The preferred way to assign a Teleport role to an Okta SSO user is by adding the
|
||||
|
||||
### SAML connector attributes to roles mapping
|
||||
|
||||
The alternative is to use SAML connector attributes to roles mapping. The mapping is defined in the SAML connector resource and can be edited either the web UI or `tctl`.
|
||||
The alternative is to use SAML connector attributes to roles mapping. The mapping is defined in the SAML connector resource and can be edited either in the web UI or `tctl`.
|
||||
|
||||
In the web UI:
|
||||
|
||||
|
||||
@@ -163,7 +163,7 @@ Supported *To App* provisioning features include:
|
||||
- **Update User Attributes** - Okta updates a user's attributes in Teleport when the SAML app is assigned. Future attribute changes made to the Okta user profile will automatically overwrite the corresponding attribute value in Teleport.
|
||||
- **Deactivate Users** - Deletes the Teleport user when it is unassigned in Okta or their Okta account is deactivated. A session lock for the user is created for the maximum session duration. The Teleport user will be recreated if the SAML app is reassigned to a user in Okta.
|
||||
|
||||
Please note Teleport doesn't display SCIM attributes in the UI. They are stored in an internal user label which is a subject to change. The attributes are currently only used to construct compliant SCIM resource responses. All attributes sent to Teleport are stored and then replied in the subsequent SCIM resource responses. The only exception is the "password" attribute.
|
||||
Please note Teleport doesn't display SCIM attributes in the UI. They are stored in an internal user label which is subject to change. The attributes are currently only used to construct compliant SCIM resource responses. All attributes sent to Teleport are stored and then replied in the subsequent SCIM resource responses. The only exception is the "password" attribute.
|
||||
|
||||
## Retrospective user provisioning
|
||||
|
||||
|
||||
@@ -98,7 +98,7 @@ resources.
|
||||
|
||||
**Application**
|
||||
|
||||
- View application and their details
|
||||
- View an application and its details
|
||||
- Edit application's user assignments
|
||||
|
||||
1. And finally click **Save role**.
|
||||
@@ -156,7 +156,7 @@ section.
|
||||
4. Select the custom admin role and the resource set created earlier and click
|
||||
**Save changes**.
|
||||
|
||||
## Step 2/3.Configure the app to trust Teleport JWTs
|
||||
## Step 2/3. Configure the app to trust Teleport JWTs
|
||||
|
||||
To allow Teleport access to Okta, the Okta API Services app created in the
|
||||
previous step must be able to verify the JWT tokens issued by Teleport. In order
|
||||
|
||||
@@ -78,7 +78,7 @@ Without special handling, concurrent updates can leave a SCIM Group (and its
|
||||
corresponding Teleport Access List) in an indeterminate state. When the Teleport
|
||||
SCIM server detects a concurrent Group update, or an update based on a now-obsolete
|
||||
revision of the SCIM group, Teleport will block the update and return the HTTP
|
||||
stats code `412 Precondition Failed`. By default, the SailPoint SCIM provisioner
|
||||
status code `412 Precondition Failed`. By default, the SailPoint SCIM provisioner
|
||||
does not automatically re-try an update when it encounters a conflict like this,
|
||||
and considers it an error.
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ policies.
|
||||
## How it works
|
||||
|
||||
The SCIM integration uses a 1:1 mapping between SCIM group and Teleport
|
||||
Access Lists
|
||||
Access Lists:
|
||||
|
||||
- Each SCIM group `displayName` must match the `spec.title` of a Teleport
|
||||
Access List.
|
||||
@@ -86,7 +86,7 @@ resource "teleport_access_list" "acl-group-requester" {
|
||||
</Admonition>
|
||||
|
||||
|
||||
## Step 2/3. Configure SCIM Integration
|
||||
## Step 2/3: Configure SCIM Integration
|
||||
Teleport provides a guided Web UI-based configuration flow for the SCIM integration.
|
||||
|
||||
In the Teleport Web UI, go to **"Add new integration"** and select **SCIM**.
|
||||
@@ -108,7 +108,7 @@ Click **Continue** to proceed to the **SCIM Credentials** screen.
|
||||
- Copy the **Client ID**, **Client Secret**, and **Base URL** — you'll use them
|
||||
when configuring your Identity Provider in the next step.
|
||||
|
||||
## Step 3/3. Configure SCIM integration with your Identity Management SCIM provider
|
||||
## Step 3/3: Configure SCIM integration with your Identity Management SCIM provider
|
||||
|
||||
SCIM configuration may differ depending on your IdP. The integration has been officially tested with the following providers:
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ A lock can target the following objects or attributes:
|
||||
A lock is a dynamic Teleport resource stored on the Teleport Auth Service
|
||||
backend. Teleport services implement a lock watcher that subscribes to Auth
|
||||
Service events related to lock creation. When these services receive a
|
||||
notification that the a lock has been created or modified, they enact safeguards
|
||||
notification that a lock has been created or modified, they enact safeguards
|
||||
to prevent various operations, e.g., preventing access from a locked user.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
@@ -118,7 +118,7 @@ for transient and long-term storage, and AWS Glue table and database.
|
||||
|
||||
`policy.tf` includes the declaration of the AWS IAM policy that must
|
||||
be attached to the AWS identity that the Identity Security service runs as,
|
||||
enabling it to access the resources and execute queries. If using an E2 instance
|
||||
enabling it to access the resources and execute queries. If using an EC2 instance
|
||||
for Identity Security, attach the policy to the instance role. If using ECS or EKS,
|
||||
attach the policy to the task or pod role.
|
||||
|
||||
|
||||
@@ -303,7 +303,7 @@ If Identity Activity Center is enabled, the following extra configurations are r
|
||||
integration:
|
||||
|
||||
- <Var name="aws-sqs-queue"/>: The ARN of the Amazon SQS queue subscribed to the SNS topic that receives CloudTrail notifications.
|
||||
- <Var name="aws-s3-trail-bucket"/>: The arn of the Amazon S3 bucket where CloudTrail delivers its log files.
|
||||
- <Var name="aws-s3-trail-bucket"/>: The ARN of the Amazon S3 bucket where CloudTrail delivers its log files.
|
||||
- <Var name="aws-sqs-kms-queue-key"/>: The ARN of the AWS KMS key used to encrypt messages in the SQS queue.
|
||||
- <Var name="aws-s3-kms-key"/>: The ARN of the AWS KMS key used to encrypt objects in the S3 bucket that stores CloudTrail logs.
|
||||
|
||||
@@ -337,11 +337,11 @@ integration:
|
||||
"kms:Decrypt",
|
||||
"kms:DescribeKey",
|
||||
"kms:GenerateDataKey",
|
||||
"kms:GenerateDataKeyWithoutPlaintext",
|
||||
"kms:GenerateDataKeyWithoutPlaintext"
|
||||
],
|
||||
"Resources": [
|
||||
"<Var name="aws-sqs-kms-queue-key"/>",
|
||||
"<Var name="aws-s3-kms-key"/>",
|
||||
"<Var name="aws-s3-kms-key"/>"
|
||||
]
|
||||
}
|
||||
]
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Discover NetIQ Access Patterns with Teleport Identity Security
|
||||
sidebar_label: NetIQ
|
||||
description: Describes how to synchronize OpenTex NetIQ access patterns using Identity Security.
|
||||
description: Describes how to synchronize OpenText NetIQ access patterns using Identity Security.
|
||||
tags:
|
||||
- how-to
|
||||
- identity-security
|
||||
@@ -56,7 +56,7 @@ to visualize access structures effectively.
|
||||
|
||||
- A running Teleport Enterprise cluster v17.2.4 or later.
|
||||
- Identity Security enabled for your account.
|
||||
- An OpenTex NetIQ instance with a user that has read access to the organization.
|
||||
- An OpenText NetIQ instance with a user that has read access to the organization.
|
||||
- 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.27.0 or later.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
title: Discover Insecure SSH Access with Teleport Identity Security
|
||||
sidebar_label: SSH Keys
|
||||
description: Describes how to enable SSH Key Scanning using Identity Security to identity access patterns that use long-lived SSH keys.
|
||||
description: Describes how to enable SSH Key Scanning using Identity Security to identify access patterns that use long-lived SSH keys.
|
||||
tags:
|
||||
- how-to
|
||||
- identity-security
|
||||
@@ -42,7 +42,7 @@ Together with the key fingerprint, the Teleport-protected server also sends the
|
||||
By default, Teleport scans the `$HOME/.ssh/authorized_keys` and `$HOME/.ssh/authorized_keys2` files for authorized keys.
|
||||
Here, `$HOME` refers to the home directory of each user on the system, whether they are local or LDAP managed users.
|
||||
|
||||
### Importing User's SSH private keys
|
||||
### Importing SSH private keys
|
||||
|
||||
Teleport's `tsh` CLI tool can scan users' laptops for SSH private keys.
|
||||
It goes through the specified directories, defaulting to `/Users` on macOS, `/home` on Linux, and `C:\Users` on Windows,
|
||||
|
||||
@@ -312,7 +312,7 @@ Replace <Var name="bedrock-model-arn"/> with the ARN of the Amazon Bedrock
|
||||
model.
|
||||
|
||||
If you're using an inference profile, the `Resource` field must instead specify
|
||||
the inference profile ARN, as well as ARNS of *all* of the models that given
|
||||
the inference profile ARN, as well as ARNs of *all* of the models that given
|
||||
inference profile may end up calling. These can be given either as an array of
|
||||
specific elements or using wildcards. For more details, see [the Amazon Bedrock
|
||||
documentation on prerequisites for using inference
|
||||
|
||||
@@ -23,6 +23,6 @@ cloud provider and third-party solutions.
|
||||
To visit the standing privileges dashboard, navigate to **Identity Security** >
|
||||
**Dashboard**.
|
||||
|
||||
You can explore details about standing privileges can be clicking on a user or bot:
|
||||
You can explore details about standing privileges by clicking on a user or bot:
|
||||
|
||||

|
||||
|
||||
@@ -13,7 +13,7 @@ The Graph Explorer view in Teleport Access Graph reveals access patterns within
|
||||
your infrastructure. You can see which infrastructure resources different
|
||||
identities have access to, and which identities have access to a single
|
||||
resource. You can reveal identities with excessive permissions and resources
|
||||
with unexpected sources of access, helping you protecting your infrastructure
|
||||
with unexpected sources of access, helping you protect your infrastructure
|
||||
against identity-based attacks.
|
||||
|
||||
The Graph Explorer displays access controls from multiple systems in a single
|
||||
|
||||
@@ -12,7 +12,7 @@ enterprise: Identity Security
|
||||
The Investigate dashboard provides an overview of recent identity activity
|
||||
across your infrastructure, helping you investigate security risks and
|
||||
incidents. You can see Teleport audit events related to identity, such as
|
||||
certificate issuance and multi-factory authentication challenges, as well as
|
||||
certificate issuance and multi-factor authentication challenges, as well as
|
||||
events from [integrations](../integrations/integrations.mdx) such as GitHub and
|
||||
AWS. Because Identity Activity Center visualizes events from multiple
|
||||
integrations at once, you can investigate identity-related incidents that
|
||||
|
||||
@@ -9,7 +9,7 @@ $ tsh aws s3 ls
|
||||
|
||||
The `--aws-role` flag allows you to specify the AWS IAM role to assume when
|
||||
accessing the AWS API. You can either provide a role name like `--aws-role
|
||||
ExampleTeleportDynamoDBRole` or a full role ARN like
|
||||
{{ iam-role }}` or a full role ARN like
|
||||
`arn:aws:iam::123456789000:role/{{iam-role}}`.
|
||||
|
||||
Now you can use the `tsh aws` command like the native `aws` command-line tool:
|
||||
|
||||
@@ -49,7 +49,7 @@ app_service:
|
||||
enabled: true
|
||||
apps:
|
||||
- name: aws
|
||||
uri: https://console.aws.amazon.com/home/home
|
||||
uri: https://console.aws.amazon.com/console/home
|
||||
```
|
||||
|
||||
(!docs/pages/includes/aws-credentials.mdx service="the Teleport Application Service"!)
|
||||
|
||||
@@ -18,7 +18,7 @@ spec:
|
||||
# 'elasticache' - discovers Amazon ElastiCache Redis and Valkey databases.
|
||||
# 'elasticache-serverless' - Amazon ElastiCache Serverless Redis or Valkey databases.
|
||||
# 'memorydb' - discovers Amazon MemoryDB databases.
|
||||
# 'opensearch' - discovers Amazon OpenSearch Redis databases.
|
||||
# 'opensearch' - discovers Amazon OpenSearch databases.
|
||||
# 'rds' - discovers Amazon RDS and Aurora databases.
|
||||
# 'rdsproxy' - discovers Amazon RDS Proxy databases.
|
||||
# 'redshift' - discovers Amazon Redshift databases.
|
||||
|
||||
@@ -29,7 +29,7 @@ discovery_service:
|
||||
# 'elasticache' - Amazon ElastiCache Redis and Valkey databases.
|
||||
# 'elasticache-serverless' - Amazon ElastiCache Serverless Redis or Valkey databases.
|
||||
# 'memorydb' - Amazon MemoryDB databases.
|
||||
# 'opensearch' - Amazon OpenSearch Redis databases.
|
||||
# 'opensearch' - Amazon OpenSearch databases.
|
||||
# 'docdb' - Amazon DocumentDB databases.
|
||||
- types: ["ec2"]
|
||||
# AWS regions to search for resources from
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
{{ extraAppScheme="" }}
|
||||
|
||||
You can update an existing Application Service or create a new one to enable the
|
||||
the MCP server.
|
||||
MCP server.
|
||||
|
||||
<Tabs>
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ spec:
|
||||
|
||||
Create the `app` resource with:
|
||||
```code
|
||||
$ tctl create -f app-{{service}}-app.yaml
|
||||
$ tctl create -f app-{{service}}-mcp.yaml
|
||||
```
|
||||
</TabItem>
|
||||
|
||||
@@ -45,10 +45,10 @@ $ tctl create -f app-{{service}}-app.yaml
|
||||
Create a `teleport_app` resource in terraform. Replace <Var name="MCP_HOST" />
|
||||
with the host running the {{serviceName}} MCP server:
|
||||
```hcl
|
||||
resource "teleport_app" "grafana" {
|
||||
resource "teleport_app" "{{ service }}" {
|
||||
version = "v3"
|
||||
metadata = {
|
||||
name = "grafana"
|
||||
name = "{{ service }}"
|
||||
labels = {
|
||||
"teleport.dev/origin" = "dynamic"
|
||||
"env" = "dev"
|
||||
|
||||
@@ -6,5 +6,5 @@ $ tsh mcp config {{service}}-mcp --client-config claude
|
||||
```
|
||||
|
||||
After configuring your MCP client, you will find {{serviceName}}-related tools from
|
||||
`teleport-mcp-{{service}}-mcp`. You can now use these tools to interactive with
|
||||
`teleport-mcp-{{service}}-mcp`. You can now use these tools to interact with
|
||||
{{serviceName}} via Teleport in your MCP clients:
|
||||
|
||||
@@ -57,7 +57,7 @@ spec:
|
||||
# - Use '?' to match any single character.
|
||||
namespace_path: my-user
|
||||
# pipeline_source restricts joins to jobs triggered by certain criteria,
|
||||
# e.g.triggered through the web interface.
|
||||
# e.g. triggered through the web interface.
|
||||
pipeline_source: web
|
||||
# environment restricts joins to jobs that are associated with the
|
||||
# specified environment
|
||||
|
||||
@@ -27,7 +27,7 @@ spec:
|
||||
- space_id: root
|
||||
# caller_type is the type of caller_id. This must be `stack` or `module`.
|
||||
caller_type: stack
|
||||
# caller_id is the id of the caller. e.g.the name of the stack or module.
|
||||
# caller_id is the id of the caller. e.g. the name of the stack or module.
|
||||
#
|
||||
# This field supports glob-style matching when the enable_glob_matching field is true:
|
||||
# - Use '*' to match zero or more characters.
|
||||
@@ -36,4 +36,4 @@ spec:
|
||||
# scope is the scope of the token - either `read` or `write`.
|
||||
# See https://docs.spacelift.io/integrations/cloud-providers/oidc/#about-scopes
|
||||
scope: read
|
||||
```
|
||||
```
|
||||
|
||||
@@ -36,7 +36,7 @@ spec:
|
||||
allow:
|
||||
# description is a human-readable description of the rule. It has no
|
||||
# bearing on whether a TPM is allowed to join, but can be used to
|
||||
# associate a rule with a specific host (e.g.the asset tag of the server
|
||||
# associate a rule with a specific host (e.g. the asset tag of the server
|
||||
# in which the TPM resides).
|
||||
- description: "example-build-server-100"
|
||||
# ek_public_hash is the SHA256 hash of the EKPub marshaled in PKIX format
|
||||
@@ -48,4 +48,4 @@ spec:
|
||||
# with colon separated nibbles. This value will not be checked when a TPM
|
||||
# does not have an EKCert configured.
|
||||
ek_certificate_serial: "01:23:45:67:89:ex:am:pl:e0:23:45:67:89:ab:cd:ef"
|
||||
```
|
||||
```
|
||||
|
||||
@@ -197,7 +197,7 @@ spec:
|
||||
kubernetes_labels:
|
||||
# A user can only access prod environments
|
||||
'env': 'prod'
|
||||
# User can access any region in us-west, e.g.us-west-1, us-west-2
|
||||
# User can access any region in us-west, e.g. us-west-1, us-west-2
|
||||
'region': 'us-west-*'
|
||||
# Regular expressions start with ^ and end with $.
|
||||
# Teleport uses Go's regular expression syntax:
|
||||
@@ -283,7 +283,7 @@ spec:
|
||||
app_labels:
|
||||
# A user can only access prod environments
|
||||
'env': 'prod'
|
||||
# User can access any region in us-west, e.g.us-west-1, us-west-2
|
||||
# User can access any region in us-west, e.g. us-west-1, us-west-2
|
||||
'region': 'us-west-*'
|
||||
# Regular expressions start with ^ and end with $.
|
||||
# Teleport uses Go's regular expression syntax:
|
||||
|
||||
@@ -193,7 +193,7 @@ $ DEPLOY_OUTPUT=$(az deployment group create \
|
||||
--resource-group <your-resource-group> \
|
||||
--template-file teleport-create-identity.json)
|
||||
$ PRINCIPAL_ID=$(echo $DEPLOY_OUTPUT | jq -r '.properties.outputs.principalID.value')
|
||||
$ CLIENT_ID=$(echo $DEPLOY_OUTPUT | jq -r '.properties.outputs.principalID.value')
|
||||
$ CLIENT_ID=$(echo $DEPLOY_OUTPUT | jq -r '.properties.outputs.clientID.value')
|
||||
$ ROLE_NAME=$(echo $DEPLOY_OUTPUT | jq -r '.properties.outputs.roleName.value')
|
||||
```
|
||||
|
||||
|
||||
@@ -4,7 +4,7 @@ shared secret, the unique identity of the host's Trusted Platform Module (TPM)
|
||||
and public key cryptography is used to authenticate the host.
|
||||
|
||||
In environments where there is no other form of identity available to machines,
|
||||
e.g.on-prem, this is the most secure method for joining. It avoids the need to
|
||||
e.g. on-prem, this is the most secure method for joining. It avoids the need to
|
||||
distribute a shared secret as is needed for the `token` join method.
|
||||
|
||||
A Trusted Platform Module (TPM) is a secure, physical cryptoprocessor that is
|
||||
|
||||
@@ -95,7 +95,7 @@ If you aren't sure which to use, we recommend starting with the
|
||||
To configure the `application-tunnel` service, first determine where you want
|
||||
the listener to bind to. As any client that can connect to the service listener
|
||||
will be able to access the application, it is recommended to bind to the
|
||||
loopback interface (e.g.`127.0.0.1`) as this will prevent access from other
|
||||
loopback interface (e.g. `127.0.0.1`) as this will prevent access from other
|
||||
hosts.
|
||||
|
||||
Modify your `tbot` configuration to add an `application-tunnel` service:
|
||||
|
||||
@@ -385,7 +385,7 @@ Replace:
|
||||
|
||||
The `auth-k8s` action sets the `KUBECONFIG` for future steps to the credentials
|
||||
it has fetched from Teleport. This means that most existing tooling for
|
||||
Kubernetes (e.g.`kubectl` and `helm`) can use your cluster with no additional
|
||||
Kubernetes (e.g. `kubectl` and `helm`) can use your cluster with no additional
|
||||
configuration.
|
||||
|
||||
Add, commit, and push this new workflow file to the default branch of your
|
||||
|
||||
@@ -50,7 +50,7 @@ within a single rule is granted access.
|
||||
In this example, you will create a token with a rule that grants access to any
|
||||
GitLab CI job within a specific GitLab project. Determine the fully qualified
|
||||
path of your GitLab project. This will include your username (or group) and the
|
||||
name of your project, e.g.`my-user/my-project`.
|
||||
name of your project, e.g. `my-user/my-project`.
|
||||
|
||||
Create a file named `bot-token.yaml`. Ensure you substitute any values as
|
||||
suggested by the comments in this example:
|
||||
|
||||
@@ -28,7 +28,7 @@ where a supported join method exists. These are:
|
||||
- Spacelift
|
||||
- Terraform Cloud
|
||||
|
||||
On CI/CD platforms where you control the runner environment (e.g.self-hosted
|
||||
On CI/CD platforms where you control the runner environment (e.g. self-hosted
|
||||
Jenkins runner), MWI can run as a daemon on the runner and the generated
|
||||
credentials can be mounted into the environment of your individual workflow
|
||||
runs.
|
||||
|
||||
@@ -172,7 +172,7 @@ resource "aws_s3_bucket" "example" {
|
||||
|
||||
1. Browse to S3
|
||||
1. Select "Create bucket"
|
||||
1. Enter a meaningful, unique name for your bucket, e.g.`workload-id-demo`
|
||||
1. Enter a meaningful, unique name for your bucket, e.g. `workload-id-demo`
|
||||
1. Leave other settings as default
|
||||
1. Click "Create bucket".
|
||||
|
||||
@@ -445,7 +445,7 @@ Configure the following environment variables:
|
||||
- `AWS_ROLE_ARN`: The ARN of the role you created earlier, e.g.
|
||||
`arn:aws:iam::123456789012:role/workload-id-demo`
|
||||
- `AWS_WEB_IDENTITY_TOKEN_FILE`: The path to the JWT file that `tbot` is writing,
|
||||
e.g.`/opt/workload-identity/jwt_svid`
|
||||
e.g. `/opt/workload-identity/jwt_svid`
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
@@ -166,7 +166,7 @@ Click "Next" to proceed to the "Add permissions" page. Now select the
|
||||
permissions you wish to grant to your workload on AWS.
|
||||
|
||||
Click "Next" to proceed to the "Name, review, and create" page. Give your role
|
||||
a descriptive name, e.g."my-workload-roles-anywhere".
|
||||
a descriptive name, e.g. "my-workload-roles-anywhere".
|
||||
|
||||
Click "Create role".
|
||||
|
||||
@@ -177,7 +177,7 @@ Finally, you must create a Roles Anywhere profile.
|
||||
Navigate back to the "Roles Anywhere" section of the AWS IAM console and click
|
||||
"Create a profile".
|
||||
|
||||
Give your profile a descriptive name, e.g."my-workload".
|
||||
Give your profile a descriptive name, e.g. "my-workload".
|
||||
|
||||
Select the role you created in the previous step.
|
||||
|
||||
|
||||
@@ -44,7 +44,7 @@ Additionally, flags can be used to further customize the SVID:
|
||||
|
||||
| `flag` | Description |
|
||||
|--------------------|---------------------------------------------------------------------------------------------------------------------|
|
||||
| `--credential-ttl` | Sets the Time To Live for the resulting X509 SVID. Specify duration using `s`, `m` and `h`, e.g.`12h` for 12 hours. |
|
||||
| `--credential-ttl` | Sets the Time To Live for the resulting X509 SVID. Specify duration using `s`, `m` and `h`, e.g. `12h` for 12 hours. |
|
||||
|
||||
### Using headless authentication to issue a SVID on a remote host
|
||||
|
||||
|
||||
@@ -134,7 +134,7 @@ spec:
|
||||
'environment': '^test|staging$'
|
||||
|
||||
kubernetes_labels:
|
||||
# User can access any region in us-west, e.g.us-west-1, us-west-2
|
||||
# User can access any region in us-west, e.g. us-west-1, us-west-2
|
||||
'region': 'us-west-*'
|
||||
'cluster_name': '^us.*\.example\.com$'
|
||||
```
|
||||
|
||||
@@ -2404,7 +2404,7 @@ Flags:
|
||||
|
||||
|Flag|Default|Description|
|
||||
|---|---|---|
|
||||
|`--expires-at`|none|Time that the revocation should expire, usually this should match the expiry time of the credential. This should be specified using RFC3339 e.g.'2024-02-05T15:04:00Z'. If unspecified, the time 1 week from now is used.|
|
||||
|`--expires-at`|none|Time that the revocation should expire, usually this should match the expiry time of the credential. This should be specified using RFC3339 e.g. '2024-02-05T15:04:00Z'. If unspecified, the time 1 week from now is used.|
|
||||
|`--reason`|none|Reason for revocation.|
|
||||
|`--serial`|none|Serial number of the certificate to revoke.|
|
||||
|`--type`|none|Type of credential to revoke (x509)|
|
||||
|
||||
+1
-1
@@ -42,7 +42,7 @@ spec:
|
||||
# The hint field allows a string to be passed to workloads along with a
|
||||
# credential issued for this identity. This can be used to help workloads
|
||||
# differentiate between multiple identities that they may have
|
||||
# (e.g.`internal` vs `external`).
|
||||
# (e.g. `internal` vs `external`).
|
||||
#
|
||||
# Optional. Supports templating.
|
||||
hint: An example hint
|
||||
|
||||
+1
-1
@@ -103,7 +103,7 @@ spec:
|
||||
- space_id: root
|
||||
# caller_type is the type of caller_id. This must be `stack` or `module`.
|
||||
caller_type: stack
|
||||
# caller_id is the id of the caller. e.g.the name of the stack or module.
|
||||
# caller_id is the id of the caller. e.g. the name of the stack or module.
|
||||
caller_id: my-stack
|
||||
```
|
||||
|
||||
|
||||
@@ -30,7 +30,7 @@ To prevent changes to labels from granting elevated privileges, you should:
|
||||
- Review sources used to generate dynamic labels and restrict modifications to the command
|
||||
or the data sources used.
|
||||
- Follow the **principle of least privilege** in creating and assigning roles.
|
||||
Don't give users permissive roles when more a restrictive role will do. For example, don't
|
||||
Don't give users permissive roles when a more restrictive role will do. For example, don't
|
||||
assign users the preset `access` or `editor` role, which give them permission to access and edit
|
||||
all cluster resources. Instead, define roles with the minimum required permissions for each
|
||||
user and configure **Access Requests** or **Access Lists** to provide temporary elevated permissions.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# Default values for slack.
|
||||
# Default values for msteams.
|
||||
# This is a YAML-formatted file.
|
||||
# Declare variables to be passed into your templates.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user