Assignment multiple users or groups via aws_ssoadmin_account_assignment

[daimon243]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• 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
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

I use aws_ssoadmin_account_assignment resource like this:

resource aws_ssoadmin_account_assignment assignment {
  for_each = toset(var.list_users)
  instance_arn = tolist(data.aws_ssoadmin_instances.sso.arns)[0]
  principal_type = "USER"
  target_id = var.target_account_id
  target_type = "AWS_ACCOUNT"
  permission_set_arn = var.permission_set_arn
  principal_id = each.value
}

When apply multiple user assignments via use "for_each" for resource "aws_ssoadmin_account_assignment", created send-receive request for every "principal_id" .

The every request contain all assignment for permission_set in target_account. In my case for 1000+ users one request have above 300Kbytes and paginator splitting one request to 20 pages. For all users traffic more then 300 Mbytes and approximately 20k pagination token for any assignments change and more than 5 hours in progress.

terraform apply failed with some error message like:

• "Rate exceeded"
• "Error: error reading SSO Account Assignment for Principal ...: ValidationException: Invalid pagination token"

After splitting all users by blocks for 100 users on some time receive error: "Error: error reading SSO Account Assignment for Principal ...: ValidationException: Invalid pagination token"

According to https://docs.aws.amazon.com/sdk-for-go/api/service/ssoadmin/#ListAccountAssignmentsInput do not have filter by "principal_id". Therefore need join multiple assignments to one aws_ssoadmin_account_assignment resource.

New or Affected Resource(s)

• aws_ssoadmin_account_assignment

Potential Terraform Configuration

# assignment users
resource aws_ssoadmin_account_assignment assignment {
  instance_arn = tolist(data.aws_ssoadmin_instances.sso.arns)[0]
  principal_type = "USER"
  target_id = var.target_account_id
  target_type = "AWS_ACCOUNT"
  permission_set_arn = var.permission_set_arn
  principal_id = [user1,user2,user3,...userN]
}

References

• #0000

[YakDriver]

@daimon243 Thank you for letting us know about this! While I cannot guarantee when we'll have a chance to work on this, at first glance, your idea of changing principal_id to a list or set, seems plausible. Another idea would be to create a new resource aws_ssoadmin_account_assignments.

[YakDriver]

Related #18812

[daimon243]

Yes i think your idea is better, because anyone using "aws_ssoadmin_account_assignment" will not need to fix previously written infrastructure code. I totally agree. Therefore Potential Terraform Configuration some change:

Potential Terraform Configuration

# new resource assignment multiple users
resource aws_ssoadmin_account_assignments assignments {
  instance_arn = tolist(data.aws_ssoadmin_instances.sso.arns)[0]
  principal_type = "USER" /*or "GROUP"*/
  target_id = var.target_account_id
  target_type = "AWS_ACCOUNT"
  permission_set_arn = var.permission_set_arn
  principal_id = [principal_id1, principal_id2, principal_id3,...principal_idN]
}

[gingersnapz]

I would really love to see an array option for target_id as well. That way when we want to provide access to the same principal across multiple accounts, we can do it in the same resource.

[emanuelflp]

As an workaround, you can create a loop using for_each or count to iterate over the list and create all mapping.

resource "aws_ssoadmin_account_assignment" "this" {
  for_each = toset(['group1','group2','group3','group4'])
  instance_arn       = tolist(data.aws_ssoadmin_instances.this.arns)[0]
  permission_set_arn = var.permission_set_arn

  principal_id   = each.value
  principal_type = "GROUP"

  target_type = "AWS_ACCOUNT"
  target_id   = var.target_account_id
}

[mattrobinsonsre]

I've raised a PR to implement an aws_ssoadmin_account_assignments resource as our iac would benefit from this.
Support for that PR from anybody following this issue would be helpful.

[gdavison]

HI @daimon243 and everyone else. I've been trying to reproduce this issue, and have not seen similar long times. This is not to say that we don't want to fix this resource, since it can still take a long time. I want to better understand the origin of the problem.

With 1,200 existing users, a plan operation takes approximately 14 minutes. With the 1,200 users and reducing to 1,100, the apply without a refresh takes 185 seconds. Adding back the 100 users (to a total of 1,200) takes a total of 16 minutes including the refresh.

Are you still seeing much longer times as reported above? If so, what version of the provider and terraform are you using? How many users do you have in SSO?

Some things that may be related to the lower times I'm seeing:

• I think AWS may have made some changes on their side, for instance the read API returns the maximum number per pagination request.
• I've used an AWS Managed Microsoft AD as the identity source, since I can use the AD API to provision users.

[gdavison]

Hi @gingersnapz. One option you have is to use for_each along with the function setproduct to combine the principal_id and target_id lists into a common list.

[jsimoni]

@gdavison I'm having a similar issue. I've tried using setproduct, but I get

│ The "for_each" value depends on resource attributes that cannot be
│ determined until apply, so Terraform cannot predict how many instances will
│ be created. To work around this, use the -target argument to first apply
│ only the resources that the for_each depends on.

I was going to create a new issue so here is my:

Reproduction Code [Required]

data "aws_organizations_organization" "this" {}

locals {
  account_id_list = data.aws_organizations_organization.this.accounts
}

module "permissionset" {
  source = "../../..//modules/permissionset"

  permission_set_name        = "name"
  permission_set_description = "description"
  awssso_instance_arn        = var.awsinstance_arn
  managed_policies_to_attach = ["arn:aws:iam::aws:policy/job-function/ViewOnlyAccess"]
}

locals {
  account_permissionset_product = setproduct(var.account_id_list[*].id, var.permission_set_arn_list)
}

# associate the group to the permission set(s) & account(s)
resource "aws_ssoadmin_account_assignment" "group_permissionset_account_assignments" {
  for_each = {
    for association in local.account_permissionset_product : "${association[0]}-${association[1]}" => {
      account_id         = association[0]
      permission_set_arn = association[1]
    }
  }
  instance_arn       = var.awssso_instance_arn
  permission_set_arn = each.value.permission_set_arn

  principal_id   = data.aws_identitystore_group.awssso_group.group_id
  principal_type = "GROUP"

  target_id   = sensitive(each.value.account_id)
  target_type = "AWS_ACCOUNT"
}

Additional context

If I use -target as suggested elsewhere (4149) to provision the permission set first, then the assignments works. However, the explanations I've seen for this error is that Terraform is unable to determine the number of resources to provision at plan so it fails. But in my case, while the arns of the permission sets would be unknown, Terraform can determine the number of assignments to create.

[gdavison]

Hi @jsimoni. Unfortunately, this is a limitation of for_each and its interaction with count, and sometimes affects only the first run. Since for_each and count are handled by Terraform core, you should open an issue on the hashicorp/terraform project.

[daimon243]

Hi @gdavison. I rewrote the infrastructure and instead of one folder with permission sets assigned, I created many folders, divided into small groups. Now, with a total number of users in SSO of about 1000 and assigning rights to 20 employees, I get the maximum execution time from 1 to 6 minutes. In this particular case, there is no problem. With this approach, the request rate limit is not exceeded. But using a list of users as a parameter instead of using for_each seems to be preferable because we can run queries to api in batch.