mirror of
https://github.com/gravitational/teleport.git
synced 2026-10-12 02:15:01 +00:00
[v18] docs: fixes for grammar and references (#64932)
* docs: fixes for grammar and references * docs: fix link to auto provisioning
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.
|
||||
|
||||
@@ -57,7 +57,7 @@ role:
|
||||
|
||||
### 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.
|
||||
You can leave the `discovery_group` <Var name="aws-example"/> value as-is or
|
||||
change it to something you find more descriptive.
|
||||
|
||||
@@ -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 system 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 the [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
|
||||
|
||||
@@ -49,7 +49,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
|
||||
@@ -392,7 +392,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
|
||||
|
||||
|
||||
+1
-1
@@ -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.
|
||||
|
||||
|
||||
@@ -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.
|
||||
@@ -69,7 +69,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:
|
||||
|
||||
@@ -152,7 +152,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:
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
@@ -779,4 +779,4 @@ name="bedrock-inference-profile-arn"/> with the inference profile ARN:
|
||||
|
||||
```sh
|
||||
aws bedrock get-inference-profile --inference-profile-identifier="<Var name="bedrock-inference-profile-arn"/>"
|
||||
```
|
||||
```
|
||||
|
||||
@@ -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 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"!)
|
||||
|
||||
@@ -19,7 +19,7 @@ the database, follow these instructions on your workstation:
|
||||
|
||||
1. To use `tctl` from your workstation, your Teleport user must be allowed to
|
||||
impersonate the system role `Db` in order to be able to generate the database
|
||||
certificate. Include the following `allow` rule in in your Teleport user's
|
||||
certificate. Include the following `allow` rule in your Teleport user's
|
||||
role:
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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".
|
||||
|
||||
@@ -442,10 +442,10 @@ web_identity_token_file=/opt/workload-identity/jwt_svid
|
||||
|
||||
Configure the following environment variables:
|
||||
|
||||
- `AWS_ROLE_ARN`: The ARN of the role you created earlier, e.g
|
||||
- `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$'
|
||||
```
|
||||
|
||||
@@ -1687,7 +1687,7 @@ Flags:
|
||||
|Flag|Default|Description|
|
||||
|---|---|---|
|
||||
|`--annotations`|none|Resolution attributes \<key\>=\<val\>\[,...\]|
|
||||
|`--assume-start-time`|none|Sets time roles can be assumed by requestor (RFC3339 e.g 2023-12-12T23:20:50.52Z)|
|
||||
|`--assume-start-time`|none|Sets time roles can be assumed by requestor (RFC3339 e.g. 2023-12-12T23:20:50.52Z)|
|
||||
|`--delegator`|none|Optional delegating identity|
|
||||
|`--reason`|none|Optional reason message|
|
||||
|`--roles`|none|Override requested roles \<role\>\[,...\]|
|
||||
@@ -2376,7 +2376,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