Use investigations tagged encrypted AMI for pfi and pfi-worker

[philmcmahon]

What does this change?

This is a very basic step towards completing the ambitions of @mbarton in https://github.com/guardian/investigations-platform/pull/343

At the moment the amigo image copier is generating 3 encrypted AMIs for every bake used in our account - one for each of the pfi-playground/pfi-giant/investigations stacks, each using a different KMS key. These AMIs allow us to have all data on the disk of our instances encrypted at rest - plug for an excellent blog post about that here https://theguardian.engineering/blog/info-2018-mar-12-why-the-guardian-is-using-encrypted-ec2-root-volumes-on-aws.html

I'm not convinced as to the security benefits of using different keys for CODE/PROD, and this setup is becoming harder to maintain as it's no longer supported by the image copier. With that in mind, this PR sets both giant stacks to use the 'investigations' AMI for the pfi and pfi-worker instances.

It would be good to do the same for elasticsearch and neo4j. Neo4j will be the hardest as we use EBS snapshots to handle isntance rotation, elastic should be ok but I want to see if this causes any problems first before messing with databases.

It's worth noting that the stack-specific KMS keys are used for mounting extra volumes as well as encrypting data in s3, so this PR is just a small step towards the ambitions set out in Michael's pr above, but it does get us out of a bind with the image copier problems.

Are you wondering why there's only a diff for pfi-playground here? Let me introduce you to our build script - something which might be possible to simplify once we complete this migration

Depends on https://github.com/guardian/investigations-platform/pull/608

How to test

I've tested this on playground and verified that the instances apps still started - which they wouldn't if the root volume was encrypted with a kms key they didn't have access to

[twrichards]

nice!