cli: Clarify active CDK role in verbose log output

[pzrq]

Describe the feature

Clarify which CDK IAM role(s) are active at a point in time.

Use Case

Given an error console log such as:

MyApiV2Stack | 17/49 | 9:46:59 am | CREATE_FAILED | AWS::Lambda::Function | ApiHandler (ApiHandler90E75D16) Resource handler returned message: "Your access has been denied by S3, please make sure your request credentials have permission to GetObject for cdk-...-assets-...-ap-southeast-2/...zip. S3 Error Code: AccessDenied. S3 Error Message: Access Denied (Service: Lambda, Status Code: 403, Request ID: ...)" (RequestToken: ..., HandlerErrorCode: AccessDenied)

Now spend a few days of wondering what was going on? Is it a problem with S3? Permissions (IAM)? Er let's say yes, so then who or what needs to be given IAM access? Is it my IAM Identity Center role? A custom role someone else needed? My CDK? Oh the CDK has roles (plural!), that's news to me, hope it's not that. One of the roles above it? So the closest in the cdk deploy -v output was a complete dead end:

[09:46:04] Assuming role 'arn:aws:iam::...:role/cdk-...-lookup-role-...-ap-southeast-2'.
MyApiV2Stack: deploying... [1/1]

The ones further up weren't particularly helpful:

[09:46:02] Assuming role 'arn:aws:iam::...:role/cdk-...-deploy-role-...-ap-southeast-2'.
...
[09:46:03] Assuming role 'arn:aws:iam::...:role/cdk-...-file-publishing-role-...-ap-southeast-2'.

---

It turned out by magic there was a completely missing piece of the puzzle we needed to fix this, that the CDK presumably has - which cdk role was used.

In fact in that verbose output I saw no suggestion it was a permissions (IAM) problem with the ...cdk-...-cfn-exec-role...) at all.

Around this point, what needed to be done became straightforward, attach an IAM policy, a bit like this one, to the AWS CloudFormation execution role (...cdk-...-cfn-exec-role...) which needed to be allowed access to S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "CDKBucketActions",
            "Effect": "Allow",
            "Action": [
                "s3:Get*",
                "s3:List*"
            ],
            "Resource": "arn:aws:s3:::cdk-*-assets-*"
        }
    ]
}

Proposed Solution

A way that might save those few days of debugging for others in future, could be to add more role logs, perhaps something like:

a) Perhaps just before the MyApiV2Stack: deploying... [1/1], add (or something similar like using already assumed role, hopefully one gets the idea):

[09:46:04] Assuming role 'arn:aws:iam::...:role/cdk-...-cfn-exec-role-...-ap-southeast-2'.

b) Make it clearer when roles are out of scope and so should no longer be used (perhaps a finally block of a try...finally statement), with logs like:

[09:46:04] Un-assuming role 'arn:aws:iam::...:role/cdk-...-cfn-exec-role-...-ap-southeast-2'.

Hope that's helpful and possible.

Other Information

Presumably adding new logs is easier than modifying existing logs (not sure if for error logs that's enough to be breaking, aside at AMZN scale suggests to me it'd be yes).

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

CDK version used

2.90.0

Environment details (OS name and version, etc.)

Ubuntu 22.04.3 LTS (jammy)

[peterwoodworth]

Thanks for the feedback - I'm not against adding logs in the verbose output, but I'm not sure that a log here for the CloudFormation execution role would be the best solution here. You're never the one to assume the execution role, which is why you don't see a log like that. The execution role is passed to CloudFormation to assume when performing the deployment.

Setting up the necessary resources and permissions (i.e. bootstrapping) is necessary to start using CDK v2, so I think it's important to have at least a surface level understanding of the bootstrapping resources before starting to actually use CDK. This is where the bootstrapping page in our devguide comes in - is to fill that knowledge gap. I'm not saying that we cannot have logs in the verbose output for the execution role, but is there any way we can better encourage understanding the bootstrap process? Or making our bootstrapping documentation better, if it wasn't clear about this to begin with?

[pzrq]

@peterwoodworth Thanks, if that documentation is assumed knowledge, perhaps it could be at the top of the verbose output? That stated, the problem did not occur during bootstrapping, but deployment.

[peterwoodworth]

That stated, the problem did not occur during bootstrapping, but deployment.

Right, it occurred because your execution role lacked the proper permissions, correct?