(aws-cdk/pipelines): allow use of custom role for CodePipeline

[ekeyser]

What is the problem?

When creating pipelines.CodePipeline with a synth pipelines.CodeBuild and even passing in role=role.without_policy_updates() parameter to the CodeBuildStep, the resulting Cfn template is generated with a PipelineRoleDefaultPolicy that exceeds the allowable size. According to other issues and to the docs regarding opting out of policy updates the policy is still being updated.

Reproduction Steps

install_commands = ['npm install -g aws-cdk', 'pip install -r requirements.txt', 'cdk synth']
        role = iam.Role(
            self,
            "Role",
            assumed_by=iam.CompositePrincipal(
                iam.ServicePrincipal("codepipeline.amazonaws.com"),
                iam.ServicePrincipal("codebuild.amazonaws.com"),
            ),
            description="My Custom Role"
        )

        policy_statement = iam.PolicyStatement(
            actions=[
                "s3:GetObject*",
                "s3:GetBucket*",
                "s3:List*",
                "s3:DeleteObject*",
                "s3:PutObject",
                "s3:Abort*",
            ],
            effect=iam.Effect.ALLOW,
            resources=[
                "*"
            ],
        )

        role.add_to_policy(
            policy_statement,
        )

        synth = pipelines.CodeBuildStep(
            "Synth",
            role=role.without_policy_updates(),
            commands=install_commands,
            input=pipelines.CodePipelineSource.connection(
                "blah/blahblah",
                "master",
                connection_arn=connection_arn,
            ),
        )

        pipeline = pipelines.CodePipeline(
            self,
            "Pipeline",
            synth=synth,
        )

What did you expect to happen?

the passed in role should not be updated

What actually happened?

policy for passed in role is updated to include individual assets for resources. It's also possible that the roles between the CodeBuildStep and the pipelines.CodePipeline are completely separate in which case I would expect that the pipelines.CodePipelines to allow for a role parameter but this does not appear to be the case.

CDK CLI Version

1.137.0

Framework Version

No response

Node.js Version

v14.18.1

OS

Linux/Ubuntu 20.04

Language

Python

Language Version

3.8.10

Other information

No response

[ekeyser]

I can't tell if there is any traction on this issue. Just to be clear - I can create the policy and role myself if I need to but it doesn't appear that the role that I'm applying is being used and what seems to be broken or not implemented is the method to not use the role without_policy_updates.

[saltman424]

This is the PR for this issue: #18293

[peterwoodworth]

I'm not finding that this role is being mutated at all. The role and policy being created are being created because the pipelines.CodePipeline construct creates a codepipeline.Pipeline without passing a role to the codepipeline.Pipeline. This causes the codepipeline.Pipeline to create a role and policy to use.

Where you're passing the role here, it's ending up being used as the CodeBuild::Project service role, and isn't being modified.

We offer the option to pass in your own codepipeline.Pipeline to the pipelines.CodePipeline so that the CDK won't generate a new codepipeline.Pipeline with its own defaults. I don't think it's out of the question to allow users to pass in a role to pipelines.CodePipeline to then pass on to the generated codepipeline.Pipeline - will convert this to a feature request

[ekeyser]

I think I follow. I'll admit I'm a little rusty on the details of what's going on and it's been a while since I opened this. From what you're saying I take it that there are two roles involved: one for creating the pipeline and one for execution of the pipeline. Is that correct? And it's the execution role that is exceeding the 10K policy size limit not the role that is a property of the pipelines.CodePipeline?

When you say that you can pass in your own codepipeline.Pipeline you mean an existing fully formed codepipeline.Pipeline, correct? If so, what would be the point of using codepipelines at that point? Am I missing something? I suppose I could pass in our existing codepipeline.Pipeline using the static method fromPipelineArn which was created from pipelines.CdkPipeline but I think at that point I'm creating a potential mess of a situation not to mention I'm not sure that's entirely possibly without impacting our existing production infrastructure.

One last bit, which is this stemmed from attempting to workaround a policy size exception. I understand that inline policies, even if there are multiple per role, are all coalesced into a single inline policy and that combined policy size is limited to 10K. My question is why is there a hard requirement for relying on inline policies? Wouldn't it be possible to create custom/customer managed policies and even multiples of these policies to then assign to whatever role is using them? That should at least allow up to 60K (120K if limit of policies / role is bumped up to 20) worth of policy size minus some policy crease loss. Again, maybe I'm missing something, in fact I'm sure I am.

[peterwoodworth]

The role you're passing into codebuildstep is the ServiceRole which enables CodeBuild to interact with AWS services. This is just limited to CodeBuild.

The other role is the role the pipeline itself uses to either perform actions that don't have a role specified for that action, or will assume the role specified for the action

Yes, I do mean a fully existing codepipeline.Pipeline. Under the hood, the CodePipeline construct will create one itself. This could be used to migrate an existing codepipeline.Pipeline to be used with our modern api, or it could be used if you wish to create a codepipeline.Pipeline construct with passing in different props than our modern API would otherwise allow. Here's an example:

    const pipeline = new Pipeline(this, 'Pipeline', {
      crossAccountKeys: false,
      restartExecutionOnUpdate: true,
      role: new Role(this, "pipeline", {
        roleName: "pipeline",
        assumedBy: new ServicePrincipal("codepipeline.amazonaws.com")
      }).withoutPolicyUpdates()
    });
    const cdkpipeline = new CodePipeline(this, 'CodePipeline', {
      codePipeline: pipeline,

This will create a CodePipeline with a role that will not be mutated, with no additional policies. All else should be identical I believe. You will then be able to use the CodePipeline construct as normal.

For reference, here's where we generate the underlying pipeline

aws-cdk/packages/@aws-cdk/pipelines/lib/codepipeline/codepipeline.ts

Lines 351 to 369 in 83f1668

	if (this.props.codePipeline) {
	if (this.props.pipelineName) {
	throw new Error('Cannot set \'pipelineName\' if an existing CodePipeline is given using \'codePipeline\'');
	}
	if (this.props.crossAccountKeys !== undefined) {
	throw new Error('Cannot set \'crossAccountKeys\' if an existing CodePipeline is given using \'codePipeline\'');
	}
	this._pipeline = this.props.codePipeline;
	} else {
	this._pipeline = new cp.Pipeline(this, 'Pipeline', {
	pipelineName: this.props.pipelineName,
	crossAccountKeys: this.props.crossAccountKeys ?? false,
	reuseCrossRegionSupportStacks: this.props.reuseCrossRegionSupportStacks,
	// This is necessary to make self-mutation work (deployments are guaranteed
	// to happen only after the builds of the latest pipeline definition).
	restartExecutionOnUpdate: true,
	});
	}

Of course, it would be easier if you could just directly pass in this role to CodePipeline.

As for the policy question - I'm not sure personally 😅 I've seen this discussed a while ago on why we don't do managed policies for this problem, but I don't remember the details.

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