Linting is an one of those things that can be weirdly controversial. I say weirdly as I cannot quite understand the objections to it – it’s not like we’re all perfect typists, after all. Generally the objections range from “My editor does it for me” to “I forget to run them before pushing!” to my favorite, “They always fail in CI!”
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. 💢
Lately I’ve found myself routinely attaching Docker-based containers to multiple networks. This has led to a couple… interesting surprises.
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.
GitLab makes a great deal of information available through Prometheus metrics. But not everything.
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. It didn’t appear that there was a
reasonable way to tighten this until I ran across references to the IAM
kms:EncryptionContext: condition.
