Database Access AWS IAM Reference

The Teleport Database Service requires IAM permissions for various tasks depending on the database type and setup, such as discovering endpoints and metadata of the database servers, generating IAM authentication tokens, and assuming IAM roles.

You can generate IAM permissions with the teleport db configure aws print-iam command. For example, the following command would generate and print the IAM policies:

$ teleport db configure aws print-iam --types rds,redshift --role teleport-db-service-role

To learn more about IAM permissions for a specific type of database, refer to the related section below.

DocumentDB

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DocumentDBConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/documentdb-user-role"
            ]
        },
        {
            "Sid": "DocumentDBCheckDomainURL",
            "Effect": "Allow",
            "Action": "rds:DescribeDBClusters",
            "Resource": "*"
        }
    ]
}

Statement	Purpose
DocumentDBConnectAsIAMRole	Assume an IAM role to connect to a DocumentDB cluster with IAM authentication.
DocumentDBCheckDomainURL	Validate a domain's URL if it was auto-discovered by the Discovery Service.

IAM role as a DocumentDB database user

The Teleport Database Service assumes a IAM role when connecting to a DocumentDB cluster with IAM authentication.

Refer to Authentication using IAM Identity for more information about DocumentDB IAM authentication.

To allow IAM Role teleport-db-service-role to assume IAM Role documentdb-user-role, the following is generally required:

1. Configure Trust Relationships on documentdb-user-role

teleport-db-service-role or its AWS account should be set as Principal in documentdb-user-role's trust policy.

Role as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Account as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross-account with external-id

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/documentdb-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and documentdb-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in documentdb-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

DynamoDB

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DynamoDBConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/dynamodb-user-role"
            ]
        },
        {
            "Sid": "DynamoDBSessionTagging",
            "Effect": "Allow",
            "Action": "sts:TagSession",
            "Resource": [
                "*"
            ]
        }
    ]
}

Statement	Purpose
DynamoDBConnectAsIAMRole	Assume an IAM role to forward requests to DynamoDB.
DynamoDBSessionTagging	Tag assumed role sessions if tags are specified in the Teleport database configuration under aws.session_tags.

The session tagging permissions are only required if you have configured tags under the aws.session_tags section of your Teleport database configuration.

IAM role as a DynamoDB database user

The Teleport Database Service assumes a user-specified IAM role when forwarding requests to DynamoDB on their behalf. DynamoDB-related IAM permissions must be attached to that IAM role.

Refer to Actions, resources, and condition keys for Amazon DynamoDB for more information about DynamoDB permissions.

To allow IAM Role teleport-db-service-role to assume IAM Role dynamodb-user-role, the following is generally required:

1. Configure Trust Relationships on dynamodb-user-role

teleport-db-service-role or its AWS account should be set as Principal in dynamodb-user-role's trust policy.

Role as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Account as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross-account with external-id

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/dynamodb-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and dynamodb-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in dynamodb-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

ElastiCache for Redis

ElastiCache supports IAM authentication for Redis engine version 7.0 or above. This is the recommended way to configure Teleport access to ElastiCache.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElastiCacheDescribeUsers",
            "Effect": "Allow",
            "Action": "elasticache:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheConnect",
            "Effect": "Allow",
            "Action": "elasticache:Connect",
            "Resource": [
                "arn:aws:elasticache:us-east-2:aws-account-id:replicationgroup:replication-group",
                "arn:aws:elasticache:us-east-2:aws-account-id:user:*"
            ]
        }
    ]
}

Statement	Purpose
ElastiCacheDescribeUsers	Determine whether a user is compatible with IAM authentication.
ElastiCacheConnect	Connect using IAM authentication.

See Authenticating with IAM for ElastiCache for more information.

ElastiCache managed users

note

The recommended way to configure Teleport access to ElastiCache is to use IAM auth, which is supported for Redis engine version 7.0 and up. Using managed users with passwords stored in AWS Secrets Manager is a legacy method for configuring Teleport access to ElastiCache.

If any ElastiCache users are tagged to be managed by Teleport, below are the IAM permissions required for managing the ElastiCache users:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElastiCacheManageUsers",
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeUsers",
                "elasticache:ModifyUser",
                "elasticache:ListTagsForResource"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheManagePasswords",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:CreateSecret",
                "secretsmanager:DeleteSecret",
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:TagResource",
                "secretsmanager:UpdateSecret"
            ],
            "Resource": [
                "arn:aws:secretsmanager:*:aws-account-id:secret:teleport/*"
            ]
        }
    ]
}

The default Secrets Manager key prefix that Teleport will use is "teleport/". If you have configured a custom key prefix in your Teleport database config, then you must update the IAM policy resource name teleport to match that custom prefix.

If you have configured a custom KMS key ID in your Teleport database config, then add the following to the IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": [
                "arn:aws:kms:*:aws-account-id:key/your-kms-id"
            ]
        }
    ]
}

Keyspaces

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "KeyspacesConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/keyspaces-user-role"
            ]
        }
    ]
}

Statement	Purpose
KeyspacesConnectAsIAMRole	Assume an IAM role to forward requests to Keyspaces.

IAM role as a Keyspaces database user

The Teleport Database Service assumes a user-specified IAM role when forwarding requests to Keyspaces on their behalf. Keyspaces-related IAM permissions must be attached to that IAM role.

Refer to the Amazon Keyspaces identity-based policy examples for more information about the Keyspaces permissions that you can grant to an IAM role.

To allow IAM Role teleport-db-service-role to assume IAM Role keyspaces-user-role, the following is generally required:

1. Configure Trust Relationships on keyspaces-user-role

teleport-db-service-role or its AWS account should be set as Principal in keyspaces-user-role's trust policy.

Role as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Account as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross-account with external-id

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/keyspaces-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and keyspaces-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in keyspaces-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

MemoryDB

MemoryDB supports IAM authentication for Redis engine version 7.0 or above. This is the recommended way to configure Teleport access to MemoryDB.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "MemoryDBDescribeUsers",
            "Effect": "Allow",
            "Action": "memorydb:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "MemoryDBConnect",
            "Effect": "Allow",
            "Action": "memorydb:Connect",
            "Resource": [
                "arn:aws:memorydb:us-east-2:aws-account-id:replicationgroup:replication-group",
                "arn:aws:memorydb:us-east-2:aws-account-id:user:*"
            ]
        }
    ]
}

Statement	Purpose
MemoryDBDescribeUsers	Determine whether a user is compatible with IAM authentication.
MemoryDBConnect	Connect using IAM authentication.

See Authenticating with IAM for MemoryDB for more information.

MemoryDB managed users

note

The recommended way to configure Teleport access to MemoryDB is to use IAM auth, which is supported for Redis engine version 7.0 and up. Using managed users with passwords stored in AWS Secrets Manager is a legacy method for configuring Teleport access to MemoryDB.

If any MemoryDB users are tagged to be managed by Teleport, below are the IAM permissions required for managing the MemoryDB users:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "MemoryDBManageUsers",
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeUsers",
                "memorydb:UpdateUser",
                "memorydb:ListTags"
            ],
            "Resource": "*"
        },
        {
            "Sid": "MemoryDBManagePasswords",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:CreateSecret",
                "secretsmanager:DeleteSecret",
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:TagResource",
                "secretsmanager:UpdateSecret"
            ],
            "Resource": [
                "arn:aws:secretsmanager:*:aws-account-id:secret:teleport/*"
            ]
        }
    ]
}

The default Secrets Manager key prefix that Teleport will use is "teleport/". If you have configured a custom key prefix in your Teleport database config, then you must update the IAM policy resource name teleport to match that custom prefix.

If you have configured a custom KMS key ID in your Teleport database config, then add the following to the IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": [
                "arn:aws:kms:*:aws-account-id:key/your-kms-id"
            ]
        }
    ]
}

OpenSearch

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "OpenSearchCheckDomainURL",
            "Effect": "Allow",
            "Action": "es:DescribeDomains",
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "OpenSearchConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/opensearch-user-role"
            ]
        }
    ]
}

Statement	Purpose
OpenSearchCheckDomainURL	Validate a domain's URL if it was auto-discovered by the Discovery Service.
OpenSearchConnectAsIAMRole	Assume an IAM role to forward requests to OpenSearch.

IAM role as an OpenSearch database user

OpenSearch maps IAM roles to OpenSearch backend roles. The Teleport Database Service must be able to assume these "access" IAM roles to sign the OpenSearch API requests.

Refer to Fine-grained access control in Amazon OpenSearch Service for more information about the permissions you can configure for these roles.

To allow IAM Role teleport-db-service-role to assume IAM Role opensearch-user-role, the following is generally required:

1. Configure Trust Relationships on opensearch-user-role

teleport-db-service-role or its AWS account should be set as Principal in opensearch-user-role's trust policy.

Role as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Account as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross-account with external-id

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/opensearch-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and opensearch-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in opensearch-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

RDS

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RDSAutoEnableIAMAuth",
            "Effect": "Allow",
            "Action": [
                "rds:ModifyDBCluster",
                "rds:ModifyDBInstance"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RDSConnect",
            "Effect": "Allow",
            "Action": "rds-db:connect",
            "Resource": "*"
        },
        {
            "Sid": "RDSFetchMetadata",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBClusters",
                "rds:DescribeDBInstances"
            ],
            "Resource": "*"
        }
    ]
}

Statement	Purpose
RDSAutoEnableIAMAuth	Automatically enable IAM auth on RDS instances and Aurora clusters.
RDSConnect	Generate an IAM authentication token to connect to a database.
RDSFetchMetadata	Automatically import AWS tags as database labels or find missing information such as the database's AWS region.

The Teleport Database Service uses rds:ModifyDBInstance and rds:ModifyDBCluster to automatically enable IAM authentication on RDS instances and Aurora clusters, respectively. You can omit the RDSAutoEnableIAMAuth permissions if IAM authentication is already enabled on your databases.

The rds-db:connect permission is required to connect to databases. You can reduce the scope of the permission to only allow specific databases, regions, or users. The resource ARN has the following format:

arn:aws:rds-db:{Region}:{AccountID}:dbuser:{ResourceID}/{UserName}

Refer to Creating and using an IAM policy for IAM database access for more information about the rds-db:connect permission grant syntax.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RDSFetchMetadata permissions if all of your AWS databases are being auto-discovered.

RDS Proxy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RDSProxyConnect",
            "Effect": "Allow",
            "Action": "rds-db:connect",
            "Resource": "*"
        },
        {
            "Sid": "RDSProxyFetchMetadata",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints"
            ],
            "Resource": "*"
        }
    ]
}

Statement	Purpose
RDSProxyConnect	Generate an IAM authentication token to connect to a database.
RDSProxyFetchMetadata	Automatically import AWS tags as database labels or find missing information such as the database's AWS region.

The rds-db:connect permission is required to connect to databases. You can reduce the scope of the permission to only allow specific databases, regions, or users. The resource ARN has the following format:

arn:aws:rds-db:{Region}:{AccountID}:dbuser:{ResourceID}/{UserName}

Refer to Creating and using an IAM policy for IAM database access for more information about the rds-db:connect permission grant syntax.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RDSProxyFetchMetadata permissions if all of your AWS databases are being auto-discovered.

Redshift

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftConnectAsDBUser",
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentials",
            "Resource": "*"
        },
        {
            "Sid": "RedshiftConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/redshift-user-role"
            ]
        },
        {
            "Sid": "RedshiftFetchMetadata",
            "Effect": "Allow",
            "Action": "redshift:DescribeClusters",
            "Resource": "*"
        }
    ]
}

Statement	Purpose
RedshiftConnectAsDBUser	Connect to a database as an existing database user.
RedshiftConnectAsIAMRole	Assume an IAM role to connect to a database with permissions mapped into the database 1:1 from the role's IAM permissions.
RedshiftFetchMetadata	Automatically import AWS tags as database labels or find missing information such as the database's AWS region.

You can reduce the scope of the RedshiftConnectAsDBUser statement by updating it to only allow specific users, databases, and database groups. The resource ARN you can specify has the following formats:

arn:aws:redshift:{Region}:{AccountID}:dbuser:{ClusterName}/{UserName}
arn:aws:redshift:{Region}:{AccountID}:dbname:{ClusterName}/{DatabaseName}
arn:aws:redshift:{Region}:{AccountID}:dbgroup:{ClusterName}/{DatabaseGroupName}

See Create an IAM role or user with permissions to call GetClusterCredentials for more information about the redshift:GetClusterCredentials permission grant syntax.

You can authenticate as an existing database user or as an IAM role that will be automatically mapped into the database. The corresponding IAM statement is only required for the method(s) you want to use. If an IAM role names the Database Service's identity as a trusted principal, and both identities are in the same AWS account, then the RedshiftConnectAsIAMRole statement can also be omitted.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RedshiftFetchMetadata permissions if all of your AWS databases are being auto-discovered.

IAM role as a Redshift database user

The following permissions policy should be attached to an IAM role that Teleport users can specify as a database user.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftConnectWithIAM",
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentialsWithIAM",
            "Resource": "*"
        }
    ]
}

Statement	Purpose
RedshiftConnectWithIAM	Connect to a Redshift database as a database user mapped 1:1 from this IAM identity.

An IAM role can connect as an automatically created database user with permissions mapped 1:1 from the identity's IAM permissions. Permissions in the database are granted with redshift-data:* statements attached to the IAM identity, for example redshift-data:GetStatementResult. Teleport users can connect as that role by specifying "role/{RoleName}" as a database user, e.g.

$ tsh db connect redshift-example-db --db-user=role/redshift-user-role

See Using identity-based policies for Amazon Redshift for more information about available Redshift IAM permissions that are mapped to the database user.

To allow IAM Role teleport-db-service-role to assume IAM Role redshift-user-role, the following is generally required:

1. Configure Trust Relationships on redshift-user-role

teleport-db-service-role or its AWS account should be set as Principal in redshift-user-role's trust policy.

Role as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Account as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross-account with external-id

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/redshift-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and redshift-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in redshift-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

Redshift Serverless

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftServerlessConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/redshift-serverless-user-role"
            ]
        },
        {
            "Sid": "RedshiftServerlessFetchMetadata",
            "Effect": "Allow",
            "Action": [
                "redshift-serverless:GetEndpointAccess",
                "redshift-serverless:GetWorkgroup"
            ],
            "Resource": "*"
        }
    ]
}

Statement	Purpose
RedshiftServerlessFetchMetadata	Automatically import AWS tags as database labels or find missing information such as the database's AWS region.
RedshiftServerlessConnectAsIAMRole	Assume an IAM role to connect as a database user.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RedshiftServerlessFetchMetadata permissions if all of your AWS databases are being auto-discovered.

Redshift Serverless maps IAM roles to database users. The Teleport Database Service must be able to assume these "access" IAM roles which are granted IAM permissions to generate IAM authentication tokens.

IAM role as a Redshift Serverless database user

The following permissions policy should be attached to an IAM role that Teleport users can specify as a database user.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftServerlessConnect",
            "Effect": "Allow",
            "Action": "redshift-serverless:GetCredentials",
            "Resource": "arn:aws:redshift-serverless:us-east-2:aws-account-id:workgroup/workgroup-id"
        }
    ]
}

Statement	Purpose
RedshiftServerlessConnect	Get credentials to connect to a database.

The resource ARN string has the following format:

arn:aws:redshift-serverless:{Region}:{AccountID}:workgroup/{WorkgroupID}

Teleport users can connect as the IAM role by specifying the role name as a database user, e.g.

$ tsh db connect redshift-serverless-example-db --db-user=redshift-serverless-user-role

See Identity and access management in Amazon Redshift Serverless for more information about configuring Redshift Serverless permissions.

To allow IAM Role teleport-db-service-role to assume IAM Role redshift-serverless-user-role, the following is generally required:

1. Configure Trust Relationships on redshift-serverless-user-role

teleport-db-service-role or its AWS account should be set as Principal in redshift-serverless-user-role's trust policy.

Role as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Account as principal

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Cross-account with external-id

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/redshift-serverless-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and redshift-serverless-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in redshift-serverless-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}