Are you "The One"
AWS Certified Global Community Challenge
In June I was asked to participate in creating a challenge as part of a series of challenges for the AWS Certified Global Community.
The idea of the challenges was to provide example of code that had been broken by hackers with the goal of remediating the issues to return the system back to a fully functioning state.
By completing the challenges, individuals not only gained points for the community leaderboard, but also were able to learn new skills and real like usage of code.
The Idea
To try and emulate real world usage, I based my challenge on a file processing solution.
The basic idea was that a file uploaded into a bucket would be tagged and moved to a new bucket. The principle was to show how file management with an AWS Lambda could be implemented using S3 triggers. The final piece, an SNS notification was then used to send an email confirming the file had been moved.
Although I added some items, such as a random value from Secrets Manager, the principle was to show a serverless, event driven, file management solution. With the goal of allowing people to see how they could extend it.
The overall architecture was provided so that participants could understand how the system had been built.
The Challenge
So I didn't want to be overly complicated but I did want it to trip people up on what I would say are basic CloudFormation/AWS gotchas.
So what errors did I add to my code and why?
Allow Uppercase in random string. (ExcludeUppercase: false)
This means that the bucket creation could fail with an error on the bucking naming not complying with resource constraints.
While a simple error it is an interesting error as will be transient. This means that it might only fail once every few deployments and updates will not fail once bucket is created.
Remove dependency on resource. (DependsOn: S3Permissions)
This is a slightly tricky one as although the resource is called "S3Permissions" and the dependency is applied to the S3 Bucket creation it is not the S3 permissions for the bucket that are dependent, but the permissions for the lambda role to access the bucket. As such the template will try and create a bucket and apply Lambda notification before the Lambda is created with the correct permissions. This means that Bucket creation fails as target does not have permissions to objects.
Remove access to objects in bucket. ( arn vs arn/*)
This is a common mistake when granting permissions to S3.
Just supplying the S3 arn (in this case the variable) only grants access to the bucket and not objects within the bucket. To grant access to objects the prefix and key needs to be specified. If granting access to all objects /* at the end of the arn will suffice, but more granular access could be granted to specific prefixes.
As always, all code is on my GitHub account, so if you want to take a look at the two version of code please feel free.
Take a look under on the AWS-Certified repo under the community-challenge-22 folder.
myawsrocks
