To be able to attach different policies to multiple users with for_each
Actual Behavior
Not possible as policy_arn accept only string not list
Steps to Reproduce
N/A
Additional Context
I need to automate creation of users using terraform, mainly i have map “svcMap” like that {user1=[policy_arn1, policy_arn2] user2=[policy_arn3, policy_arn4]}, it’s easy to create users but not easy to attach policies:
for_each requires a map where the keys each uniquely identify one instance of the resource, so we’ll need to do one further transformation in the for_each expression to generate these unique keys:
resource "aws_iam_user_policy_attachment" "test-attach" {
for_each = {
for up in var.policy_attachments :
"${up.username} ${up.policy_arn}" => up
}
user = each.value.username
policy_arn = each.value.policy_arn
}
This will produce instances with addresses like aws_iam_user_policy_attachment.test-attach["user1 policy_arn1"], which ensures that as you make changes to var.service_map in future Terraform will be able to correlate the existing instances with the elements in your map and decide which instances to create or destroy.
Would it be possible some day to support list of policies attachement per user so mainly policy_arn accepts list instead of string ? that would make it really easy and less confusing.
I have case that we need for each user to attach up to 10 policies which will lead to 10 terraform resources of type aws_iam_user_policy_attachment which will make terraform output hard to read.
Cloudformation supports list of policies attachement per IAM:USER, Does it make sense for you ?
The Terraform provider structure is reflecting the structure of the underlying AWS API. The provider development teams usually follow the API structures closely because previous experience has shown that when they try to add additional abstractions they tend to be broken later by the evolution of the underlying APIs.
In this particular case, aws_iam_user_policy_attachment is a Terraform interface to iam:AttachUserPolicy. You’ll see there that its signature matches the resource type signature exactly, aside from following Terraform’s naming conventions.
I don’t work on the AWS provider so I can’t speak to the specific design tradeoffs in this case. If you’d like to discuss further the specific design tradeoffs for this specific case, you could open a feature request in the AWS provider repository and see what the AWS provider team thinks.