-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multiple aws accounts with chained providers #1544
Comments
I have prepared a more complete example of the problem out of our codebase. I just create the intermediateProvider and the destinationProvider and invoke the GetCallerIdentity function upon each and try to print the two providers arn.
Which leads to the above described error message that the role cannot be assumed .. |
I have the same code flow in pulumi python for aws and it fails like the go code. The error message is different:
I guess this is a followup error from me calling get_caller_identity on the destination provider and this returns an empty response. The code:
|
I don't think the Python example you have above is functionally equivalent to your Go code as you don't actually construct the peering provider using the intermediate provider as a resource option. The Go example you have does look like what I'd expect and we'll need to do some investigation to understand what's going on there. |
Correct, I do not use the pulumi.ResourceOptions() way but instead inject the Token, access_key, and secret_key from the intermediate provider. I could change the code to:
From my understanding this should be equivalent? It is a little irritating that in Python you have to use |
@Comradin I don't think they'll be equivalent as the provider doesn't actually allow for using |
Hmm, did I misread the provider documentation? https://www.pulumi.com/docs/reference/pkg/aws/provider/#outputs This part states, that all Inputs are implicitly available as outputs. So I should be able to chaint the output of the intermediate provider into the inputs of the peering provider? |
But, following your suggestion I changed my code and now I get the "cannot be assumed" error message like with the Go code.
Ok, this is a bit surprising, did not expect this. |
Thanks for the additional details. Digging into this further, it looks like this is an upstream issue as tracked in hashicorp/terraform-provider-aws#16841 |
I believe this is the same issue tracked in #673, so closing out to track there. |
We have a mutliple aws account setup. In the external accounts we need to modify resources, e.g. establish vpc peerings or add routes to a transit gateway.
There is a specific role in each account containing permissions to execute those external resource modifications.
To assume those roles in the external accounts, there is one role called intermediateRole that is allowed to assume those roles in the external accounts.
To maintain this multi aws account setup with pulumi we tried to establish chained providers with the according roles.
We experience issues with one particular external account/role while the other one works.
Steps:
using the provider from step 2, works as expected
using the provider from step 3, though similar build up to the one from step2, fails.
expressed via code:
whithin each function the correlated chained destinationProvider are built the same way:
the aws.GetCallerIdentity calls are exemplary for using the created providers. For the latter call we get the error:
at this point I came to the conclusion that the role setup in the latter external aws account is wrong hence I tried to verify it via the aws cli, which worked fine.
Therefore I tried a workaround with aws go sdk to directly assume the intermediate role and create the failing destinationProvider:
which worked fine out of the box.
How can I debug this further? Right now I cannot see any difference, that would explain the inconsistent behaviour of the chained providers.
Expected: the intermediate pulumi provider should work for all chained destinationProviders
Actual: it doesn't work for all
The text was updated successfully, but these errors were encountered: