aws_db_instance
Going through upgrading the AWS provider in a module that provisions an RDS instance from 4.65 to 5.36 and were presented with the error:
Error: reading RDS DB Instance (xxx-rt-xxx): AccessDenied: User: arn:aws:sts::111111111111:assumed-role/TerraformDB/terraform-db is not authorized to perform: rds:DescribeDBInstances on resource: arn:aws:rds:us-east-1:111111111111:db:db-<randomID> because no identity-based policy allows the rds:DescribeDBInstances action
We use dedicated IAM roles to provision resources within a given module, which has not changed during the upgrade of provider. The policy does have the rds:DescribeDBInstances permission, which is restricting access to DBs that this module creates:
This appears to be related to the changes brought in as part of the 5.0.0 release (#31232). The only way to mitigate this is to wildcard the resource in the policy, which somewhat seems to defeat the purpose of being able to limit access to given resources. This may be related to the issue described in #32732 (although they talk of it being down to the IAM sniffing adding in a later version).
I've verified that it's the 5.0.0 release by testing 4.67.0 (no problem) and then going up to 5.0.0 (problem occurs). The confusing bit for me is that the instance ARN still shows the instance name not the random ID, i.e. ARN = arn:aws:rds:us-east-1:111111111111:db:foo-rt-bar, which would match the resource definition in the IAM policy.
Expected Behavior
We should be able to restrict access to certain DB instances using IAM policies
Actual Behavior
We've had to wildcard the IAM policy to allow access to effectively any DB instance in the same account/region
Relevant Error/Panic Output Snippet
No response
Terraform Configuration Files
IAM role:
data "aws_iam_policy_document" "assume_role_policy" {
statement {
effect = "Allow"
actions = ["sts:AssumeRole"]
principals {
identifiers = ["arn:aws:iam::111111111111:root"]
type = "AWS"
}
}
}
locals {
rds_actions = [
"rds:AddTagsToResource",
"rds:CreateDBInstance",
"rds:CreateDBParameterGroup",
"rds:CreateDBSubnetGroup",
"rds:DeleteDBInstance",
"rds:DeleteDBParameterGroup",
"rds:DeleteDBSubnetGroup",
"rds:DescribeDBInstances",
"rds:DescribeDBParameterGroups",
"rds:DescribeDBParameters",
"rds:DescribeDBSubnetGroups",
"rds:ListTagsForResource",
"rds:ModifyDBInstance",
"rds:ModifyDBParameterGroup",
"rds:ModifyDBSubnetGroup",
"rds:RemoveTagsFromResource",
]
rds_resources = [
"arn:aws:rds:*:111111111111:db:*",
"arn:aws:rds:*:111111111111:pg:*-rt-*",
"arn:aws:rds:*:111111111111:subgrp:*-rt-*",
]
}
data "aws_iam_policy_document" "policy" {
statement {
actions = local.rds_actions
resources = local.rds_resources
}
}
resource "aws_iam_role" "role" {
name = TerraformDB
description = "Role to be assumed by Terraform when deploying the module"
assume_role_policy = data.aws_iam_policy_document.assume_role_policy.json
}
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
Volunteering to Work on This Issue
If you are interested in working on this issue, please leave a comment.
If this would be your first contribution, please review the contribution guide.
Terraform Core Version
1.5
AWS Provider Version
5.36
Affected Resource(s)
We use dedicated IAM roles to provision resources within a given module, which has not changed during the upgrade of provider. The policy does have the
rds:DescribeDBInstances
permission, which is restricting access to DBs that this module creates:This appears to be related to the changes brought in as part of the 5.0.0 release (#31232). The only way to mitigate this is to wildcard the resource in the policy, which somewhat seems to defeat the purpose of being able to limit access to given resources. This may be related to the issue described in #32732 (although they talk of it being down to the IAM sniffing adding in a later version).
I've verified that it's the 5.0.0 release by testing 4.67.0 (no problem) and then going up to 5.0.0 (problem occurs). The confusing bit for me is that the instance ARN still shows the instance name not the random ID, i.e. ARN =
arn:aws:rds:us-east-1:111111111111:db:foo-rt-bar
, which would match the resource definition in the IAM policy.Expected Behavior
We should be able to restrict access to certain DB instances using IAM policies
Actual Behavior
We've had to wildcard the IAM policy to allow access to effectively any DB instance in the same account/region
Relevant Error/Panic Output Snippet
No response
Terraform Configuration Files
IAM role:
main:
Steps to Reproduce
Debug Output
In case it's useful, the sate on 4.67.0 contains:
After the upgrade to 5.0.0, it shows:
Panic Output
No response
Important Factoids
No response
References
No response
Would you like to implement a fix?
None