Hi,
I have used the new pipeline constructs recently and added a custom stage with a ShellScriptAction and custom sam cli commands such as sam package and sam publish. The issue I have encountered is that it is not easy to add custom PolicyStatement to the role, that is associated with the stage. Given the nature of a ShellScriptAction to be generic step in a pipeline running bash commands, it would be great to pass a specific IAM PolicyStatement to a corresponding action role.
I have found a way to do that, but this is not an easy task, this is how it resolved now:
const publishStageNode = this.node?.tryFindChild('Pipeline')?.node.tryFindChild('Pipeline')?.node.tryFindChild('publishStageNode')
publishStageNode?.node.tryFindChild('publishAction')?.node.children?.forEach(item => {
if (item instanceof PipelineProject) {
item.addToRolePolicy(allowCreateLayerSererlessRepoPolicy);
item.addToRolePolicy(allowUploadToS3Policy);
}
})
As you can see this is not an easy way to fetch the stage and the PipelineProject construct that is nested within the tree. Furthermore, I have to loop through the children, because in some cases there is a Role and a PipelineProject construct.
it would be great to add a policy statement directly to an action i.e.:
const policyStatement = new iam.PolicyStatement({...});
const action = new ShellScriptAction({
actionName: 'mySpecialShellScriptAction',
commands: [_some_bash_commands_here_]
});
action.addToRolePolicy(policyStatement);
Pinging @webdog as per request.
-
This is a :rocket: Feature Request
@am29d I have a question, is it possible to use the project property (like below) to add the desired policy statement? Or does this project not refer to the right stage / is this not doable because of the order in which objects are created/binded together, or something else?
myAction.project.addToRolePolicy(myPolicyStatement);
Even if this was a solution though, I could still see the value in adding an extra method for adding the role since it makes the mental model a bit simpler. (I'm also a bit new to CodePipelines so forgive me if I'm misunderstanding the issue 馃槄)
Hi @Chriscbr, you are absolutely correct! The project object can be accessed via the action, but I would have never found it. As you said, from the mental model I would expect to use the method from the action. Important catch, make sure to add the action to the project first, and then add the policy, otherwise you will end up with an error that the stage does not have any actions:
const buildStage = pipeline.addStage('BuildStage');
const shellScriptAction = new ShellScriptAction({
actionName: "shellScriptAction",
commands: [
"echo foo"
],
additionalArtifacts: [sourceArtifact],
runOrder: buildStage.nextSequentialRunOrder()
});
buildStage.addActions(shellScriptAction);
shellScriptAction.project.addToRolePolicy(new PolicyStatement({
effect: Effect.ALLOW,
actions: [
"s3:PutObject"
],
resources: ["*"]
}));
I have also tested it with multiple actions and PolicyStatements, the least privilege principle is working as expected and each step has its own permissions, because they are in a separate CodeBuild project. Maybe it is worth to update the docs to show how custom permissions can be added to the custom stage?
Thanks a lot for the hint, @Chriscbr !
@am29d @Chriscbr do you know how to do this for cross-account deployments?
I have a build account where the pipeline runs and deploys the stack to a staging account. I want to assume a role in the staging account to execute the acceptance tests on but I'm not sure how to do this with CDK pipelines.
@am29d @Chriscbr do you know how to do this for cross-account deployments?
I have a build account where the pipeline runs and deploys the stack to a staging account. I want to assume a role in the staging account to execute the acceptance tests on but I'm not sure how to do this with CDK pipelines.
Did you find that out in the meantime? I'm having the same issue
@michaelfecher no circled back to it a couple of times when I've had a spare 15 mins but haven't cracked it yet.
Got it working by creating a role in the testing account and assuming it in my tests from the build account.


@michaelfecher I have just stumbled upon this nice workshop that guides you through a cross account deployment with CDK, take a look: https://github.com/aws-samples/aws-cross-account-cicd-pipeline