terraform-provider-gitlabci: Register GitLab CI Runners

Easy runner registration via terraform

I’m a huge fan of terraform, so when I needed to build out cloud infrastructure for GitLab CI/CD it was the first thing I reached for. The native terraform-provider-gitlab was very useful, but left out one critical detail: it was not possible to register a runner.

Ouch. 💢

Docker container network interface ordering seems kinda random, yeah?

Lately I’ve found myself routinely attaching Docker-based containers to multiple networks. This has led to a couple… interesting surprises.

It doesn’t seem to be well documented (AFAIK), so here’s what I’ve learned. This isn’t a big serious how-to post, just something that irked me. 😄

Using a Metadata Proxy to Limit AWS/IAM Access with GitLab CI

The gitlab-runner agent is very flexible, with multiple executors to handle most situations. Similarly, AWS IAM allows one to use “instance profiles” with EC2 instances, obviating the need for static, long-lived credentials. In the situation where one is running gitlab-runner on an EC2 instance, this presents us with a couple interesting challenges – and opportunities.

KMS key context, IAM conditions, and s3

At $work, I’ve been using KMS to encrypt s3 bucket contents for some time now. It works rather well, but one thing that had been bugging me is that our IAM policies granted both read permissions on bucket objects and encrypt/decrypt on the relevant KMS key. That is, principals with the policies attached can use the key to encrypt/decrypt anything they otherwise have permission to access, not just objects in the bucket.

Conditional git Configuration

git has always(?) allowed for additional configuration files to be unconditionally included. However, sometimes on our systems we also have certain locations where we store multiple git projects, which may need different configuration from the global, but still common across that location.