![Fork me on GitHub](/docs/_next/image/?url=%2Fdocs%2F_next%2Fstatic%2Fmedia%2Fforkme.b9234619.webp&w=256&q=75)
Teleport
Database Access AWS IAM Reference
- Version 17.x
- Version 16.x
- Version 15.x
- Version 14.x
- Older Versions
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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:root"
},
"Action": "sts:AssumeRole"
}
]
}
{
"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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:root"
},
"Action": "sts:AssumeRole"
}
]
}
{
"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
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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:root"
},
"Action": "sts:AssumeRole"
}
]
}
{
"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
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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:root"
},
"Action": "sts:AssumeRole"
}
]
}
{
"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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:root"
},
"Action": "sts:AssumeRole"
}
]
}
{
"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.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
},
"Action": "sts:AssumeRole"
}
]
}
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::aws-account-id:root"
},
"Action": "sts:AssumeRole"
}
]
}
{
"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": "*"
}
]
}