aws / aws/aws-cdk

[pipelines]: Support custom Cross-Account actions (by default, SelfMutate fails to deploy support stack)

Open
#16,374 4 comments 2 reactions 0 assignees View on GitHub
@aws-cdk/pipelines effort/medium feature-request p2
Dominant language
TypeScript
Stars
12.9k
Forks
4.6k
Avg merge
1d 19h
Merged PRs (30d)
74

Description

While running a CDK pipeline I get an error message that implies that either the trust on the bootstrap or the boostrap itself was not setup properly. From my naive point of view, it seems to be setup correctly.

### Reproduction Steps

The action.

```
// class to deploy to EBS
class ElasticBeanstalkDeployAction implements IAction {
actionProperties: ActionProperties;

constructor(private props: ElasticBeanstalkDeployActionProps) {
this.actionProperties = {
...this.props,
category: ActionCategory.DEPLOY,
actionName: `${this.props.id}-elasticbeanstalk-deploy-action`,
owner: 'AWS',
provider: 'ElasticBeanstalk',
account: "PRODACCOUNTNUMBER",
artifactBounds: {
minInputs: 1,
maxInputs: 1,
minOutputs: 0,
maxOutputs: 0,
},
inputs: [this.props.input],
};
}

bind(scope: Construct, stage: IStage, options: ActionBindOptions): ActionConfig {

options.bucket.grantRead(options.role);
options.role.addManagedPolicy(ManagedPolicy.fromManagedPolicyArn(scope, "ebs-permissions", 'arn:aws:iam::aws:policy/AdministratorAccess-AWSElasticBeanstalk'));

return {
configuration: {
ApplicationName: this.props.ebsApplicationName,
EnvironmentName: this.props.ebsEnvironmentName,
},
};
}

onStateChange(name: string, target?: IRuleTarget, options?: RuleProps): Rule {
throw new Error('not supported');
}
}
```

The Step:
```
class EBSDeployStep extends pipelines.Step implements pipelines.ICodePipelineActionFactory {
constructor(private readonly name: string, private readonly input: FileSet) {
super(name)
}

public produceAction(stage: IStage, options: ProduceActionOptions): CodePipelineActionFactoryResult {

stage.addAction(new ElasticBeanstalkDeployAction({id: "name-2021",
ebsApplicationName: "prod-name-app",
ebsEnvironmentName: "prod-name-env",
input: options.artifacts.toCodePipeline(this.input),
}));

return { runOrdersConsumed: 1 };
}
}
```

The call:
```
const applicationProdStage = new ApplicationStage(this, "Prod", {
env: {

account: "PRODACCOUNTNUMBER",
region: "ca-central-1"
},
stage: "prod"
})

const prodStage = pipeline.addStage(applicationProdStage);
prodStage.addPost(
new EBSDeployStep('DeployApp', commands.addOutputDirectory('.'))
)
```
The CDKToolkit bootstrap stack in the Prod account has in it resources (and the role exists):
`DeploymentActionRole | cdk-hnb659fds-deploy-role-PRODACCOUNTNUMBER-ca-central-1`

and in its parameters:
`TrustedAccounts DEVACCOUNTNUMBER`

### What did you expect to happen?

I was trying to deploy the application to EBS on a PROD account from a pipeline in my DEV account. The stack deploys correctly but the EBS deploy action fails.

### What actually happened?

`❌ cross-account-support-stack-PRODACCOUNTNUMBER (Something-support-PRODACCOUNTNUMBER) failed: Error: Could not assume role in target account using current credentials (which are for account DEVACCOUNTNUMBER) User: arn:aws:sts::DEVACCOUNTNUMBER:assumed-role/Something-PipelineUpdatePipelineSelfMutati-1DXBMLVQABN2P/AWSCodeBuild-7d55b435-2e66-4da4-b150-48179c6ca744 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::PRODACCOUNTNUMBER:role/cdk-hnb659fds-deploy-role-PRODACCOUNTNUMBER-ca-central-1 . Please make sure that this role exists in the account. If it doesn't exist, (re)-bootstrap the environment with the right '--trust', using the latest version of the CDK CLI.
`

### Environment

- **CDK CLI Version :** 1.121.0
- **Framework Version:** 1.121.0
- **Node.js Version:** 14.17.1
- **OS :** Windows
- **Language (Version):** 3.9.7

### Other

---

This is :bug: Bug Report

Contributor guide

Open the contributing guide

Research direction

Start with the custom ElasticBeanstalkDeployAction.bind implementation and EBSDeployStep.produceAction shown in the issue, then trace the cross-account-support-stack failure and the attempted AssumeRole from DEVACCOUNTNUMBER to PRODACCOUNTNUMBER. Done means a custom cross-account action can deploy to the production account without the support stack failing on the deployment-role assumption.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, typescript
Domain
cloud, devops, infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.