Some time ago, I was working on an AWS resource inventory and realized I needed a clean, structured way to present it in Confluence - especially since not everyone on the team had direct access to the AWS console. Manually updating pages was time-consuming and error-prone, so I built a tool to automate that process.
The aws-csv-to-confluence transforms CSV files exported from the AWS Tag Editor into structured Confluence pages, with one page per service (like EC2, S3, Lambda, etc.). It’s simple, small, and saved me a ton of time. Maybe it’ll be useful for someone else too.

In this post, I’ll share a specific situation I had some time ago and how I went about solving it. It’s a rather niche case, but it may be of interest to those who deal with similar challenges and:

• use GitLab
• use Container-Scanning.gitlab-ci.yml GitLab template
• want to manage vulnerability-allowlist.yml from a single location
• …or simply curious what it’s all about

Imagine you have a directory - maybe for migrations, test cases, or some other specific type of files - and you want to ensure every file inside follows a consistent naming pattern with a prefix like migration_ or testcase_. I recently ran into this exact need. Since our team use a pre-commit in our daily workflows, I decided to create a small hook to enforce this rule automatically. It’s lightweight, does one job well, and I’ve made it public in case it’s useful to others too. In this post, I’ll walk you through what the tool does, how it works, and how to get started using it.

One day, I had to integrate a third-party metrics exporter into our monitoring stack (a pretty standard setup with Prometheus, Alertmanager, and Grafana). The exporter exposed a metrics endpoint that, when opened in a browser, simply displayed a list of metrics. However, when I added it to the Prometheus config as a new target, Prometheus broke with the

err: received unsupported Content-Type "application/json"

In this post, I’ll explain why that happened and how I fixed it. Hopefully, this will be useful to someone out there.

Starting with Terraform v1.11, we now have a cleaner and more secure way to handle sensitive values - write-only arguments. This post walks through a simple example of using that feature with Google Cloud Secret Manager.

Some time ago, I got a task from our security team: ensure that pods running in our EKS cluster couldn’t access the instance metadata endpoint. This was part of a broader effort to tighten security and prevent potential credential exposure. In this post, I’ll walk you through how I did this with a combination of two Kubernetes egress NetworkPolicies.

Hi everyone! If you, like me, work a lot with Terraform (and Infrastructure as Code in general) and GCP, you’ll probably find this collection of publicly available modules quite useful. I’m proud to say that I’ve contributed to many of them. In this post, you’ll find a collection of links to the modules developed at the University of Cambridge along with a brief description for each module.