Description
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)