tl;dr:

• 1557 lines of code added
• 17 fix commits vs 8 feature commits
• Almost 60% of the commits were related with debugging the platform
• Complete rewrite of the webhook TLS logic

It’s been a while since I last posted about this project. The reason was not that it was abandoned, on the contrary: in the meantime, I’ve been able to add ~1500 lines of code to this project. I know this might not sound a lot in this day and age, but trust me: the problem is never about how many lines of code you write, but rather whether the code is good quality. And at this point, it was time to start testing what we had built so far; so much so, that in this time, ~60% of my commits have been related with fixing existing issues in the actual implementation. But I’m getting ahead of myself.

It’s hard to think about a more fundamental part of one’s digital identity than a password manager. In a sense, if you want to be sovereign over your digital presence, the password manager is what allows you to hold the keys to your kingdom. It’s pretty much that one security measure that everyone can agree on; managing all your passwords by yourself is bound to create problems of its own: either you are reusing the same password, or you are writing them down somewhere. This is not okay, and why password managers were born.

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.