iptables rules interference

[kyessenov]

This is something that is inevitably going to pop up: how do we deal with multiple sidecars operating on iptables rules. At the very least, we should document how we can exclude traffic per port or per container/process from istio proxy traffic capture. For per node set-up, dealing with kube-proxy iptables rules in conjunction with istio proxy rules needs to be addressed.

[rshriram]

multiple sidecars in same pod? Well, we could basically punt on it stating that there can be only one, unless someone is willing to setup some super fancy chaining.
Personally, if I were writing the app from scratch, i wouldn't bother running the init container for ip tables setup. Rather, i would just explicitly invoke the sidecar (depends on how you view the problem: enforcement or opt-in)

[kyessenov]

We want enforcement for security policies (auth especially). Currently, you can escape rules by setting PID, which is probably good enough for now.

[rshriram]

We should also be prepared for scenarios where IPtables setup is not desired (in non kubernetes platforms). If this issue is being tracked for beta (Aug 31st), then support for another platform like CloudFoundry is definitely on the plate.

[kyessenov]

Is there an adopted specification how to address services and ports with an explicit proxy? Should we adopt linkerd convention and only support HTTP?

[cmluciano]

@smawson Should this still be part of 0.2 since it now resides in backlog?

[rshriram]

This is probably irrelevant now since we have settled on the transparent proxy setup. A better issue would be to enable non transparent proxy in k8s

[cmluciano]

So should this be closed in favor of that epic?

[andraxylia]

This issue is orthogonal to the transparent proxy injection.

We need to leave it open and address it in 0.3. We need at a minimum to selectively capture traffic only for some of the container ports, opt-in or opt-out. Some of the other concerns from the description are also valid, but I see the selective capture as higher priority.

[kyessenov]

Issue moved to istio/istio #1428 via ZenHub