Missing "root" alias aws provider definition in aws-sso component

[MReggler]

Found a bug? Maybe our Slack Community can help.

Describe the Bug

All versions of the aws-sso component released from 1.227.0 onwards do not have an alias = "root" aws provider defined in providers.tf, which prevents planning and/or applying changes to the component if any sso assignments have been made in the root account.

Prior to the release of version 1.227.0, the aws-sso component's providers.tf declared this additional aws provider definition, which is used to deploy the sso_account_assignments_root module in main.tf.

Expected Behavior

• Given that I have defined sso account assignments in the aws-sso component YAML configuration for the account designated as the root account for my organisation ("core-root"),
• When I plan or apply valid changes made to any of the YAML configuration for the component
• Then the component should plan successfully

Steps to Reproduce

Steps to reproduce the behavior:

1. Go to the YAML component configuration for the aws-sso component (either the catalog or where it is used)
2. Add an account_assignments block for the org root account, typically core-root
3. Ensure this matches the output from account-map such that the aws-sso local account_assignments_rootis non-empty
4. Run atmos terraform plan aws-sso --stack core-gbl-identity(where this is env hosting the aws-sso component)
5. You should see the error:

Error: missing provider provider["registry.terraform.io/hashicorp/aws"].root

Screenshots

N/A

Environment (please complete the following information):

Anything that will help us triage the bug will help. Here are some ideas:

• OS: Any
• Atmos component version affected >1.227.0

Additional Context

For reference, the 1.226.0 version of providers.tf which contains the root-aliased provider is here

The 1.227.0 versions of providers.tf for which the root-aliased provider is missing is here

[MReggler]

It looks like this happened due to the sweeping changes to providers.tf that occurred as part of #715

Of note in this PR is that providers.tf that previously used module.iam_roles.org_role_arn and therefore required SuperAdmin deployment (such as aws-sso and account-settings), subsequently use terraform_role_arn which is not guaranteed to be the same for customers where terraform_dynamic_role_enabled is false in account-map.

I am unclear whether this is a separate bug or a intentional breaking change impacting legacy users, but I wonder if this, and the bug raised above, are a side-effect of components with bespoke aws provider configurations being updated to a standardised approach.

[milldr]

We encountered this mistake internally as well, and we have this open PR to resolve the issue:
#740

We also are creating an upgrade guide to explain the why and how of that sweeping account-map and providers.tf change. WIll link that once available

[Nuru]

@MReggler Thank you for opening this issue. Please feel free to try our proposed fix in PR #740 and comment on it there. In particular, if you are so inclined, I would value your feedback on the Change log regarding how well it answers your questions regarding SuperAdmin vs terraform_dynamic_role_enabled deployment.