-
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 consume a cross reference from stack" when using CDK Pipelines #12741
Comments
Uff, i though me was the problem. Having the same issue. If stage region != pipeline region i get the same error. (1.87.1) |
Unfortunately does not reproduce for me. Using the code above, and using the following versions:
And then:
|
Have you cut something out of your code sample that is causing the actual issue? |
Is the issue perhaps that you have
|
I'm running into the same problem and I can confirm I don't have multiple copies of the CDK core library in my dependency tree.
I pushed the code I used to reproduce this here: https://github.com/tompiscitell/test-cdk-pipeline. It has branches with versions 1.77.0 and 1.88.0 in addition to 1.87.1 (master). I'm seeing the same behavior as @nasuboots in that it works on 1.77.0 and doesn't work on any of the later version. |
+1 - I've tried versions 1.86 and 1.88 and am seeing the same issue. |
I have the same problem with Python libs version 1.88. Both environments are bootstrapped. |
Ha haaaah! Found the culprit!
Removing that makes it work. Thanks for the repro @tompiscitell, that was extremely helpful. Still not quite sure why the error didn't repro for me, but now we have a way to investigate. |
…s set (#12925) When the `trustAccountIdentities` flag is set (either directly, or set by default via the `@aws-cdk/aws-kms:defaultKeyPolicies` feature flag), any grant statements are always added to the principal OR resource, defaulting to the principal if possible. In cross-environment usage, this means that the principal IAM policy is updated, but the key policy is never updated. However, cross-environment usage always requires the key policy to be updated. Attempting to use the key in a cross-environment usage with `trustAccountIdentities` enabled initially presents itself as a cross-environment reference issue, but even if the stack was successfully deployed, the delegated account would not have access to use/admin the key. This change updates the logic to make use of the existing cross-environment logic whenever cross-environment usage is detected, regardless of the value of `trustAccountIdentities`. This has the impact of fixing the cross-env references and ensuring the key policy is properly updated. fixes #12921, fixes #12741 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
…s set (#12925) When the `trustAccountIdentities` flag is set (either directly, or set by default via the `@aws-cdk/aws-kms:defaultKeyPolicies` feature flag), any grant statements are always added to the principal OR resource, defaulting to the principal if possible. In cross-environment usage, this means that the principal IAM policy is updated, but the key policy is never updated. However, cross-environment usage always requires the key policy to be updated. Attempting to use the key in a cross-environment usage with `trustAccountIdentities` enabled initially presents itself as a cross-environment reference issue, but even if the stack was successfully deployed, the delegated account would not have access to use/admin the key. This change updates the logic to make use of the existing cross-environment logic whenever cross-environment usage is detected, regardless of the value of `trustAccountIdentities`. This has the impact of fixing the cross-env references and ensuring the key policy is properly updated. fixes #12921, fixes #12741 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s set (#12925) When the `trustAccountIdentities` flag is set (either directly, or set by default via the `@aws-cdk/aws-kms:defaultKeyPolicies` feature flag), any grant statements are always added to the principal OR resource, defaulting to the principal if possible. In cross-environment usage, this means that the principal IAM policy is updated, but the key policy is never updated. However, cross-environment usage always requires the key policy to be updated. Attempting to use the key in a cross-environment usage with `trustAccountIdentities` enabled initially presents itself as a cross-environment reference issue, but even if the stack was successfully deployed, the delegated account would not have access to use/admin the key. This change updates the logic to make use of the existing cross-environment logic whenever cross-environment usage is detected, regardless of the value of `trustAccountIdentities`. This has the impact of fixing the cross-env references and ensuring the key policy is properly updated. fixes #12921, fixes #12741 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s set (aws#12925) When the `trustAccountIdentities` flag is set (either directly, or set by default via the `@aws-cdk/aws-kms:defaultKeyPolicies` feature flag), any grant statements are always added to the principal OR resource, defaulting to the principal if possible. In cross-environment usage, this means that the principal IAM policy is updated, but the key policy is never updated. However, cross-environment usage always requires the key policy to be updated. Attempting to use the key in a cross-environment usage with `trustAccountIdentities` enabled initially presents itself as a cross-environment reference issue, but even if the stack was successfully deployed, the delegated account would not have access to use/admin the key. This change updates the logic to make use of the existing cross-environment logic whenever cross-environment usage is detected, regardless of the value of `trustAccountIdentities`. This has the impact of fixing the cross-env references and ensuring the key policy is properly updated. fixes aws#12921, fixes aws#12741 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
…s set (aws#12925) When the `trustAccountIdentities` flag is set (either directly, or set by default via the `@aws-cdk/aws-kms:defaultKeyPolicies` feature flag), any grant statements are always added to the principal OR resource, defaulting to the principal if possible. In cross-environment usage, this means that the principal IAM policy is updated, but the key policy is never updated. However, cross-environment usage always requires the key policy to be updated. Attempting to use the key in a cross-environment usage with `trustAccountIdentities` enabled initially presents itself as a cross-environment reference issue, but even if the stack was successfully deployed, the delegated account would not have access to use/admin the key. This change updates the logic to make use of the existing cross-environment logic whenever cross-environment usage is detected, regardless of the value of `trustAccountIdentities`. This has the impact of fixing the cross-env references and ensuring the key policy is properly updated. fixes aws#12921, fixes aws#12741 ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Deploying a subclass of Stage with CdkPipeline to a different region fails because of
cdk synth
error.Reproduction Steps
What did you expect to happen?
Generating a template succeeded.
What actually happened?
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: