Pod injection is replica blind
Stealing traffic from one pod behind an HPA is a coin flip, and pod filters cannot match a JWT claim.
Personal traffic intercepts for Kubernetes.
Route only your requests to the service running on your laptop. Matched traffic reaches your debugger; everyone else stays on the real pods.
INCOMING REQUESTGET /api/v2/orders
authorization Bearer eyJhbGci...
claim.email you@corp.com
RELAY / YOUR NAMESPACE
Decode claim / match ruleRouting hint only. The target still owns authorization.is this yours?
yes
YOUR LAPTOP / :8080
Reverse tunnel to local app breakpoint waitingno
REAL TARGET PODS
Transparent passthroughx-outprobe-bypass: 1WHY A RELAY
The right interception point is where identity becomes visible.
The goal is simple: drive the shared app and stop at a local breakpoint. In a locked-down, replicated service mesh, the usual interception points cannot reliably identify your request.
Cluster managers need broad permission
Shared clusters often do not let developers install or operate a cluster-wide control plane.
Mesh routes only see raw headers
VirtualService and HTTPRoute cannot inspect a JWT claim such as email.
Decode the token in a namespace-scoped relay, use the claim only as a routing hint, and dispatch a matching request to the connected developer.
THE REQUEST PATH
One route in. Per-request dispatch back out.
The relay stays generic. Each laptop registers its own matching rule when its tunnel workers connect.
- 01
Route candidate traffic
A VirtualService, HTTPRoute, or target-side EnvoyFilter sends the selected feed to the relay.
- 02
Evaluate the rule
The relay extracts a JWT claim or HTTP header and resolves the first connected match.
- 03
Tunnel to the laptop
The CLI forwards the request through its Kubernetes port-forward to your local service.
- 04
Leave everyone else alone
Unmatched traffic reaches the real target; in mirror modes, the real service always responds.
TRAFFIC MODES
Choose the interception side and response owner.
Caller-side modes are simpler. Target-side modes also catch clients without an Istio sidecar.
Compare the trade-offs| Mode | Coverage | Response |
|---|---|---|
divertdefault | Meshed callers | Local service |
mirrorobserve | Meshed callers | Real service |
inbound-divertall callers | Mesh + non-mesh | Local service |
inbound-mirrorall callers | Mesh + non-mesh | Real service |
THE WHOLE DEBUG LOOP
Inbound requests and outbound dependencies through one relay.
Identity-aware matching
Route on a stable JWT claim such as email, or use a plain HTTP header.
No inbound laptop access
The CLI connects out through a client-go port-forward; the cluster never dials your machine.
Browser traffic too
Optional Gateway API routes catch selected browser traffic through a narrow header gate.
Reach cluster dependencies
Expose HTTP, gRPC, Postgres, or another TCP service locally through the same connection.
Scoped cluster footprint
The relay and routing objects stay in the target namespace, without a cluster-wide manager.
Routing-first teardown
Ctrl-C removes routing before the relay so direct traffic is restored first.
QUICKSTART
From install to breakpoint.
Install the CLI, scaffold one config file, add your service and identity, then bring the intercept up.
Full walkthrough# install the laptop CLI brew install outprobe/outprobe # scaffold .outprobe.yaml outprobe init # set target, namespace, identity, and relay image # run the local app, then start the intercept outprobe up ready / matched requests now route to localhost:8080
OPEN A PERSONAL ROUTE
Your traffic, your laptop.
Everyone else, untouched.
Bring up the intercept while you debug, then restore direct routing with Ctrl-C.