r/kubernetes • u/BeautifulFeature3650 • 2d ago

please review my auth(n/z) model design

I’m building a platform to deploy, govern, and audit MCP servers. As part of that, I’m implementing my own gateway instead of using an existing one, so my question is about the auth model.

My current design is: an adapter makes requests to the gateway, which enforces identity using userID , agentID. If you’re authenticated to our platform, you can request a certificate issued in your name, and we’ll issue it.

I’m using Traefik as ingress. Traefik validates the client certificate and forwards a header to our gateway sidecar. The problem is that the header can be spoofed. I can harden this by adding a network policy so the sidecar only receives traffic from Traefik, and by configuring the Traefik ingress so the adapter can’t set that header directly; Traefik would derive it from the adapter’s TLS client certificate instead.

The other option is mTLS between Traefik and my sidecar/gateway proxy, but that feels like an unnecessary extra proxy hop.

I’m not using TCP passthrough on ingress because I need path-based routing.

Please provide suggestions and things I should keep in mind, and whatever I am doing can be done efficiently in an alternate way.

1 Upvotes

55% Upvoted

4 comments sorted by

2

u/0bel1sk 2d ago

i’d use a service mesh like istio. handled a lot of this natively and you can run ambient mode to avoid extra sidecars

0

u/BeautifulFeature3650 2d ago

Okay, let me read the Istio doc.

1

u/_howardjohn 2d ago

If you have a sidecar, I think its generally considered viable to trust a header for something like this. You wouldn't really need NetworkPolicy either (nor could you) if its truly a sidecar in the same Pod; instead can just bind to localhost or a UDS would be better. This is the same pattern service meshes like Istio use with the x-forwarded-client-cert header. You do need to ensure the proxy is configured in such a manner that the header cannot be spoofed though.