Are cdk asset bucket names reserved in any way?

[pergardebrink]

All CDK asset S3 buckets follow the cdk-hnb659fds-assets-{ACCOUNTID}-{REGION} syntax for their names by default and is used implicit everywhere unless you provide a custom qualifier.

Is there something stopping anyone with malicious intent to "bulk create" buckets with "my" account ids/regions and effectively blocking me from a smooth CDK experience?

Or is CDK toolset based on the assumption that everyone is playing along nicely, and if not, you would be forced to specify a custom qualifier to bootstrap/deploy with?

[peterwoodworth]

Is there something stopping anyone with malicious intent to "bulk create" buckets with "my" account ids/regions and effectively blocking me from a smooth CDK experience?

I've thought about this before too. There's nothing stopping anyone from creating buckets with these names. However, someone would only be able to do 100 of these per account without getting a limit increase request, which is a tiny number when there are 100 billion possible account IDs. I think if someone were to be malicious, they would be targeting someone whose account ID they have identified for this to have any realistic chance of impacting anyone.

And yes, you would have to specify a custom qualifier if this were to happen to you. That's not an awful workaround to have to do even if it's not ideal, so I seriously doubt anyone would do this if they were trying to actually accomplish anything with the malicious activity.

[mateuszboryn]

Limit of 100 buckets doesn't prevent an attacker that knows account ID upfront to block somebody's deployment. If there's a fresh account and attacker learns its ID somehow, he may target that account ID only to prevent smooth CDK deployments.

Also, requirement for this bucket to exist (cdk-hnb659fds-assets-{ACCOUNTID}-{REGION}) isn't mentioned anywhere in
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3_assets-readme.html
nor in
https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_s3_deployment-readme.html

Could somebody please update that docs to ensure assets bucket are explicitly listed in prerequisites?

[mateuszboryn]

well, it is worse than that: an attacker would set up his own S3 bucket, give the victim write permissions and provide malicious content there. Malicious content can be provided upfront, or by connect that bucket to S3 Notifications that will overwrite files uploaded by victim.

So IMO it is a vulnerability.

[pergardebrink]

But the bootstrap would fail though, so this would require an incomplete bootstrap that someone would need to override manually in order to exploit this?

However, @peterwoodworth, all of this got me to think about a solution to the default scenario (which would be the problem discussed here).
What about a new bootstrap variant with a "default" SSM parameter (/cdk-bootstrap/default-qualifier or similar), containing the qualifier to use as the value for the CLI to lookup first if no qualifier is specified? That way you could bootstrap your account with a "default" and all subsequent CLI calls would use this qualifier without having to specify it hardcoded on the command line.

It would also be backwards compatible for everyone with the old default qualifier, unless you are running another "default qualifier" which would require a compatible CLI.