Teleport

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 db-service-role

To learn more about a specific database, refer to the related section below.

RDS

In this section, you will find information about the necessary IAM permissions that are required for RDS instances, Aurora clusters, and RDS Proxies.

RDS auto-discovery

The following IAM permissions are required for the Teleport service that performs auto-discovery:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBClusters",
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints",
                "rds:ListTagsForResource",
            ],
            "Resource": "*"
        }
    ]
}

rds:*DBInstance*, rds:*DBCluster*, and rds:*DBProxy* are permissions required for RDS instances, Aurora clusters, and RDS Proxies, respectively. You can omit the other permissions if only some are used.

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

RDS access

The Teleport Database Service can automatically manage IAM policies of the attached IAM identity for RDS access. To use this feature, Teleport requires iam:PutRolePolicy or iam:PutUserPolicy permissions to grant itself necessary IAM permissions for each registered database.

If you prefer to manage IAM identities manually, refer to the manage IAM identities yourself section which outlines the required IAM permissions.

Teleport-managed IAM identities for RDS access

Teleport requires the following IAM permissions depending on the IAM identity Teleport is managing:

Use this policy if your Teleport Database Service runs as an IAM role (for example, on an EC2 instance with an attached IAM role):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBClusters",
                "rds:ModifyDBInstance",
                "rds:ModifyDBCluster",
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:role/sample-role"
        }
    ]
}

Teleport uses rds:ModifyDBInstance and rds:ModifyDBCluster to automatically enable IAM authentication on the RDS instance and the Aurora cluster, respectively. You can omit these permissions if IAM authentication is already enabled.

For best security, use the following boundary policy that limits Teleport's self-granting capability on the IAM user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBClusters",
                "rds:ModifyDBInstance",
                "rds:ModifyDBCluster",
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints",
                "rds-db:connect"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:role/sample-role"
        }
    ]
}

See permissions boundaries for IAM entities for more information.

Use this policy if you're connecting to RDS instances and Aurora clusters, and your Teleport Database Service instance runs as an IAM user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBClusters",
                "rds:ModifyDBInstance",
                "rds:ModifyDBCluster",
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:user/sample-user"
        }
    ]
}

For best security, use the following boundary policy that limits Teleport's self-granting capability on the IAM user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBInstances",
                "rds:DescribeDBClusters",
                "rds:ModifyDBInstance",
                "rds:ModifyDBCluster",
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints",
                "rds-db:connect"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:user/sample-user"
        }
    ]
}

See permissions boundaries for IAM entities for more information.

Manage IAM identities yourself for RDS access

To connect to an RDS database, the Database Service instance's IAM identity must have rds-db:connect permissions for it. Here is a sample policy:

{
   "Version": "2012-10-17",
   "Statement": [
      {
         "Effect": "Allow",
         "Action": [
             "rds-db:connect"
         ],
         "Resource": [
             "arn:aws:rds-db:us-east-2:aws-account-id:dbuser:db-ABCDEFGHIJKL01234/*",
             "arn:aws:rds-db:us-east-2:aws-account-id:dbuser:cluster-ABCDEFGHIJKL01234/*",
             "arn:aws:rds-db:us-east-2:aws-account-id:dbuser:prx-ABCDEFGHIJKL01234/*"
         ]
      }
   ]
}

The resource ARN in the policy has the following format:

arn:aws:rds-db:<region>:<account-id>:dbuser:<resource-id>/<db-user>

Parameter	Description
`region`	AWS region where the database cluster is deployed.
`account-id`	AWS account ID the database cluster is deployed under.
`resource-id`	Database AWS resource identifier: - `db-XXX` for RDS instances. - `cluster-XXX` for Aurora clusters. - `prx-XXX` for RDS Proxy. Can be found under Configuration section in the RDS control panel.
`db-user`	Database user to associate with IAM authentication. Can be a wildcard.

See Creating and using an IAM policy for IAM database access for more information.

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

Redshift

In this section, you will find information about the necessary IAM permissions that are required for Redshift clusters.

Redshift auto-discovery

The following IAM permissions are required for the Teleport service that performs auto-discovery:

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

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

Redshift access

As mentioned in the Redshift guide, Teleport supports IAM authentication as either an existing database user or an IAM role for Redshift.

When authenticating as an existing database user, the Teleport Database Service can automatically manage IAM policies of the attached IAM identity for Redshift access. To use this feature, Teleport requires iam:PutRolePolicy or iam:PutUserPolicy permissions to grant itself necessary IAM permissions for each registered database. If you prefer to manage IAM identities manually, refer to the manage IAM identities yourself section which outlines the required IAM permissions.

When authenticating as an IAM role, use the IAM permissions outlined in the IAM authentication as IAM role section.

Teleport-managed IAM identities for Redshift access

Teleport requires the following IAM permissions depending on the IAM identity Teleport is managing:

Use this policy if your Teleport Database Service instance runs as an IAM role (for example, on an EC2 instance with an attached IAM role):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "redshift:DescribeClusters",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:role/sample-role"
        }
    ]
}

For best security, use the following boundary policy that limits Teleport's self-granting capability on the IAM role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "redshift:DescribeClusters",
                "redshift:GetClusterCredentials",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:role/sample-role"
        }
    ]
}

See permissions boundaries for IAM entities for more information.

Use this policy if your Teleport Database Service runs as an IAM user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "redshift:DescribeClusters",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:user/sample-user"
        }
    ]
}

For best security, use the following boundary policy that limits Teleport's self-granting capability on the IAM user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "redshift:DescribeClusters",
                "redshift:GetClusterCredentials"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:user/sample-user"
        }
    ]
}

See permissions boundaries for IAM entities for more information.

Manage IAM identities yourself for Redshift access

In order to authorize Teleport to generate temporary IAM tokens, create an IAM role with the GetClusterCredentials permission. Here is a sample policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentials",
            "Resource": [
                "arn:aws:redshift:us-east-2:aws-account-id:dbuser:cluster_id/*",
                "arn:aws:redshift:us-east-2:aws-account-id:dbname:cluster_id/*",
                "arn:aws:redshift:us-east-2:aws-account-id:dbgroup:cluster_id/*"
            ]
        }
    ]
}

The resource ARN string has the following format:

arn:aws:redshift:<region>:<account-id>:<resource>:<cluster-id>/<name>

Parameters:

Parameter	Description
`region`	AWS region where your Redshift cluster is deployed, or a wildcard.
`account-id`	ID of the AWS account where the Redshift cluster is deployed.
`resource`	One of `dbuser`, `dbname` or `dbgroup` to restrict access to database accounts, names or groups respectively.
`cluster-id`	Redshift cluster identifier, or a wildcard.
`name`	Name of a particular database account, name or group (depending on the `resource`), or a wildcard.

See Create an IAM role or user with permissions to call GetClusterCredentials for more information.

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

IAM authentication as IAM role for Redshift access

When authenticating Redshift as an IAM role, the Teleport Database Service must be able to assume this IAM role.

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

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

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

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-access-role"
        }
    ]
}

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

db-service-role also requires sts:AssumeRole permissions in its boundary policy, for example:

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

Note that this is only required when a boundary policy is attached to db-service-role.

The Redshift "access" IAM role requires the following permissions:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentialsWithIAM",
            "Resource": "arn:aws:redshift:us-east-2:aws-account-id:dbname:cluster-id/*"
        }
    ]
}

The resource ARN string has the following format:

arn:aws:redshift:<region>:<account-id>:db-name:<cluster-id>/*

Parameters:

Parameter	Description
`region`	AWS region where your Redshift cluster is deployed, or a wildcard.
`account-id`	ID of the AWS account where the Redshift cluster is deployed.
`cluster-id`	Redshift cluster identifier, or a wildcard.

Redshift Serverless

In this section, you will find information about the necessary IAM permissions that are required for Redshift Serverless workgroups.

Redshift Serverless auto-discovery

The following IAM permissions are required for the Teleport service that performs auto-discovery:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "redshift-serverless:ListWorkgroups",
                "redshift-serverless:ListEndpointAccess",                                
                "redshift-serverless:ListTagsForResource"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

Redshift Serverless access

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.

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

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

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

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-access-role"
        }
    ]
}

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

db-service-role also requires sts:AssumeRole permissions in its boundary policy, for example:

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

Note that this is only required when a boundary policy is attached to db-service-role.

In addition to assuming IAM roles, heres is a list of IAM permissions used by Database Service to gather information about the registered Redshift Serverless workgroups and VPC endpoints:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "redshift-serverless:GetWorkgroup",
                "redshift-serverless:GetEndpointAccess"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

The Redshift Serverless "access" IAM role requires the following permissions:

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

The resource ARN string has the following format:

arn:aws:redshift-serverless:<region>:<account-id>:workgroup:<workgroup-id>/*

Parameters:

Parameter	Description
`region`	AWS region where your Redshift Serverless workgroup is deployed, or a wildcard.
`account-id`	ID of the AWS account where the Redshift Serverless workgroup is deployed.
`workgroup-id`	Redshift Serverless workgroup identifier, or a wildcard.

ElastiCache/MemoryDB

In this section, you will find information about the necessary IAM permissions that are required for ElastiCache and MemoryDB for Redis.

ElastiCache/MemoryDB auto-discovery

The following IAM permissions are required for the Teleport service that performs auto-discovery:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticache:ListTagsForResource",
                "elasticache:DescribeReplicationGroups",
                "elasticache:DescribeCacheClusters",
                "elasticache:DescribeCacheSubnetGroups",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "memorydb:ListTags",
                "memorydb:DescribeClusters",
                "memorydb:DescribeSubnetGroups",
            ],
            "Resource": "*"
        }
    ]
}

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

ElastiCache/MemoryDB access

ElastiCache and MemoryDB supports IAM authentication for Redis engine version 7.0 or above. The Teleport Database Service can automatically manage IAM policies of the attached IAM identity for ElastiCache and MemoryDB that use IAM authentication. To use this feature, Teleport requires iam:PutRolePolicy or iam:PutUserPolicy permissions to grant itself necessary IAM permissions for each registered database. If you prefer to manage IAM identities on your own, refer to the manage IAM identities yourself section which outlines the required IAM permissions.

Teleport also supports automatic password rotations for ElastiCache and MemoryDB users using secrets manager, when IAM authentication is not available. Please use the IAM permissions outlined in the auto-password rotation section.

Teleport-managed IAM identities for ElastiCache/MemoryDB access

The required IAM permissions are slightly different depending on the IAM identity Teleport is managing:

Use this policy if your Teleport Database Service instance runs as an IAM role (for example, on an EC2 instance with an attached IAM role):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeReplicationGroups",
                "elasticache:DescribeUsers"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeSubnetGroups",
                "memorydb:DescribeUsers"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:role/sample-role"
        }
    ]
}

For best security, use the following boundary policy that limits Teleport's self-granting capability on the IAM role:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeReplicationGroups",
                "elasticache:DescribeUsers",
                "elasticache:Connect",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeSubnetGroups",
                "memorydb:DescribeUsers",
                "memorydb:Connect"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRolePolicy",
                "iam:PutRolePolicy",
                "iam:DeleteRolePolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:role/sample-role"
        }
    ]
}

See permissions boundaries for IAM entities for more information.

Use this policy if your Teleport Database Service runs as an IAM user (for example, it uses an AWS credentials file):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeReplicationGroups",
                "elasticache:DescribeUsers"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeSubnetGroups",
                "memorydb:DescribeUsers"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:user/sample-user"
        }
    ]
}

For best security, use the following boundary policy that limits Teleport's self-granting capability on the IAM user:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeReplicationGroups",
                "elasticache:DescribeUsers",
                "elasticache:Connect",
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeClusters",
                "memorydb:DescribeUsers",
                "memorydb:Connect"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:PutUserPolicy",
                "iam:DeleteUserPolicy"
            ],
            "Resource": "arn:aws:iam::aws-account-id:user/sample-user"
        }
    ]
}

See permissions boundaries for IAM entities for more information.

Manage IAM identities yourself for ElastiCache/MemoryDB access

In order to authorize Teleport to generate temporary IAM tokens, create an IAM role with the Connect permission. Here is a sample policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeUsers"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeUsers"
            ],
            "Resource": "*"
        },
        {
            "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:*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": "memorydb:Connect",
            "Resource": [
                "arn:aws:memorydb:us-east-2:aws-account-id:cluster/cluster-name",
                "arn:aws:memorydb:us-east-2:aws-account-id:user/*"
            ],
        }
    ]
}

See Authenticating with IAM for ElastiCache and Authenticating with IAM for MemoryDB for more information.

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

Auto-password rotation for ElastiCache/MemoryDB

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

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

If a custom Secrets Manager key prefix or a custom KMS key ID is used in the static configuration, add the following to the IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "secretsmanager:DescribeSecret",
                "secretsmanager:CreateSecret",
                "secretsmanager:UpdateSecret",
                "secretsmanager:DeleteSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:TagResource"
            ],
            "Resource": [
                "arn:aws:secretsmanager:*:aws-account-id:secret:my-prefix/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "kms:GenerateDataKey",
                "kms:Decrypt"
            ],
            "Resource": [
                "arn:aws:kms:*:aws-account-id:key/my-kms-id",
            ]
        }
    ]
}

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

OpenSearch

In this section, you will find information about the necessary IAM permissions that are required for OpenSearch domains.

OpenSearch auto-discovery

The following IAM permissions are required for the Teleport service that performs auto-discovery:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "es:ListDomainNames",
                "es:DescribeDomains",
                "es:ListTags"
            ],
            "Resource": "*"
        }
    ]
}

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

OpenSearch access

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

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

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

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

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-access-role"
        }
    ]
}

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

db-service-role also requires sts:AssumeRole permissions in its boundary policy, for example:

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

Note that this is only required when a boundary policy is attached to db-service-role.

In addition to assuming IAM roles, heres is a list of IAM permissions used by Database Service to gather information about the registered OpenSearch domains:

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

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

DynamoDB

In this section, you will find information about the necessary IAM permissions that are required for DynamoDB.

Note that auto-discovery is not available for DynamoDB.

DynamoDB access is provided by IAM roles with corresponding DynamoDB-related IAM permissions. The Teleport Database Service must be able to assume these "access" IAM roles.

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

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

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

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-access-role"
        }
    ]
}

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

db-service-role also requires sts:AssumeRole permissions in its boundary policy, for example:

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

Note that this is only required when a boundary policy is attached to db-service-role.

If session tags are used for DynamoDB access, the following IAM permissions is also required:

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

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

Keyspaces

In this section, you will find information about the necessary IAM permissions that are required for Keyspaces (Apache Cassandra).

Note that auto-discovery is not available for Keyspaces.

Keyspaces access is provided by IAM roles with corresponding Keyspaces-related IAM permissions. The Teleport Database Service must be able to assume these "access" IAM roles.

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

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

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

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-access-role"
        }
    ]
}

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

db-service-role also requires sts:AssumeRole permissions in its boundary policy, for example:

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

Note that this is only required when a boundary policy is attached to db-service-role.

Note that if your IAM identity uses a boundary policy, the above IAM permissions must be included in the boundary policy as well.

The Teleport Access Platform

Featured Resource

Integrations

Featured Resource

Use Cases

Featured Resource

Industries

Featured Resource

Compliance

Featured Webinar

Strategic Partners

Featured AWS Webinar

Featured Blog Post

Featured Webinar

Database Access AWS IAM Reference

RDS

RDS auto-discovery

RDS access

Teleport-managed IAM identities for RDS access

Manage IAM identities yourself for RDS access

Redshift

Redshift auto-discovery

Redshift access

Teleport-managed IAM identities for Redshift access

Manage IAM identities yourself for Redshift access

IAM authentication as IAM role for Redshift access

Redshift Serverless

Redshift Serverless auto-discovery

Redshift Serverless access

ElastiCache/MemoryDB

ElastiCache/MemoryDB auto-discovery

ElastiCache/MemoryDB access

Teleport-managed IAM identities for ElastiCache/MemoryDB access

Manage IAM identities yourself for ElastiCache/MemoryDB access

Auto-password rotation for ElastiCache/MemoryDB

OpenSearch

OpenSearch auto-discovery

OpenSearch access

DynamoDB

Keyspaces