A few years ago CloudFormation was a large part of my day. While Terraform slowly began to creep into my stacks, with its daring support for other providers, one of the features I always missed was an equivalent to CloudFormations AWS specific parameter types. These provided a great way to ensure you were using the type of value you thought you were, enforcing that something was actually a subnet ID for example, and now with Terraform 0. Read on →

One of the things I find myself occasionally missing from terraform are the native AWS specific parameter types you can use in CloudFormation. These are refinements to the usual template parameters that further limit the valid input, help describe what the value should actually be, and in some cases verify that the resource passed in actually exists. In CloudFormation you’d often start with a basic string parameter like this in your templates: Read on →

Once you have enough people each working in multiple accounts it becomes a waiting game until you’ll eventually get the dreaded “Your AWS account 666 is compromised.” email. As someone who’s been using AWS since S3 arrived this is the first time I’ve encountered this so I thought I’d write up some notes about what actually happens. First comes the easy, but not recommended, part of the whole experience; push some credentials to GitHub. Read on →

When it comes to Amazon Web Services support Terraform has coverage that’s second to none. It includes most of Amazons current services, rapidly adds newly released ones, and even helps granularise existing resources by adding terraform specific extensions for things like individual rules with aws_security_group_rule. This awesome coverage makes it even more jarring when you encounter one of the rare edge cases, such as VPC default security groups. It’s worth taking a step back and thinking about how Terraform normally works. Read on →

Terraform code reuse leads to modules. Modules lead to variables and outputs. Variables and outputs lead to massive amount of boilerplate documentation. terraform-docs lets you shortcut some of these steps and jump straight to consistent, easy to use, automatically generated documentation instead. Terraform-docs, a self-contained binary implemented in Go, and released by Segment, provides an efficient way to add documentation to your terraform code without requiring large changes to your workflow or massive amounts of additional boilerplate. Read on →

Like most people I have too many credentials in my life. Passwords, passphrases and key files seem to grow in number almost without bound. So, in an act of laziness, I decided to try and remove one of them. In this case it’s my AWS EC2 SSH key and instead reuse my GitHub public key when setting up my base AWS infrastructure. Once you start using EC2 on Amazon Web Services you’ll need to create, or supply an existing, SSH key pair to allow you to log in to the Linux hosts. Read on →

Have you ever noticed in the AWS console, when new instances are created, the “Tags” tab doesn’t have any content for the first few seconds? A second or two before values are added may not seem like much but it can lead to elusive provisioning issues, especially if you’re autoscaling and have easily blamed network dependencies in your user data scripts. A lot of people use Tag values in their user data scripts to help ‘inflate’ AMIs and defer some configuration, such as which config management classes to apply, to run time when the instance is started, rather than embedding them at build time when the AMI itself is created. Read on →

All the well managed AWS accounts I have access to include some form of security group control over which IP addresses can connect to them. I have a home broadband connection that provides a dynamic IP address. These two things do not play well together. Every now and again my commands will annoyingly fail with ‘access denied’. I’ll run a curl icanhazip.org, raise a new PR against the isolated bootstrap project that controls my access, get it reviewed and after running terraform, restore my access. Read on →

Inspired by a link in the always excellent Last Week in AWS I decided to investigate Scout2, a “Security auditing tool for AWS environments”. Scout2 is a command line program, written in Python, that runs against your AWS account, queries your configuration data and presents common issues and misconfigurations via a set of local HTML files. The dashboard itself is simple, but effective, and displays a nice overview of all the checks Scout2 ran. Read on →

Sometimes, when using an infrastructure as code tool like Terraform or CloudFormation, you only want to include a property on a resource under certain conditions, while always including the resource itself. In AWS CloudFormation there are a few CloudFormation Conditional Patterns that let you do this, but and this is the central point of this post, what’s the Terraform equivalent of using AWS::NoValue to remove a property? Here’s an example of doing this in CloudFormation. Read on →

One of my favourite forthcoming Terraform 0.8 features is the ability to restrict the versions of terraform a configuration file can be run by. Terraform is a rapidly moving project that constantly introduces new functionality and providers and unless you’re careful and read the change logs, and ensure everyone is running the same minor version (or you run terraform from a central point like Jenkins), you can easily find yourself getting large screens of errors from using a resource that’s in terraform master but not the version you’re running locally. Read on →

Over the last 3 years I’ve done a lot of CloudFormation work and while it’s an easy enough technology to get to grips with the mass of JSON can become a bit of a blur when you’re doing code reviews. It’s always nice to get a second pair of eyes, especially an unflagging, automated set, that has insight in to some of the easily overlooked security issues you can accidentally add to your templates. Read on →

I’ve been writing a few Terraform modules recently with the aim of sharing them among a few different teams and there are a couple of things missing that I think would make reusable modules much more powerful. The first and more generic issue is using the inability to use more complex data structures. After you’ve spent a while using Terraform with AWS resources you’ll develop the urge to just create a hash of tags and use it nearly everywhere. Read on →

While Terraform is remarkably good at its job there are going to be some occasions when you want to test what you wanted actually happened. In the unixdaemon_terraform_experiments repository I’m handling this with awspec and a little custom rspec directory modification. First we pull in the awspec gem. bundle install We also need to add the necessary scaffolding files: echo "gem 'awspec', '~> 0.37'" >> Gemfile mkdir spec echo "require 'awspec'" >> spec/spec_helper. Read on →

Introduction While it’s possible to experiment and learn parts of Terraform in isolation sometimes it’s handy to have a larger, more complete, environment to run your tests in. For me unixdaemon_terraform_experiments this is that repo. It will contain a number of different terraform based projects that can be consistently deployed together. You can see some of my thinking behind this in the Naive first steps with Terraform post. Terraform is a very powerful, but quite young, piece of software so I’m making this repo open to encourage sharing and invite feedback on better way to do things. Read on →

One of the principles of running large numbers of instances is that consistency is key. Config deviations cause oddities that’ll drain your time with investigations and nothing causes entropy on your hosts like an admin investigating an issue. In this post we’ll configure our instances to mark themselves as contaminated when someone logs in. We can then use other tooling to query, collate and probably reap, machines corrupted by the keystrokes of humans. Read on →

Naive First Steps with Terraform On one of the $WORK projects, we’ve recently had a chance to join seemingly the entire AWS using world and spend some time using Terraform to manage a few migration prototypes. I’ve had a few little plays with Terraform over the last few years but I’ve never tried to plan a large environment with it before and even though it’s -very- early days for me it’s been an interesting path of discovery. Read on →

Ever since I started using distributed version control systems one of my fears has been accidentally publishing security credentials that could be maliciously used against me. Add to this services like AWS where you can run up a large bill very quickly, and an employer that tries to open source everything possible, and eventually you know you’re going to slip up and expose something you shouldn’t. In the past I’ve cobbled together git commit hooks to provide a basic safety net but I’m looking for a more designed solution and pre-commit is heavily in the running. Read on →

As part of re-doing my home infrastructure I’m looking to add a remote location for my private git repos. My use case is a simple one, I need lots of low cost, tiny, private repos, each with a few dozen files at most. I don’t need a comprehensive set of collaboration features as I’m normally the only one working on them. My current practice is to keep my private repos on a local git server and anything open source goes to GitHub. Read on →

As possibly the last AWS using sysadmin in London who’s not invested in Terraform I’ve decided it’s time to take my quarterly look at the tool. This time around I decided to start with a basic IAM admin user and group. For my stripped down example I’m going to create a user and group, add the user to a group and set an explicit IAM group policy. As a novice terraform user I find the code easy to read, the online documentation was short but helpful and the getting started guide did indeed guide my starting. Read on →

After a previous comment about “templating CloudFormation JSON from a tool higher up in your stack” I had a couple of queries about how I’m doing this. In this post I’ll show a small example that explains the work flow. We’re going to create a small CloudFormation template, with a single Jinja2 embedded directive, and call it from an example playbook. This template creates an S3 bucket resource and dynamically sets the “DeletionPolicy” attribute based on a value in the playbook. Read on →

You can create some high value resources using CloudFormation that you’d like to ensure exist even after a stack has been removed. Imagine being the admin to accidently delete the wrong stack and having to watch as your RDS master, and all your prod data, slowly vanishes in to the void of AWS reclaimed volumes. Luckily AWS provides a way to reduce this risk, the DeletionPolicy Attribute. By specifying this on a resource you can ensure that if your stack is deleted then certain resources survive and function as usual. Read on →

While AWS CloudFormation is one of the best ways to ensure your AWS environments are reproducible it can also be a bit of an awkward beast to use. Here are a couple of simple time saving tips for refining your CFN template parameters. The first one is also the simplest, always define at the least a MinLength property on your parameters and ideally an AllowedValues or AllowedPattern. This ensures that your stack will fail early if no value is provided. Read on →

Back in November 2013 Amazon added a much requested feature to CloudFormation, the ability to conditionally include resources or their properties in to a stack. As an example I’m currently using this as a small cost saving measure to ensure only my production RDS instances have PIOPs applied to them while being able to build each environment from a single template. CloudFormation Conditionals live in their own section of a CloudFormation template. Read on →

We’re currently moving some of our early stage dev prototypes to a more automated environment and as part of this work I’m converting command line AWS resource creation to parameterised CloudFormation templates that we can use to either run multiple stacks side by side or recreate the entire stack from development to production. It’s been quite a frustrating afternoon due to some tool chain related yak shaving and some nuances in how CloudFormation works. Read on →

AWS CloudFormation gives developers and systems administrators an easy way to create and manage a collection of related AWS resources, provisioning and updating them in an orderly and predictable fashion. -- AWS CloudFormation Homepage I’ve gone from never having used Amazon CloudFormation to building multi- tier, cross region, many availability zone deployments in a couple of months and while digging through official documentation, support requests, blog posts and sample templates I’ve put together what I’ve come to view as the ‘Four Stages of CloudFormation’. Read on →

While most of us spend our December hunting for those last minute gifts, treats and surprise presents, a small number of techies manage to find the time to write a themed set of articles on certain technical topics that are combined in to an advent calendar. While I’m a little ashamed to say I’ve not yet read the 2012 SysAdvent posts I did have a chance to look at the inaugural, and quite excellent Amazon Webservice Advent 2012 Read on →