Closed smallinsky closed 10 months ago
I have been giving a thought to this we might want to use the following versus options.aws.session_tags, so when creating a given DB object we are providing the name, region, account, and any sessionTags needed right?
{
"kind": "db",
"version": "v4",
"metadata": {
"name": dynamo_table_name.replace('_', '-'),
"labels": table_info['tags']
},
"spec": {
"protocol": "dynamodb",
"aws": {
"region": table_info['region'],
"account_id": table_info['account_id'],
"session_tags": [
{ "Name": "ddb_table_name" , "Value": dynamo_table_name.replace('_', '-') }
]
},
}
}
Either way works but I was not sure if it makes more sense to define the tag using internal.db_name at the Role resource level, or if we would want to define tags at the DB resource level.
What
In case of handing many AWS DB Resource (like DynamoDB table) a separate IAM role needs to be created with proper hardcoded IAM permission. That lead to following problems:
IAM Role Management: Separate IAM roles need to be created and managed for different AWS database resources (like various DynamoDB tables). Each role should ideally follow the principle of least privilege (POLP). Scalability Concern: The creation and management of multiple IAM roles can lead to configuration overhead and might be perceived as not very scalable, especially in environments with numerous AWS resources.
Proposed Solution:
Using Session Tags in STS Assume Role API: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html
The above policy allows the entity assuming the role to access the DynamoDB table specified by the TableID session tag dynamically, thus potentially reducing the number of IAM roles required.
Where AWS session Tags can be managed and defined in Teleport Role definition:
Example Code Snippet (in Go, using the AWS SDK):