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

(aws-events): cross-region event rules breaks cross-account codepipelines #15639

Closed
jdvornek opened this issue Jul 19, 2021 · 4 comments · Fixed by #15717
Closed

(aws-events): cross-region event rules breaks cross-account codepipelines #15639

jdvornek opened this issue Jul 19, 2021 · 4 comments · Fixed by #15717
Assignees
Labels
@aws-cdk/aws-events Related to CloudWatch Events bug This issue is a bug. in-progress This issue is being actively worked on. p1

Comments

@jdvornek
Copy link
Contributor

Upgrading from <=1.112.0 caused my cross-account codepipelines to be undeployable. I have a multi-account setup with CodeCommit repositories hosted in one account triggering CodePipelines in several different accounts. Following CDK upgrade deployment fails with

Access to the resource arn:aws:iam::9876543210:role/SomeRole is denied. Reason: Cross-account pass role is not allowed.

It appears as though the change in #14731 alters the change of the rule target to include a roleArn, at least that appears to be the difference in what is synthesized.

Reproduction Steps

Apologies if this is somewhat convoluted, I've attempted to extract an example that best represents the situation as it exists in my application. If you need more detail or more color around the situation, let me know.

app.js
#!/usr/bin/env node
const config = require('../lib/config.json');

const cdk = require('@aws-cdk/core');
const { SourceStack } = require('../lib/SourceStack');
const { PipelineStack } = require('../lib/PipelineStack');

const app = new cdk.App();
new SourceStack(app, 'EventsIssueSourceStack', {
  env: config.envs.account_a,
});
new PipelineStack(app, 'EventsIssuePipelineStack', {
  env: config.envs.account_b,
});
config.json
{
  "envs": {
    "account_a": { "account": "0123456789", "region": "us-east-1" },
    "account_b": { "account": "9876543210", "region": "us-east-1" }
  }
}
SourceStack.js
const cdk = require('@aws-cdk/core');
const codecommit = require('@aws-cdk/aws-codecommit')

class SourceStack extends cdk.Stack {

  constructor(scope, id, props) {
    super(scope, id, props);

    new codecommit.Repository(this, 'Repo', {
      repositoryName: 'SomeRepository'
    });
  }
}

module.exports = { SourceStack }
PipelineStack.js
const cdk = require('@aws-cdk/core');
const codecommit = require('@aws-cdk/aws-codecommit');
const codepipeline = require('@aws-cdk/aws-codepipeline');
const actions = require('@aws-cdk/aws-codepipeline-actions');

const config = require('./config.json');

class RepositoryReference extends cdk.Stack {
  constructor(scope, id, props) {
    super(scope, id, props);
    this.repo = codecommit.Repository.fromRepositoryName(this, 'RepositoryRef', props.repo_name);
  }
}

class PipelineStack extends cdk.Stack {

  constructor(scope, id, props) {
    super(scope, id, props);
    this.props = props;

    const repo_ref = new RepositoryReference(this, 'RepoRef', {
      env:       config.envs.account_a,
      repo_name: 'SomeRepository'
    });
    
    this.source_output = new codepipeline.Artifact('SourceOutput');

    this.pipeline = new codepipeline.Pipeline(this, 'Pipeline', {
      stages: [
        {
          stageName: 'Source',
          actions:   [
            new actions.CodeCommitSourceAction({
                                                 actionName: 'SourceCheckout',
                                                 repository: repo_ref.repo,
                                                 output:     this.source_output
                                               })
          ]
        },
        {
          stageName: 'IrrelevantPlaceholder',
          actions:   [
            new actions.ManualApprovalAction({
                                               actionName: 'Approval'
                                             })
          ]
        }
      ]
    });
  }

}

module.exports = { PipelineStack };

What did you expect to happen?

I expected the application to deploy and function as it did in version <=1.112.0.

What actually happened?

I received an error:

Access to the resource arn:aws:iam::9876543210:role/SomeRole is denied. Reason: Cross-account pass role is not allowed. (Service: AmazonCloudWatchEvents; Status Code: 400; Error Code: AccessDeniedException; Request ID: 01234-abcd-xyz; Proxy: null)

Environment

  • CDK CLI Version : 1.114.0
  • Framework Version: 1.114.0
  • Node.js Version: v14.17.3
  • OS : OSX 11.4
  • Language (Version): javascript

Other

It would seem to me that the cross-region events features should be rolled back or put on a flag if a quick fix is not available. As of now I'm effectively locked at version 1.112.0.


This is 🐛 Bug Report

@jdvornek jdvornek added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Jul 19, 2021
@github-actions github-actions bot added the @aws-cdk/aws-events Related to CloudWatch Events label Jul 19, 2021
@rix0rrr
Copy link
Contributor

rix0rrr commented Jul 22, 2021

I'm suprised that this setup used to work at all, given that it looks like CodePipeline doesn't seem to support cross-account CodeCommit repositories. There is no mention of an account field here: https://docs.aws.amazon.com/codepipeline/latest/userguide/action-reference-CodeCommit.html

And when I try your code for myself, I get this error in CodePipeline:

image

@jdvornek
Copy link
Contributor Author

I must have missed a dependency between the two stacks, please try deploying SourceStack first manually or add an explicit dependency. Again, I was trying to replicate something illustrative from a much larger application here.

There's a published guide for a cross-account codepipeline, but really under the hood, it is just cross-account event delivery.

@rix0rrr
Copy link
Contributor

rix0rrr commented Jul 22, 2021

Yes, I've seen it work now which is crazy.

rix0rrr added a commit that referenced this issue Jul 22, 2021
When we started supporting cross-region event targets, we needed
to add a role to the event-bus target. At that point, we also
opted to fall back to the role that the event target requested
for itself.

However, that was wrong: the role used in that place is *only*
for passing events between event buses, and *never* for triggering
the actual target.

Solution: don't fall back, only use a special role for event passing.
In fact, don't even do it if the target isn't in a different region,
because apparently it's not necessary for cross-account event
passing at all.

Refactor the `events` code a little to make clear what is happening
and why, because it was string to get messy.

Fixes #15639.
@NGL321 NGL321 added in-progress This issue is being actively worked on. p1 and removed needs-triage This issue or PR still needs to be triaged. labels Jul 24, 2021
@mergify mergify bot closed this as completed in #15717 Aug 13, 2021
mergify bot pushed a commit that referenced this issue Aug 13, 2021
…15717)

When we started supporting cross-region event targets, we needed
to add a role to the event-bus target. At that point, we also
opted to fall back to the role that the event target requested
for itself.

However, that was wrong: the role used in that place is *only*
for passing events between event buses, and *never* for triggering
the actual target.

Solution: don't fall back, only use a special role for event passing.
In fact, don't even do it if the target isn't in a different region,
because apparently it's not necessary for cross-account event
passing at all.

Refactor the `events` code a little to make clear what is happening
and why, because it was starting to get messy.

Fixes #15639.


----

*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

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

hollanddd pushed a commit to hollanddd/aws-cdk that referenced this issue Aug 26, 2021
…ws#15717)

When we started supporting cross-region event targets, we needed
to add a role to the event-bus target. At that point, we also
opted to fall back to the role that the event target requested
for itself.

However, that was wrong: the role used in that place is *only*
for passing events between event buses, and *never* for triggering
the actual target.

Solution: don't fall back, only use a special role for event passing.
In fact, don't even do it if the target isn't in a different region,
because apparently it's not necessary for cross-account event
passing at all.

Refactor the `events` code a little to make clear what is happening
and why, because it was starting to get messy.

Fixes aws#15639.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
TikiTDO pushed a commit to TikiTDO/aws-cdk that referenced this issue Sep 6, 2021
…ws#15717)

When we started supporting cross-region event targets, we needed
to add a role to the event-bus target. At that point, we also
opted to fall back to the role that the event target requested
for itself.

However, that was wrong: the role used in that place is *only*
for passing events between event buses, and *never* for triggering
the actual target.

Solution: don't fall back, only use a special role for event passing.
In fact, don't even do it if the target isn't in a different region,
because apparently it's not necessary for cross-account event
passing at all.

Refactor the `events` code a little to make clear what is happening
and why, because it was starting to get messy.

Fixes aws#15639.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
david-doyle-as24 pushed a commit to david-doyle-as24/aws-cdk that referenced this issue Sep 7, 2021
…ws#15717)

When we started supporting cross-region event targets, we needed
to add a role to the event-bus target. At that point, we also
opted to fall back to the role that the event target requested
for itself.

However, that was wrong: the role used in that place is *only*
for passing events between event buses, and *never* for triggering
the actual target.

Solution: don't fall back, only use a special role for event passing.
In fact, don't even do it if the target isn't in a different region,
because apparently it's not necessary for cross-account event
passing at all.

Refactor the `events` code a little to make clear what is happening
and why, because it was starting to get messy.

Fixes aws#15639.


----

*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/aws-events Related to CloudWatch Events bug This issue is a bug. in-progress This issue is being actively worked on. p1
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants