Provider with AssumeRoleArn uses default profile when profile is not specified

[massimob76]

What is the bug?

If aws_assume_role_arn is specified, but no profile is given,
the provider will assume that the 'default' profile will assume the given role arn.
This is not necessarily true, for instance if AWS credentials are specified via environment variables they should take the precedence and not force to use the 'default' profile.

How can one reproduce the bug?

1. Create a role 'opensearch-role' that can manage the opensearch cluster
2. Create a role 'opensearch-build' that can assume the opensearch-role
3. Allow the local user to assume the 'opensearch-build' role, but not the 'opensearch-role' directly.
   So it should look like:
   local user => opensearch-build => opensearch-role
   but the local user should not be able to assume 'opensearch-role' directly
4. configure the opensearch provider like:

provider "opensearch" {
  url                 = "https://...."
  aws_assume_role_arn = "arn:aws:iam::...:role/opensearch-role"
}

5. the local user should assume the opensearch-build role:

aws sts assume-role --role-arn arn:aws:iam::...:role/opensearch-build --role-session-name test

and make sure that the AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN are set
6. TF_LOG=debug terraform apply:
you should get an error similar to this:

<Message>User: arn:aws:iam::...:user/some-user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::...:role/opensearch-role</Message>
...
Error: NoCredentialProviders: no valid providers in chain. Deprecated.

What is the expected behavior?

No errors, since opensearch-build is allowed to assume opensearch-role

What is your host/environment?

Macbook Pro - MacOS Ventura 13.2

Do you have any screenshots?

Do you have any additional context?

Add any other context about the problem.

[moritzzimmer]

guess this is the same as in #61

[massimob76]

guess this is the same as in #61

Oh I didn't noticed that issue. Yes it's the same issue of #61 since it was reopened.
The PR should hopefully fix it.

[prudhvigodithi]

[Untriage]
Closing this duplicate of #61, @massimob76 I have added a comment to your PR, please take a look.
Thank you