Mar 14, 2021


I spent most of this week migrating code into a new microservice, and refactoring code in the Transition Checker. I think I’ve added more code than I’ve deleted (alas), but most of the complexity is in the new microservice now, and more parts of GOV.UK will be able to implement account-based functionality. Or “personalisation”, as the buzzword is.

I did a lot of the coding this week which, while enjoyable, is also not very good delegation or future-proofing. If I have the best knowledge of everything (because I implemented all of the core, and others only reviewed it or implemented smaller pieces), then the team’s bus factor is dangerously low. Also it’s less fun for everyone else to spend all their time reviewing code and not writing any.

So I’ll try to hold off a bit next week and do more reviewing and helping, than direct implementation.


This week I read:

Concourse and Secrets Management

I set up secrets management for my Concourse instance, which turned out to be incredibly easy, and not really worth putting off for over a year, as I had done.

I decided to use the AWS SSM credential manager, which only required me to set up a new AWS IAM user and give it a small set of permissions. I did consider the Vault credential manager, but when the Vault server starts up it requires a human operator to enter the master decryption key. That’s not so great for me, as I have automatic updates and reboots enabled on the server which would run it. It can store the master key in AWS Secrets Manager, but I thought that if I’m going to have to use AWS anyway I may as well skip Vault entirely.

I hit a weird problem with the Concourse IAM policy. Normally, you can omit the AWS region and account ID when specifying which resources it applies to, but that didn’t work. I just got a permission denied error when I tried to get or put any secrets. So I ended up specifying them in the policy:

    resources = [
      # "arn:aws:ssm:::parameter/..." doesn't seem to work in this
      # policy, but specifying the account ID explicitly does.

But it’s all working now. Maybe AWS SSM Parameter Store policies are just picky.

And I’ve been able to migrate away from interpolating YAML variables into using proper secrets, which means I got to delete a text file full of credentials. It also allows me to define my Concourse pipelines in the repos which they refer to (rather than having one repo with the pipeline templates + a script to interpolate the variables).

This, along with setting up a new IAM user and policy, has triggered some thinking about how I manage my cloud stuff (it’s all more complex than it needs to be), so I think I’ll do some wider refactoring in the near future too.