provide a way to categorize incoming traffic from outside the mesh

[memory]

Feature Request

Add a way to manually categorize "unmeshed" traffic with a unique name in addition to the source IP address.

What problem are you trying to solve?

Presently, any traffic that arrives to a pod from outside the service mesh (e.g. from an ingress or other load-balancer) is categorized only by its source IP address, and there is no way to further break down rps/error rates beyond that. Since multiple sources might share an internal load balancer (for example a GCP CloudComposer or DataFlow job talking to an internal LB deployed for a service in a GKE cluster), it would be extremely helpful to see in tap or the linkerd web console what the actual source of the traffic is.

How should the problem be solved?

If an l5d-src-override header is present in an incoming http request, linkerd should categorize that request as coming from the service name specified in that header.

(I'm not sure if there's a good solution for non-http traffic, although I am tempted to recommend going extremely old-school and supporting something like ident)

Any alternatives you've considered?

Psychic powers? :)

How would users interact with this feature?

Ideally this would be totally transparent: manually tagged traffic would look like any other source in the linkerd ui/cli, possibly with some sort of highlight to make clear that it was manually rather than automatically categorized?

[grampelberg]

Is it possible for these load balancers to add a header?

[memory]

At least for our use case, my intention would be for the various traffic sources that share the LB as a point of entry to add the header when the request is generated.

But yes, they can.

[grampelberg]

TIL! Perfect! There's a pretty large potential for this being used by someone malicious externally, either to crash your prometheus with crazy cardinality or manipulate metrics and internal systems. Should this be an opt-in only feature at the pod level or is there a better way for us to determine that it is safe? As these are going to be external requests, we won't be able to rely on mTLS and identity.

[memory]

Hm, the malicious header case is interesting. I can think of a couple of ways to deal:

1- document the heck out of it and make it the user's responsibility to filter/reset the header at the perimeter (lame, but low-effort; not sure what the story is for e.g. amazon ALBs)

2- require a second header (l5d-src-override-authorize?) to pass in a shared secret without which the mesh will not honor the override

3- require a second header (l5d-src-override-sig?) to contain a signature of the l5d-src-override header made by a pre-shared key

...and yeah, probably safest to make it opt-in at the pod level; at least in our case the pods we'd want to use this with are not and will never be directly externally accessible.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[memory]

bump; I still think this is a reasonably good idea. :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[memory]

Bumping again because I still think this is a good idea. 🤣

[hawkw]

Bumping again because I still think this is a good idea. :rofl:

@memory I added the pinned label, so you can stop doing that. :)

As a side note, if you'd like to see something like this added to Linkerd, a good way to hurry it along might be to write a Linkerd RFC to propose a design for it. That way, we could start to collect community feedback on the design, and come up with a plan that you or someone else in the community could work on implementing.

[memory]

that's an entirely reasonable request -- I'll schedule some time to do that in an upcoming sprint.