Skip to content
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

Closed
nasuboots opened this issue Jan 28, 2021 · 9 comments · Fixed by #12925
Closed
Assignees
Labels
@aws-cdk/pipelines CDK Pipelines library bug This issue is a bug. needs-triage This issue or PR still needs to be triaged.

Comments

@nasuboots
Copy link

Deploying a subclass of Stage with CdkPipeline to a different region fails because of cdk synth error.

Reproduction Steps

#!/usr/bin/env node
import 'source-map-support/register';

import { App, Construct, Stage, Stack, StackProps, StageProps, SecretValue } from '@aws-cdk/core';
import { CdkPipeline, SimpleSynthAction } from '@aws-cdk/pipelines';
import * as codepipeline from '@aws-cdk/aws-codepipeline';
import * as codepipeline_actions from '@aws-cdk/aws-codepipeline-actions';
import * as dynamodb from '@aws-cdk/aws-dynamodb';

class DatabaseStack extends Stack {
  constructor(scope: Construct, id: string, props?: StageProps) {
    super(scope, id, props);

    new dynamodb.Table(this, 'Table', {
      partitionKey: { name: 'PK', type: dynamodb.AttributeType.STRING },
    });
  }
}

class MyApplication extends Stage {
  constructor(scope: Construct, id: string, props?: StageProps) {
    super(scope, id, props);

    new DatabaseStack(this, 'Database');
  }
}

class AwsCdkPipelinesCrossRegionStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const sourceArtifact = new codepipeline.Artifact();
    const cloudAssemblyArtifact = new codepipeline.Artifact();

    const pipeline = new CdkPipeline(this, 'Pipeline', {
      pipelineName: 'MyAppPipeline',
      cloudAssemblyArtifact,

      sourceAction: new codepipeline_actions.GitHubSourceAction({
        actionName: 'GitHub',
        output: sourceArtifact,
        oauthToken: SecretValue.secretsManager('GITHUB_TOKEN_NAME'),
        owner: 'OWNER',
        repo: 'REPO',
      }),

      synthAction: SimpleSynthAction.standardNpmSynth({
        sourceArtifact,
        cloudAssemblyArtifact,
      }),
    });

    pipeline.addApplicationStage(new MyApplication(this, 'Prod', {
      // stage env
      env: {
        account: '111111111111',
        region: 'eu-west-1',
      },
    }));
  }
}

const app = new App();
new AwsCdkPipelinesCrossRegionStack(app, 'AwsCdkPipelinesCrossRegionStack', {
  // pipeline env
  env: {
    account: '111111111111',
    region: 'us-east-1',
  },
});
$ npm run cdk synth

> aws-cdk-pipelines-cross-region@0.1.0 cdk /workspaces/aws-cdk-pipelines-cross-region
> cdk "synth"


/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/private/refs.ts:57
    throw new Error(
          ^
Error: Stack "AwsCdkPipelinesCrossRegionStack" cannot consume a cross reference from stack "cross-region-stack-111111111111:eu-west-1". Cross stack references are only supported for stacks deployed to the same environment or between nested stacks and their parent stack
    at resolveValue (/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/private/refs.ts:57:11)
    at Object.resolveReferences (/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/private/refs.ts:33:24)
    at Object.prepareApp (/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/private/prepare-app.ts:31:3)
    at Object.synthesize (/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/private/synthesis.ts:24:3)
    at App.synth (/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/stage.ts:188:23)
    at process.<anonymous> (/workspaces/aws-cdk-pipelines-cross-region/node_modules/@aws-cdk/core/lib/app.ts:123:45)
    at Object.onceWrapper (events.js:422:26)
    at process.emit (events.js:315:20)
    at process.EventEmitter.emit (domain.js:467:12)
    at process.emit (/workspaces/aws-cdk-pipelines-cross-region/node_modules/source-map-support/source-map-support.js:495:21)

What did you expect to happen?

Generating a template succeeded.

What actually happened?

pipeline env stage env result
111111111111, us-east-1 111111111111, us-east-1 Successfully synthesized to /workspaces/aws-cdk-pipelines-cross-region/cdk.out
111111111111, us-east-1 222222222222, us-east-1 Successfully synthesized to /workspaces/aws-cdk-pipelines-cross-region/cdk.out
111111111111, us-east-1 111111111111, eu-west-1 Error: Stack "AwsCdkPipelinesCrossRegionStack" cannot consume a cross reference from stack "cross-region-stack-111111111111:eu-west-1"
111111111111, us-east-1 222222222222, eu-west-1 Error: Stack "AwsCdkPipelinesCrossRegionStack" cannot consume a cross reference from stack "cross-region-stack-111111111111:eu-west-1"

Environment

  • CDK CLI Version : v1.87.0
  • Framework Version: v1.87.0
  • Node.js Version: v14.15.4
  • OS : Debian GNU/Linux 10 (buster)
  • Language (Version): TypeScript (3.9.7)

Other

cdk version result
v1.76 Successfully synthesized to /workspaces/aws-cdk-pipelines-cross-region/cdk.out
v1.77 Successfully synthesized to /workspaces/aws-cdk-pipelines-cross-region/cdk.out
v1.78 ~ Error: Stack "AwsCdkPipelinesCrossRegionStack" cannot consume a cross reference from stack "cross-region-stack-111111111111:eu-west-1"

This is 🐛 Bug Report

@nasuboots nasuboots added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jan 28, 2021
@github-actions github-actions bot added the @aws-cdk/pipelines CDK Pipelines library label Jan 28, 2021
@markusbecker
Copy link

markusbecker commented Jan 29, 2021

Uff, i though me was the problem. Having the same issue. If stage region != pipeline region i get the same error. (1.87.1)

@rix0rrr
Copy link
Contributor

rix0rrr commented Feb 8, 2021

Unfortunately does not reproduce for me. Using the code above, and using the following versions:

1.78.0 (version mentioned in the title)
1.87.0 (version mentioned in the "environment" block)
1.83.0 (just one I happened to have lying around)

And then:

$ npx cdk synth
Successfully synthesized to /Users/huijbers/Temp/testpipeline/cdk.out
Supply a stack id (cross-region-stack-111111111111:eu-west-1, AwsCdkPipelinesCrossRegionStack) to display its template.

@rix0rrr
Copy link
Contributor

rix0rrr commented Feb 8, 2021

Have you cut something out of your code sample that is causing the actual issue?

@rix0rrr rix0rrr added the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Feb 8, 2021
@rix0rrr
Copy link
Contributor

rix0rrr commented Feb 8, 2021

Is the issue perhaps that you have ^ dependencies somewhere, and/or there are multiple copies of the CDK core library in your dependency tree?

grep '\^' package.json     # <-- should NOT show any CDK libraries
find . -path \*/@aws-cdk/core   # <-- should only find ONE directory

@rix0rrr rix0rrr changed the title (pipelines): Deploying a subclass of Stage to a different region is not working from v1.78 (pipelines): "cannot consume a cross reference from stack" when using CDK Pipelines Feb 8, 2021
@tompiscitell
Copy link

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.

grep '\^' package.json 
    "@types/jest": "^26.0.10",
    "jest": "^26.4.2",
    "ts-jest": "^26.2.0",
    "ts-node": "^9.0.0",
    "source-map-support": "^0.5.16"

find . -path \*/@aws-cdk/core  
./node_modules/@aws-cdk/core

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.

@mathewlk
Copy link

mathewlk commented Feb 8, 2021

+1 - I've tried versions 1.86 and 1.88 and am seeing the same issue.

@oleksii-donoha
Copy link

oleksii-donoha commented Feb 8, 2021

I have the same problem with Python libs version 1.88. Both environments are bootstrapped.
Regarding stale libs, I don't think I have any since all CDK libs are frozen to 1.88 in setup.py and this issue can be reproduced both on local machine and clean CodeBuild environment.

@github-actions github-actions bot removed the response-requested Waiting on additional info and feedback. Will move to "closing-soon" in 7 days. label Feb 9, 2021
@rix0rrr
Copy link
Contributor

rix0rrr commented Feb 9, 2021

Ha haaaah! Found the culprit!

    "@aws-cdk/aws-kms:defaultKeyPolicies": true,

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.

@mergify mergify bot closed this as completed in #12925 Feb 9, 2021
mergify bot pushed a commit that referenced this issue Feb 9, 2021
…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*
@github-actions
Copy link

github-actions bot commented Feb 9, 2021

⚠️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.

nija-at pushed a commit that referenced this issue Feb 9, 2021
…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*
nija-at pushed a commit that referenced this issue Feb 9, 2021
…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*
TLadd pushed a commit to TLadd/aws-cdk that referenced this issue Feb 9, 2021
…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*
NovakGu pushed a commit to NovakGu/aws-cdk that referenced this issue Feb 18, 2021
…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*
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
@aws-cdk/pipelines CDK Pipelines library bug This issue is a bug. needs-triage This issue or PR still needs to be triaged.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants