Various useful cloudformation templates.
Important note: I'm still working on minimizing the IAM permissions for some of the entities in the templates, so some of the policies included may be overly permissive.
Template for a CodePipeline that will automatically build a CodeCommit package using CodeBuild. You need to already have a CodeCommit package with a buildspec.yml file; this will take care of the rest.
Template for a CodePipeline that will automatically build a GitHub package using CodeBuild. You need to already have a GitHub package with a buildspec.yml file; this will take care of the rest.
Some manual work is required to enable the auth for this pipeline to talk to GitHub:
-Go to Settings/Developer settings/Personal access tokens in GitHub to create a new OAuth token.
-Click "Generate new token"
-In "Token description", put "AWS CodeBuild/CodePipeline" or something else descriptive.
-Under "Select scopes", select "repo" and "admin:repo_hook"
-Click "Generate Token"
-Copy the token. Keep it secret, keep it safe, and provide it as an unencrypted input to your CF stacks. (Yeah, I know that means read access to your CF stack inputs is equivalent to admin access to all your GitHub repos, but that's what seems to currently be required.)
-Finally, follow the instructions in step 5 of "Create a Build Project (Console)" in the CodeBuild docs to directly give AWS access to GitHub. (And yeah, I know this is just giving AWS the same permissions as those given by the aforementioned OAuth token, but it's what seems to currently be required.)
Template for a CodePipeline that will automatically deploy a Lambda function behind APIGateway. The inputs to the stack are the same as for codepipeline-github.cf.json. The package stevenorum/example-lambda-website is a simple website that the pipeline will successfully launch; you can use that as a basis to learn how to add more complex functionality.
In this template, at the end of the CloudFormationPolicy, there's a list of several :* permissions that are granted. Those should be the permissions necessary to create the CloudFormation stack, as well as any permissions that IAM roles in the stack itself need to inherit. Unfortunately, it will likely have to be somewhat broad, due to the difficult of specifying resource-specific permissions for resources that haven't yet been created.
WARNING: Most of the CF templates I write generate resources that are either below AWS's free-tier usage levels, or are very cheap (I had one beer with some friends last night and even before tip it cost more than my monthly AWS bill). CloudHSM is not a cheap service. Each HSM costs $1.45-$2.05 per hour, depending on the region, or between $1,000 and $1,500 per month. Make sure to only have them running while you're actively using them. Once you've activated a CloudHSM cluster, you can delete all the HSMs in the cluster and create replacements later and the keys, users, etc. that you initially created will still be there.
In addition, this template creates an EC2 instance so that you can communicate with the HSM. By default it uses an m4.large instance, which costs ~$0.10 per hour, or ~$70 per month. You can stop this instance when you aren't using it, and you can also substitute a smaller (and cheaper) instance type if you won't be running resource-intensive software.
This template uses CloudFormation custom resources to automatically set up an AWS CloudHSM cluster, even though that service isn't actually integrated with CloudFormation.
Hardware Security Modules are a good technology to be familiar with these days. It seems that every other day I get a LinkedIn message from a recruiter from a cryptocurrency startup that's looking for devs for HSM stuff. However, the bar to learning about HSMs can be pretty high. The off-the-shelf price of an HSM is in the thousands or tens of thousands of dollars. As mentioned before, CloudHSM isn't cheap compared with the rest of the stuff I post code for, but it's affordable to play around with if you're careful to not leave instances up and running long-term.
This template will create a CloudHSM cluster containing a single HSM. In more detail, it will create a VPC and subnets, it will create a cluster and HSM connected to that VPC, it will initialize the cluster for you, it will launch a client instance, and it will install and configure the client software on that instance. At that point, you just need to log onto the client instance and follow the steps listed in /home/ec2-user/README.txt to activate the cluster.
Because of the slightly brittle way this template handles the CloudHSM resources, manual cleanup may be required when deleting the stack. Although it should ideally work seamlessly through CF, I recommend deleting the HSM and cluster through the CloudHSM console instead of relying on CF to handle it. This is not just recommended but strictly required if you delete and recreate your HSM while the CF stack is up, as CF will be ignorant of the new HSM's ID.
Obligatory disclaimer: I work as a developer on AWS CloudHSM. Everything written here or included in the template is just my rambling thoughtstream/not a reflection of my employer's views/not based on private or internal information/etc.