# 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`](https://goteleport.com/docs/enroll-resources/database-access/reference/cli.md) 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

Assign aws-account-id to your AWS account ID:

```
{
    "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](https://docs.aws.amazon.com/documentdb/latest/developerguide/iam-identity-auth.html) 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**

Assign aws-account-id to your AWS account ID:

```
{
  "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**

Assign aws-account-id to your AWS account ID:

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

```

**Cross-account with external-id**

Assign external-aws-account-id to an external AWS account 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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

Assign aws-account-id to your AWS account ID:

```
{
    "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](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazondynamodb.html) 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**

Assign aws-account-id to your AWS account ID:

```
{
  "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**

Assign aws-account-id to your AWS account ID:

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

```

**Cross-account with external-id**

Assign external-aws-account-id to an external AWS account 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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 and Valkey

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

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElastiCacheFetchMetadata",
            "Effect": "Allow",
            "Action": "elasticache:DescribeReplicationGroups",
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheDescribeUsers",
            "Effect": "Allow",
            "Action": "elasticache:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheConnect",
            "Effect": "Allow",
            "Action": "elasticache:Connect",
            "Resource": "*"
        }
    ]
}

```

| Statement                  | Purpose                                                                                                         |
| -------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `ElastiCacheFetchMetadata` | Automatically import AWS tags as database labels or find missing information such as the database's AWS region. |
| `ElastiCacheDescribeUsers` | Determine whether a user is compatible with IAM authentication.                                                 |
| `ElastiCacheConnect`       | Connect using IAM authentication.                                                                               |

You can reduce the scope of the `ElastiCacheConnect` statement by updating it to only allow specific ElastiCache clusters and IAM users. The resource ARN you can specify has the following formats:

```
arn:aws:elasticache:{Region}:{AccountID}:replicationgroup:{ReplicationGroup}
arn:aws:elasticache:{Region}:{AccountID}:user:{UserName}
```

See [Authenticating with IAM for ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth-iam.html) 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, assigning your-kms-id to your KMS ID:

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

```

## ElastiCache Serverless for Redis and Valkey

```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElastiCacheServerlessFetchMetadata",
            "Effect": "Allow",
            "Action": "elasticache:DescribeServerlessCaches",
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheServerlessDescribeUsers",
            "Effect": "Allow",
            "Action": "elasticache:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheServerlessConnect",
            "Effect": "Allow",
            "Action": "elasticache:Connect",
            "Resource": "*"
        }
    ]
}

```

| Statement                            | Purpose                                                         |
| ------------------------------------ | --------------------------------------------------------------- |
| `ElastiCacheServerlessFetchMetadata` | Automatically import AWS metadata about the database.           |
| `ElastiCacheServerlessDescribeUsers` | Determine whether a user is compatible with IAM authentication. |
| `ElastiCacheServerlessConnect`       | Connect using IAM authentication.                               |

Details

You can reduce the scope of the `ElastiCacheServerlessConnect` statement by updating it to only allow specific ElastiCache Serverless caches and IAM users. The resource ARN you can specify has the following formats:

```
arn:aws:elasticache:{Region}:{AccountID}:serverlesscache:{CacheName}
arn:aws:elasticache:{Region}:{AccountID}:user:{UserName}
```

See [Authenticating with IAM for ElastiCache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/auth-iam.html) for more information.

## Keyspaces

Assign aws-account-id to your AWS account ID:

```
{
    "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](https://docs.aws.amazon.com/keyspaces/latest/devguide/security_iam_id-based-policy-examples.html) 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**

Assign aws-account-id to your AWS account ID:

```
{
  "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**

Assign aws-account-id to your AWS account ID:

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

```

**Cross-account with external-id**

Assign external-aws-account-id to an external AWS account 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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": "MemoryDBFetchMetadata",
            "Effect": "Allow",
            "Action": "memorydb:DescribeClusters",
            "Resource": "*"
        },
        {
            "Sid": "MemoryDBDescribeUsers",
            "Effect": "Allow",
            "Action": "memorydb:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "MemoryDBConnect",
            "Effect": "Allow",
            "Action": "memorydb:Connect",
            "Resource": "*"
        }
    ]
}

```

| Statement               | Purpose                                                                                                         |
| ----------------------- | --------------------------------------------------------------------------------------------------------------- |
| `MemoryDBFetchMetadata` | Automatically import AWS tags as database labels or find missing information such as the database's AWS region. |
| `MemoryDBDescribeUsers` | Determine whether a user is compatible with IAM authentication.                                                 |
| `MemoryDBConnect`       | Connect using IAM authentication.                                                                               |

You can reduce the scope of the `MemoryDBConnect` statement by updating it to only allow specific MemoryDB clusters and IAM users. The resource ARN you can specify has the following formats:

```
arn:aws:memorydb:{Region}:{AccountID}:cluster:{ClusterName}
arn:aws:memorydb:{Region}:{AccountID}:user:{UserName}
```

See [Authenticating with IAM for MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/auth-iam.html) 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, assigning your-kms-id to your KMS ID:

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

```

## OpenSearch

Assign aws-account-id to your AWS account ID:

```
{
    "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](https://docs.aws.amazon.com/opensearch-service/latest/developerguide/fgac.html) 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**

Assign aws-account-id to your AWS account ID:

```
{
  "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**

Assign aws-account-id to your AWS account ID:

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

```

**Cross-account with external-id**

Assign external-aws-account-id to an external AWS account 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) 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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.IAMPolicy.html) 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

Assign aws-account-id to your AWS account ID:

```
{
    "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](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-iam-credentials-role-permissions.html) 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 my-redshift --db-user=role/redshift-user-role
```

See [Using identity-based policies for Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/redshift-iam-access-control-identity-based.html) 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**

Assign aws-account-id to your AWS account ID:

```
{
  "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**

Assign aws-account-id to your AWS account ID:

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

```

**Cross-account with external-id**

Assign external-aws-account-id to an external AWS account 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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

Assign aws-account-id to your AWS account ID:

```
{
    "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. Assign us-east-2 to an AWS region, aws-account-id to your AWS account ID, and workgroup-id to a workgroup ID:

```
{
    "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](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-iam.html) 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**

Assign aws-account-id to your AWS account ID:

```
{
  "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**

Assign aws-account-id to your AWS account ID:

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

```

**Cross-account with external-id**

Assign external-aws-account-id to an external AWS account 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](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) 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": "*"
        }
    ]
}

```