Add a sidecar to Mixer

[geeknoid]

We want to add a proxy sidecar to Mixer in order to gain all the usual benefits of the sidecar, including mTLS, metrics, telemetry, quotas, etc.

The essence of this work is to figure out how to have the sidecar invoke its attached Mixer directly for Check and Report, rather than invoke its own endpoint recursively.

[ZackButcher]

From previous discussions the team has had: if we run Mixer's sidecar with Check and Report disabled we should avoid any call cycles. This gets us mTLS and network resiliency features for very little effort.

I think we should ship that first, then evaluate strategies for avoiding cycles in Check and Report afterwards.

[geeknoid]

We can definitely stage it, but ultimately we need to have the sidecar call Check and Report.

Turns out it's inherently simpler the complicated stuff we talked about previously. It's really just a matter of having the instance of the sidecar attached to Mixer communicate for Check and Report directly to its attached Mixer instead of trying to communicate to the normal mesh-level Mixer endpoint (which is itself). If we just break the circuit there, then everything else 'just works'.

[ZackButcher]

Cycles still exist in that scenario, right? Consider a Mixer instance configured to report to a metrics backend also in the mesh (i.e. it has a proxy in front that calls Report too):

A Report request comes in to Mixer; it's intercepted by Mixer's sidecar, forwarded to Mixer, and Mixer processes and responds. Mixer's sidecar then sends a Report about that call to the Mixer its in front of. That Report triggers Mixer calling our metric backend. That call goes through the backend's sidecar, which triggers a Report to Mixer.

The exact same argument applies for a backend in the mesh called on the Check path too. Or are you saying that calls to Mixer about Mixer can't result in calls to other backends (i.e. we need to forbid config that does that, or drop that traffic, something to that end)?

[geeknoid]

​I'm assuming that backends are not in the mesh, which I think makes everything work. We don't support this composition today already.

Once we have the sidecar working for Mixer, we can then later introduce support for the sidecar on Mixer backends. As we discussed, ultimately supporting that case will end up just being a matter of configuring the system such that when the backend's sidecar calls back to Mixer, it doesn't cause a loop back into the same backend.

So let's first add the sidecar to Mixer, and later worry about supporting sidecar on backends.

On Fri, Oct 20, 2017 at 6:37 AM, Zack Butcher notifications@github.com wrote:

Cycles still exist in that scenario, right? Consider a Mixer instance configured to report to a metrics backend also in the mesh (i.e. it has a proxy in front that calls Report too):

A Report request comes in to Mixer; it's intercepted by Mixer's sidecar, forwarded to Mixer, and Mixer processes and responds. Mixer's sidecar then sends a Report about that call to the Mixer its in front of. That Report triggers Mixer calling our metric backend. That call goes through the backend's sidecar, which triggers a Report to Mixer.

The exact same argument applies for a backend called on the Check path too. Or are you saying that calls to Mixer about Mixer can't result in calls to other backends (i.e. we need to forbid config that does that, or drop that traffic, something to that end)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/istio/mixer/issues/1470#issuecomment-338208822, or mute the thread https://github.com/notifications/unsubscribe-auth/AVucHYjozwMlgSw8YASiBi5LQG3WHfj2ks5suKIAgaJpZM4QAmF- .

[costinm]

I believe there is a PR already on pilot for this ? However it doesn't include sidecars for prometheus/graphana/etc yet.

[costinm]

https://github.com/istio/pilot/pull/1444

(Krishna is working on this - it is a P0 for securing all istio components)

[ZackButcher]

Excellent. Thank's for pointing that out Costin.

[geeknoid]

Simply slapping a sidecar on Mixer is not sufficient. We need to change something in the instance of the sidecar to call check/report on the attached Mixer. Just putting the sidecar without this change will lead to an infinite loop. ​

On Fri, Oct 20, 2017 at 9:17 AM, Zack Butcher notifications@github.com wrote:

Excellent. Thank's for pointing that out Costin.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/istio/mixer/issues/1470#issuecomment-338253380, or mute the thread https://github.com/notifications/unsubscribe-auth/AVucHXKF4iVEpHsYutgX39oNkTkyBRcwks5suMeXgaJpZM4QAmF- .

[qiwzhang]

Mixer filter config has knobs to control call Check/Report or not. For this mixer side-car proxy, we just need to turn Check/Report them off.

[ZackButcher]

We want Mixer's sidecar to call Mixer; it just needs to do it over localhost rather than calling the Mixer service (to ensure the request doesn't go through another sidecar in front of a different Mixer and trigger a cycle).

[kyessenov]

@geeknoid for the initial attempt, we will be statically configuring Envoys (without Pilot mostly). It's just a JSON with some templating.