I saw this post on my feed, and it caught my eye because I self-host a Mattermost instance. The fact that it has possible critical security issues is a concern for me. So I checked the github issue with the details.

Of course, it’s fully LLM generated, but that’s to be expected at this point. So I opened the first issue described there, a CRITICAL VULNERABILITY no less. It’s the possibility for XSS in email templates. Ok, sure, let’s dig deeper. This post will have a technical part, where I dig into the code; and a more sociological part, where I dig into other things.

In part 1 we could see the foundation of this project taking shape - we had a zero-framework HTTP server, with structured logging. Solid foundations are very important, but now it’s time to have a go (pun intended) at the fundamental part of this project: we want to automatically provision secure, isolated namespaces with proper RBAC. This is the “paved road” I wanted to build, and these are the first steps to getting there!

The Problem

While talking with a friend that works in IT, he repeated something that I’ve heard before many times: “It’s really difficult to guarantee consistency of developer experience.” It’s not that we don’t have the tools, but they’re scattered, and the workflow for deploying something are not integrated. Besides, it can extremely time consuming, and prone to mistakes.

But what if there could be a “paved road” approach, where we enforce strict configurations and policies, and establish guardrails, therefore guaranteeing that we can guarantee security, isolation, limits, and the ability to audit the system any time we need to? This is what I’m trying to build with k8s-mtp: a multi tenant platform based on Kubernetes that abstracts away things like RBAC, NetworkPolicy, ResourceQuotas, and a bunch of other important but difficult things, to guarantee that the industry best-practices are always in place.

While I’m no stranger to building dashboards, there was always something that bothered me when I was using Grafana for displaying the metrics I wanted to look at: it was a web app! Now, while web apps are much maligned, they do serve a purpose. But for the purpose of displaying rather the rather simple information that Prometheus collect (yes, simple: a complex metric is a useless metric IMO), a web app seems overkill. And now that TUIs are back en vogue, I thought it could be a fun exercise to build a TUI for displaying Prometheus metrics. Hence, gopromtui: a lightweight, terminal-native solution for displaying Prometheus metrics without any additional infrastructure.

After finishing my previous project, I felt an itch to continue building. One of the things that was noticeable during that process was that my coding skills were not being pushed: while the app I built did teach me about integration of Prometheus inside a Golang application, there wasn’t much else new for me there. So, for my next project, I chose to concentrate on building software.

The question then became: what should I build? It occurred to me that if I wanted to concentrate on improving my software development skills, that I should choose a domain that I have some experience in, so as to remove an extra layer of complexity for the project. As I have some experience already with Kubernetes, and given that I love CLIs, the union of those two things seemed like a natural choice. I even already had a cluster running that I could easily test things on!