-
Notifications
You must be signed in to change notification settings - Fork 4k
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
pipelines: Cannot perform lookup in cross-account nested stack #25171
Comments
I believe when you |
Everything works fine when the resource is in a normal Stack and fails when it is in a Nested Stack. All accounts have been bootstrapped correctly. |
@growak Thank you for your immediate response. Are you able to provide a small working sample that I can reproduce in my account? This will help us address this issue much easier. |
Do you want a code repository or can I copy paste the code in comments? |
@growak Please feel free to just copy paste the minimal required code in the comments or in the issue description with code blocks, I will copy/paste into my IDE and try reproduce this error. |
flow.ts:
main.ts:
core.ts:
network.ts:
|
I was able to reproduce this.
This occurs when you need to perform a lookup within a cross-account nested stack. I'm not aware of a way you can directly fix this within your app, but I think a viable workaround could be refactoring your code such that lookups are performed only in top-level stacks, with the values passed to the nested stacks once the lookup has been properly performed I'm also not super sure what is causing this behavior with nested stacks to begin with, I'm not terribly familiar with them |
Hey Peter, thank you for your answer. I had the same issue creating VPC in a NestedStack. Were you able to reproduce that bug too? I didn't test other constructs. |
Yes, creating a VPC can cause a lookup to occur (lookup stack AZs) depending on how you have it configured. This is likely what's occurring for you in this case |
Thank you for your answer. Isn't that a bug? Any idea how to fix it? I may try to do a PR! |
Sorry I didn't reply to this @growak, yes, this is a bug! And, I'm not really sure at all why this is occurring. If you have any ideas, a PR would be very welcome! Otherwise, we'll try to investigate and fix this when we can |
I think the issue here is that the NestedStackSynthesizer does not pass the The solution is probably to somehow inherit the settings from the parent stack synthesizer. |
Hi, encountered exactly the same problem on a Python and a Typescript CDK pipeline. When passing the role to the synthesizeTemplate method, the NestedStack indeed assume the cross-account role and is able to perform the lookup on the target account. Attached a PR that solves the issue. |
@IgnacioAcunaF were you still interested in continuing the PR? |
Hi @peterwoodworth yes. I haven't been able to upload some changes the last weeks, but I think I'll be able to do it the next one. Thanks for the reminder |
+1 to the affected users count. Watching this thread. |
NestedStack's synthesizer doesn't receive the lookupRoleArn from the parent stack synthesizer, so the NestedStack tries with local credentials (of the deployment account) instead of assuming a cross-account role (on the target account) as regular non-nested Stack would do. This PR aims to add lookupRoleArn reference to the StackSynthesizer class and IStackSynthesizer, so it can be use on the NestedStack to explicitly set an IAM role in case of parent stack having one already defined, so CDK uses the role instead of local credentials. Closes #25171. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
NestedStack's synthesizer doesn't receive the lookupRoleArn from the parent stack synthesizer, so the NestedStack tries with local credentials (of the deployment account) instead of assuming a cross-account role (on the target account) as regular non-nested Stack would do. This PR aims to add lookupRoleArn reference to the StackSynthesizer class and IStackSynthesizer, so it can be use on the NestedStack to explicitly set an IAM role in case of parent stack having one already defined, so CDK uses the role instead of local credentials. Closes aws#25171. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
NestedStack's synthesizer doesn't receive the lookupRoleArn from the parent stack synthesizer, so the NestedStack tries with local credentials (of the deployment account) instead of assuming a cross-account role (on the target account) as regular non-nested Stack would do. This PR aims to add lookupRoleArn reference to the StackSynthesizer class and IStackSynthesizer, so it can be use on the NestedStack to explicitly set an IAM role in case of parent stack having one already defined, so CDK uses the role instead of local credentials. Closes aws#25171. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Describe the bug
When a resource is created in a NestedStack in a cross-account pipeline, the Build/Synth phase failed with he following error message: Need to perform AWS calls for account 222222222222, but the current credentials are for 111111111111.
111111111111 is the pipeline account
222222222222 is the target account where the resource should be deployed.
If the same resource is moved to the parent stack everything works.
Expected Behavior
Resource creation should work in NestedStack in cross-account pipelines.
Current Behavior
Resource creation failed in NestedStack in cross-account pipelines.
Reproduction Steps
Create a pipeline.
Create a stage in a different account.
Create a NestedStack inside de stage stack.
Create a resource in the Nested Stack.
Possible Solution
No response
Additional Information/Context
No response
CDK CLI Version
2.74.0
Framework Version
No response
Node.js Version
v16.20.0
OS
Amazon-Linux 2023
Language
Typescript
Language Version
No response
Other information
No response
The text was updated successfully, but these errors were encountered: