Add STS session tags support for DynamoDB access

[gabrielcorado]

Closes #33131.

This update adds support for specifying STS session tags on database configurations. The tags will be passed into the assume role call for DynamoDB database access, making them available on the IAM policies. This feature allows users to have one Teleport database configured per DynamoDB table (to have granular access) but share IAM roles used to connect.

changelog: Added support for STS session tags in the database configuration for granular DynamoDB access.

Usage example

1. Specify the tags on the database configuration.

kind: db
version: v3
metadata:
  name: dynamo-table-a
  description: "DynamoDB Table A"
spec:
  protocol: "dynamodb"
  aws:
    region: "us-east-1"
    account_id: "123456789012"
    session_tags:
      ddb_table_name: "table-a"

2. Create/Update the IAM access role to include the tag session permissions on the trust policy. For this example, we're naming this role as DynamoScanTableRole. Note: If the role used has a permission boundaries set, it will also need to get updated with the new STS permissions.

3. Update the IAM role policy to use the session tag. Here is an example of a policy that gives access to describe the table:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "dynamodb:DescribeTable"
            ],
            "Resource": "arn:aws:dynamodb:*:123456789012:table/${aws:PrincipalTag/ddb_table_name}"
        }
    ]
}

4. Include the database user on the Teleport user or role:

kind: user
metadata:
  name: alice
spec:
  roles:
  - access
  - editor
  traits:
    db_names:
    - '*'
    db_users:
    - 'DynamoScanTableRole'
version: v2

4. Run proxy tunnel (same as regular DynamoDB access): tsh proxy db --tunnel --port 8000 --db-user=DynamoScanTableRole dynamo-table-a

5. Execute the DynamoDB queries:

$ aws --endpoint-url=http://localhost:8000 dynamodb describe-table --table-name table-a

{
    "Table": {
        ...
    }
}

Trying to describe any other table should return access denied error:

$ ❯ aws --endpoint-url=http://localhost:8000 dynamodb describe-table --table-name table-b

An error occurred (AccessDeniedException) when calling the DescribeTable operation: User: arn:aws:sts::123456789012:assumed-role/DynamoScanTableRole/alice is not authorized to perform: dynamodb:DescribeTable on resource: arn:aws:dynamodb:us-east-1:123456789012:table/table-b because no identity-based policy allows the dynamodb:DescribeTable action

[greedy52]

If agent's IAM role has a boundary policy, is sts:TagSession required in the boundary?

@smallinsky what are your thoughts on this appraoch? Thanks

[smallinsky]

If agent's IAM role has a boundary policy, is sts:TagSession required in the boundary?
@smallinsky what are your thoughts on this appraoch? Thanks

I might be wrong but this should not be needed and the only proper trust relation setup is required but I it work to check and test.

One improvement is tempting:

Namely in current implementation a custom will need to create N teleport database resouce for each DynamoDB table I if session_tags can support simple expressions so customer will be able to configure database using session_tags template:

kind: db
version: v3
metadata:
  name: dynamo-database
  description: "DynamoDB Table A"
spec:
  protocol: "dynamodb"
  aws:
    region: "us-east-1"
    account_id: "123456789012"
    session_tags:
      ddb_table_name: "{{db_name}}"

By that we will support table rback for dynamoDB:

    db_names:
    - 'TableA'
    - 'TableB'

and a user will be able to dynamically connect to dynamo-database tables using tsh db proxy --db-user=DynamoScanTableRole --db-name=TableA dynamo-database

The cons is naming confusion db_name == DynamoDB table.

[greedy52]

and a user will be able to dynamically connect to dynamo-database tables using tsh db proxy --db-user=DynamoScanTableRole --db-name=TableA dynamo-database

If we were to support a "dynamo-table-as-database-name" mode, should we implement the access control properly on the Teleport side?

• User access check: if TableA not in user's roles/traits, request should be rejected
• API check: if TableB is requested in an API call but TableA is in dbroute, request should be rejected

I think this would be more aligned with how access is controlled for other databases so that we don't have to rely on AWS IAM policy for permission management.

What do you think? (if doing so, we can track it as a separate feature)

If agent's IAM role has a boundary policy, is sts:TagSession required in the boundary?

This was meant for @gabrielcorado to double check. It didn't work for me without sts:TagSession.

[smallinsky]

I think this would be more aligned with how access is controlled for other databases so that we don't have to rely on AWS IAM policy for permission management.

What do you think? (if doing so, we can track it as a separate feature)

Agree, Let's keep it out of scope and we can discuss this separately.

[gabrielcorado]

@greedy52 Yes, if the agent role has a boundary set, it needs to get updated with the sts:TagSession. (I've updated the example)

[greedy52]

@greedy52 Yes, if the agent role has a boundary set, it needs to get updated with the sts:TagSession. (I've updated the example)

Could you update the AWS configurator as well?

teleport/lib/configurators/aws/aws.go

Lines 270 to 273 in f17ace0

	// dynamodbActions contains IAM actions for static AWS DynamoDB databases.
	dynamodbActions = databaseActions{
	authBoundary: stsActions,
	}

Thanks!

[greedy52]

LGTM 👍

[greedy52]

@smallinsky PTAL. thanks!

[public-teleport-github-review-bot]

@gabrielcorado See the table below for backport results.

Branch	Result
branch/v14	Failed