[aws-codepipeline-actions] support cross account/region ecs deployment

[stocks29]

Add account/region params and setup permissions so an EcsDeployAction in a pipeline in Account A can deploy to a different region in Account B.

Use Case

To keep pipeline accounts separate from environment accounts and to support multi-region deployments.

Proposed Solution

I don't have an elegant proposed solution but I was able to achieve a workaround described below.

Other

I was able to cobble together a workaround by:

1. copy EcsDeployAction to a new module (I called it EcsMultiAccountDeploy in examples below), adding in props for account and region which are passed to super and removing the role code.
2. granting the deploy role from the cdk boostrap process the ability to deploy to ecs in each environment account via a cdk stack.
3. passing the deploy role from the cdk bootstrap to the new deploy action described in step 1.

There may be a better approach but this worked for me. The reason for using the deploy role from cdk bootstrap is because it already has access to the build artifacts. Maybe there could be a way to augment the permissions of these roles during bootstrapping.

Below are the snippets of my workaround.

Important pieces from EcsMultiAccountDeploy

export interface EcsMultiAccountDeployActionProps extends EcsDeployActionProps {
  account: string | undefined;
  region: string | undefined;
}

  ...

  constructor(props: EcsMultiAccountDeployActionProps) {
    super({
      ...props,
      category: codepipeline.ActionCategory.DEPLOY,
      provider: 'ECS',
      artifactBounds: deployArtifactBounds(),
      inputs: [determineInputArtifact(props)],
      resource: props.service,
    });

    this.props = props;
  }

In the build stack which contains the pipeline:

// this is the deploy role created by the cdk bootstrap process
const deployRole = iam.Role.fromRoleArn(this, `${stageName}EcsDeployRole`, deployRoleArn);

const action = new EcsMultiAccountDeployAction({
  actionName: `${stageName}EcsDeploy`,
  service: ecsService,
  input: appArtifact,
  runOrder: stage.nextSequentialRunOrder(),
  account: env.account,
  region: env.region,
  role: deployRole,
});

stage.addActions(action);

In the application stack:

  updateDeployRole(props: UpdateDeployRoleProps) {
    const { deployRoleArn } = props;

    // this is the deploy role created by the cdk bootstrap process
    const role = iam.Role.fromRoleArn(this, 'BootstrapDeployRole', deployRoleArn);

    // the below is necessary for the ecs depoly
    role.addToPrincipalPolicy(new iam.PolicyStatement({
      actions: [
        'ecs:DescribeServices',
        'ecs:DescribeTaskDefinition',
        'ecs:DescribeTasks',
        'ecs:ListTasks',
        'ecs:RegisterTaskDefinition',
        'ecs:UpdateService',
      ],
      resources: ['*'],
    }));

    role.addToPrincipalPolicy(new iam.PolicyStatement({
      actions: ['iam:PassRole'],
      resources: ['*'],
      conditions: {
        StringEqualsIfExists: {
          'iam:PassedToService': [
            'ec2.amazonaws.com',
            'ecs-tasks.amazonaws.com',
          ],
        },
      },
    }));
  }

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

---

This is a 🚀 Feature Request

[skinny85]

Hey @stocks29 ,

thanks for opening the issue. Do you mind showing the code that creates props.service in your code?

Thanks,
Adam

[stocks29]

For sure. See below. It relies on naming conventions for the cluster and service names since, aside from security groups and the vpcId, passing service/cluster information back to the pipeline stack resulted in cross-stack errors. I was actually surprised that the same didn't happen for security groups and the vpcId.

    // This role is generated by the cdk bootstrap process. It's generally used for deploying cloudformation to env account/regions
    // but since it already has access to the artifact bucket/key and it's in account b, we'll use it for ecs deploys as well
    // the service stack will handle adding ecs permissions to this role.
    const deployRoleArn = `arn:aws:iam::${env.account}:role/cdk-hnb659fds-deploy-role-${env.account}-${env.region}`;

    const serviceStage = new ServiceStage(this, stageName, {
      env,
      ecrRepoArn: ecrRepo.repositoryArn,
      ecrRepoName: ecrRepo.repositoryName,
      clusterName,
      serviceName,
      containerName: imageName,
      deployRoleArn,
      hostname,
    });

    const stage = pipeline.addApplicationStage(serviceStage);
    const securityGroups = serviceStage.securityGroupIds.value.split(',')
      .map((id: string, index: number) => ec2.SecurityGroup.fromSecurityGroupId(self, `${stageName}SG${index}`, id));

    const vpc = ec2.Vpc.fromVpcAttributes(this, `${stageName}Vpc`, {
      vpcId: serviceStage.vpcId.value,
      availabilityZones: serviceStage.availZones.value.split(',')
    });

    const cluster = ecs.Cluster.fromClusterAttributes(this, `${stageName}Cluster`, { clusterName, vpc, securityGroups });

    const ecsService = ecs.FargateService.fromFargateServiceAttributes(this, `${stageName}EcsService`, { cluster, serviceName }); 

    const deployRole = iam.Role.fromRoleArn(this, `${stageName}EcsDeployRole`, deployRoleArn);

    const action = new EcsMultiAccountDeployAction({
      actionName: `${stageName}EcsDeploy`,
      service: ecsService,
      input: appArtifact,
      runOrder: stage.nextSequentialRunOrder(),
      account: env.account,
      region: env.region,
      role: deployRole,
    });

[skinny85]

Ok. So the issue here is that you're importing your service into the same Stack the CodePipeline is in, with a name. And because of that, the CDK has no way of knowing that service is defined in a different account/region.

Now, there are 2 options:

1. Import the service into a Stack that belongs to the same account & region the actual service is in. In that case, you don't need the EcsMultiAccountDeployAction. The CodePipeline construct will figure out itself that the Service is from a different account/region, and will do the correct setup for you.
2. Import the service by ARN instead of by name. Since the ARN contains the account and region, that should be enough for CDK to figure out it needs to do the same setup as in point 1.

However, the problem is that option .2 does not currently work in the CDK, because the account and region of the imported Service is not filled out correctly. This needs to be corrected here. For this reason, I'm keeping this issue open as a feature request (if you'd like to contribute this functionality to the CDK @stocks29 , that would be awesome - take a look at how Bucket handles that for some inspiration). Here's our Contributing guide: https://github.com/aws/aws-cdk/blob/master/CONTRIBUTING.md ).

[ryanpagel]

@skinny85 How would I get the above to work if I don't have a reference to the cross account service in the stack I am deploying?

[skinny85]

@ryanpagel import it using a from*() method into a Stack that belongs to the same account/region the service is in.

[robert-lilleker]

Hi, multi regional ecs deployments would be very useful to us. Has there been any progress on this?

[robert-lilleker]

I've created a pr for the issue #15944

[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.