Request matching

Matching happens in two tiers. The routing layer can first narrow which requests reach the relay; the relay then decides which connected developer owns each candidate request.

Tier 1: the shared feed

A feed: list is an optional Istio pre-filter used only by mode: divert:

.outprobe.yaml

feed:
  - path: /api/v2/
  - header: x-debug-user
  - header: x-environment
    value: dev

Entries are OR’d:

• path is a URI prefix;
• header without value matches presence;
• header with value is an exact match.

Requests outside the feed go directly to the target and never reach the relay. Requests inside it still need to match a registered client rule.

The feed must be a superset

If your rule selects a request that the feed excludes, the relay never sees it. Start broad, verify interception, and narrow afterward.

feed is ignored by mirror, inbound-mirror, and inbound-divert.

Tier 2: the client rule

The laptop CLI reads .outprobe.yaml, selects the first rule containing a matcher, and registers that rule on every tunnel worker. The relay has no static identity config.

JWT claim

For a top-level claim:

.outprobe.yaml

rules:
  - type: jwt
    property: ""
    matchers:
      - key: email
        value: you@example.com

Given this token payload:

{
  "sub": "user-123",
  "email": "you@example.com"
}

outprobe extracts email and compares it exactly with the configured value.

For providers that namespace custom claims, split the namespace and claim name:

.outprobe.yaml

rules:
  - type: jwt
    property: https://your-org.example.com/
    matchers:
      - key: email
        value: you@example.com

This selects https://your-org.example.com/email from the decoded claims object.

HTTP header

Use a header when a token claim is unavailable or manual opt-in is preferable:

.outprobe.yaml

rules:
  - type: header
    matchers:
      - key: x-debug-user
        value: denis

Go’s HTTP header lookup is case-insensitive. The value comparison is exact.

Current v1 selection rules

The config schema is intentionally list-shaped for future expansion, but the current CLI uses:

• the first rule that has at least one matcher;
• the first matcher in that rule;
• only jwt and header as relay identity types.

Identity has no flag or environment override. Put it in .outprobe.yaml; flags and env vars override deployment fields only.

Path is not an identity rule

Use feed.path or normal Istio routing for path selection. The relay exists primarily for identity values the mesh cannot extract.

Multiple developers

A relay registry can hold clients with different rules at once:

Developer	Type	Selector	Value
A	jwt	email	a@example.com
B	jwt	namespaced sub	user-b
C	header	x-debug-user	charlie

Rules are evaluated in registration order. First registered wins if two rules match the same request. Once a client’s final worker disconnects, its registration is removed.

Security properties

Decoded, not verified

Claim decoding is only routing. Never treat a relay match as authentication or authorization.

Stable, non-secret values

Prefer a value such as email or subject ID. Do not place bearer tokens or other secrets in the config.

The relay sees candidate traffic

In divert mode the relay sees its feed; in inbound-mirror it sees every inbound copy. Keep it up only while debugging.

Passthrough auth stays intact

The local service receives the original headers, while real-pod passthrough follows the target’s normal mesh and app security path.