[Bug]: Provider iam role chaining error when there is an unknown variable in the role_arn argument

[dylan-pvt]

Terraform Core Version

1.9.7

AWS Provider Version

5.70.0

Affected Resource(s)

All

Expected Behavior

Before provider version 5.67, it was possible to have an unknown variable (output for a ressource for example) for the role_arn argument in provider assume_role configuration without having warning for provider with single assume_role. With the new feature for provider IAM role chaining, this is an error.

Actual Behavior

Provider IAM role chaining with an unknown variable for the role_arn argument results in error and fails to plan.

provider "aws" {
   region = "eu-west-1"
   assume_role {
     role_arn = "arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME"
   }
   assume_role {
     role_arn = "arn:aws:iam::${aws_organizations_account.account.account_id}:role/FINAL_ROLE_NAME"
   }
 }

Since provider version 5.67, there is also a warning with unknown variable for the role_arn for a single assume_role.

provider "aws" {
   region = "eu-west-1"
   assume_role {
     role_arn = "arn:aws:iam::${module.account.account_id}:role/ROLE_NAME"
   }
 }

Relevant Error/Panic Output Snippet

The argument "role_arn" is required, but no definition was found.

Terraform Configuration Files

providers.tf

provider "aws" {
   alias  = "account"
   region = "eu-west-1"
   assume_role {
     role_arn = "arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME"
  }
}

provider "aws" {
   alias  = "new_account"
   region = "eu-west-1"
   assume_role {
     role_arn = "arn:aws:iam::123456789012:role/INITIAL_ROLE_NAME"
   }
   assume_role {
     role_arn = "arn:aws:iam::${aws_organizations_account.account.account_id}:role/FINAL_ROLE_NAME"
   }
 }

main.tf

resource "aws_organizations_account" "account" {
  provider = aws.account
  name     = "my_new_account"
  email    = "xxxxxxxxx@xxxxxxxx"
}

resource "aws_vpc" "vpc" {
  provider   = aws.new_account
  cidr_block = "10.0.0.0/16"
}

Steps to Reproduce

Run the above configuration

Debug Output

No response

Panic Output

No response

Important Factoids

No response

References

No response

Would you like to implement a fix?

None

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• 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.

[justinretzolk]

Hey @dylan-pvt 👋 Thank you for taking the time to raise this! Something similar was noticed in #39296 and resulted in a change implemented by #39328. There are some recommendations in the comments there about handling some of this via a dynamic block. One difference I noted is that it seems you're attempting to instantiate one instance of the provider by using the output of a resource created by another instantiation of the provider in the same configuration. Truthfully, I'm surprised to hear that ever worked, so it's unclear to me if that will work with these workarounds, but I would be interested to hear if it does.

[ewbankkit]

This situation is exactly what deferred actions was built to support.

[lorengordon]

I didn't realize dynamic blocks were supported in provider configs. I guess you're saying something like this ought to work?

provider "aws" {
  dynamic "assume_role" {
    for_each = var.aws_assume_role_arn != null ? [var.aws_assume_role_arn] : []
    content {
      role_arn = assume_role.value
    }
  }
}

variable "aws_assume_role_arn" {
  description = "ARN of the role to assume for the AWS provider"
  type        = string
  default     = null
}