Published: Dec 9, 2023 by Isaac Johnson

I had an idea for an app. I don’t often get those…

Basically, I want a service with auth that can toggle on and off ingress to apps. I find myself often having either under-secured demo apps or minor one-off apps that I would like to selectively enable. But I don’t really want to have to login and use kubectl to enable and disable ingress.

I searched, of course, to see if someone else already made it but I could find no such tool.

So, having now had an idea what is next?

Crawl Walk Run

As always, when building out a project, we need to define our specific stages.

Stage 1

I need a service that can see ingresses and disable them. It could disable with an annotation, or messing the service routing. I have a few options

I also want to create a very basic “Service is Disabled” splash page things route to.

Stage 2

I want to add some kind of auth, at the very least internal. I want logging of actions and a decent UI

Stage 3

Some stretch goals are full federated auth, easy installation, documentation and a full open-source rollout.

Another stretch goal is to handle (and test) proper RBAC so we can limit to a namespace or affect the whole cluster.

I’ve been thinking about ingresses, but I likely need to consider things like Istio VirtualServices as well.

Requirements

1. Containerized: I don’t want some kind of local install
2. Helm deploys

other thoughts

This is a good test of some of the things we cover here:

1. diagrams in mermaid
2. git repos in Forgejo
3. Containers in Harbor (and dockerhub or other globally shareable location)
4. issue tracking and project management - TBD
5. notifications - likely with sendgrid and resend.dev
6. usage of Matrix for chat/updates
   1. might be nice to a have a variety of notification endpoints
7. ? DAPR
8. Metrics - Otel - tracing and logs
9. storage

Draw draw draw

I always start with scratching out ideas on paper or paper substitute.

I was sitting idle (okay, busted, I was in church, but my mind wanders sometimes) and scribbled out the following

Above: the basic setup

Above: I was just thinking through what the auth flow might look like

Project

I’ll start by creating a project in Forgejo

I want to create a “Spikes” column just to denote some info gathering work

The thing about projects is that they contain issues from repos so to create work, we have to start at the repo level.

I’ll create a new repo, though for now make it private, to start to catalogue work

Now I’m able to create some Issues and assign them to a project

I’ll tackle both NodeJS and Python.

Now when I get back to the Project page, I can see the Spikes in ‘Uncategorized’. This just means they haven’t been accepted by the team yet.

Since I’m ready to start on NodeJS, I’ll move that one to In Progress, but leave the other spike in To Do. In fact, it dawned on my that “Spike” is more of a type than a state.

I’ll remove the column while I’m at it

I’ll use labels to denote sub-states. Here I want to indicate that the goal is to get more info

I’ll also assign it to myself and set the kind to documentation (a spike is a mini research project)

Next steps

I want to work this like a normal project. That means I’m not going to just complete the whole thing in one post. With few exceptions, life works in fits and starts.

The goal here was to take an idea, spitball some “hows”, do a diagram or two and then break down some initial spikes.

On of our goals will be to build out some stories that get us to the end, again; “crawl walk run”. Another analogy often used is ‘scooter, bicycle, car’ or similar. We need to get something that will move us going and build from there.

I already have something baking, so worry not, this won’t stall out. Next post will cover our initial NodeJS and Python findings and then build from there.