egress-operator VS kubetls

Linkerd. I implemented Istio for the same reason at my first Kubernetes job. Comes with all the bells and whistles out of the box, but it’s all tightly coupled, as OP said doesn’t upgrade well. I’ve since realised “one tool for one job” is better. Linkerd for mesh and something else for ingress and egress. There are lots of options, I’m looking at implementing Monzo’s egress operator next time I need to control egress https://github.com/monzo/egress-operator.

Hi! I wrote a thing called KubeTLS that automatically provisions MTLS certificates per-pod. It is not necessarily simpler than KubeTLS, because you need a lot of the same components, but if you're not looking for the whole set of baggage that comes with an integrated and opinionated (and in my view, often wrong) solution, I'd be happy to help you give it a try.

I'm working on KubeTLS to make Certificates a first-class concept; though I'm also pushing Kubernetes upstream to adopt the concept. Everything should run with certs, and it's all about solving problems of trust and key distribution.

I built a tool for just that: https://gitlab.com/gauntletwizard_net/kubetls . It's out of date and half-baked - Nowhere near production ready. It might help you start as a baseline.

I am working towards this goal, sort of: I believe that TLS should be self-configuring. I've built a spec and some tools around automatically issuing TLS certificates automatically in a well-defined place in Kubernetes clusters. You then call my init code to start up your services - Exactly like you'd call http.ListenAndServe(), you call KubeTLS.ListenAndServe(). The code is simple enough, and there's a little script you run on your development machine to create a self-signed cert locally.

https://gitlab.com/gauntletwizard_net/kubetls

I’m the author of a tool called KubeTLS. KubeTLS creates certificates for use in MTLS between pods in your cluster. These certificates are identified as the Service Account that the pod is running as (for use in identifying to the cluster), but also as server certificates for identifying the server to other client pods. There’s no reason those two usages couldn’t be split into two certificates, but no reason for them to be - The X509 spec and client libraries do the right thing.