Support cross-account context queries from bootstrap stack

[rix0rrr]

See title.

---

This is a 🚀 Feature Request

[dnascimento]

@rix0rrr how would you address this issue? What's the best way to fix this? Happy to contribute

[ColeMurray]

Is there additional documentation on work needed to support this feature?

[blimmer]

There's a good thread in the cdk.dev slack about this. It appears that a workaround is to populate the VPC IDs in a cdk.context.json file.

[agalazis]

so one fix is to have a script that populates cdk.context.json independently ?

[hoegertn]

You can synth locally once and then commit the file.

[agalazis]

yep that's what I thought xD. Despite seeing many projects having context file in .gitignore , committing it is the recommended approach :

Don't forget to add the cdk.context.json file to your source control repository 
to ensure that subsequent synth commands will return the same result, 
and that your AWS account won't be needed when synthesizing from your build system.

from
https://docs.aws.amazon.com/cdk/latest/guide/context.html

still not only about running synth I will add a script that

• switches off the flag
• iterates though my environments and does synth
• switches on the flag
• deserves a script entry in package.json

[sean-kennedy-songtradr]

Hi, I have come across this problem while building a cdk pipeline, I think a solution/workaround may to to give the codebuild role or whatever role is performing the synth action permissions to use describe or list actions for whatever resource it needs such as vpc or listeners etc and then it can successfully synth with all the required context information.

Does this seem like a valid solution/workaround? I only discovered this today and will attempt to validate my findings tomorrow.

Sorry if this is the wrong place to mention it. Can give more information about my scenario if needed.

[skinny85]

It's not enough @sean-kennedy-songtradr , because the cdk synth build may happen in a different account/region than the stacks that need the context values are in.

[skinny85]

The best workaround is:

1. Do the synth locally with the correct credentials (read-only should be fine).
2. Commit and push the cdk.context.json file that gets generated this way.

[sean-kennedy-songtradr]

It's not enough @sean-kennedy-songtradr , because the cdk synth build may happen in a different account/region than the stacks that need the context values are in.

In my scenario (as far as I can tell) I am always synthesizing in the same account, that synth will require some ssm parameters from different accounts/regions and then use them in .fromLookup calls, I am using the CDK credential plugin so that cdk can assume the relevant role when it needs to get those parameters and make context queries.

If I can make sure the build always happens in the same account and region is this a valid method of supporting context queries right now or would you say it's a bit hacky for lack of a better term?

[skinny85]

I wouldn't use the word "hacky" necessarily, but I would say it's not a practice we want to encourage exactly. The reason is that we want to separate synthesizing your CDK application, which might mean running code from arbitrary third-party dependencies that you might not want to trust completely, from deploying it. If you give your build step permissions to read from your account, the third party dependencies will have those permissions as well.

Perhaps you consider that risk acceptable, in which case, go right ahead 🙂.

[greg-aws]

@skinny85
This issue has kind of been a thorn in my side lately, so I wanted to make sure I understand it. It looks like context queries are currently done with whatever base credentials are present rather than assuming a role from Stack's account. Does it make sense to add an additional context lookup role to the bootstrap /w the appropriate read permissions and when an SDK is retrieved via sdk-provider.ts the assumeRoleArn is provided in CredentialOptions?

[skinny85]

@rix0rrr should be able to answer that question better than me.

Rico, would you mind answering @greg-aws's question? Does new-style synthesis come into play here?

[redbaron]

@greg-aws, something like cdk-hnb659fds-lookup-role-{ACCOUNT_ID}-{REGION} with read only view access in the target account?

[greg-aws]

@greg-aws, something like cdk-hnb659fds-lookup-role-{ACCOUNT_ID}-{REGION} with read only view access in the target account?

Exactly, in terms of the actual policy I would want some input on. We could be fairly fine grained to only allow access to the current actions required or it would be a more broad read policy which would leave room for future features.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.