istio
Add note about istio-cni security
Description
Add note about Istio CNI's security implications in ambient mode
Reviewers
- [ ] Ambient
- [ ] Docs
- [ ] Installation
- [ ] Networking
- [ ] Performance and Scalability
- [ ] Extensions and Telemetry
- [ ] Security
- [ ] Test and Release
- [ ] User Experience
- [ ] Developer Infrastructure
- [ ] Localization/Translation
@jaellio When you get a chance, can you let me know how/when to proceed with this
meaning that policies won't be enforced until after the CNI comes up and that pod is restarted.
@keithmattix @jaellio If we run into such an issue, is there a straightforward way to identify the pods where traffic is being bypassed? For example, if we run istioctl zc workloads, would the affected pods show HBONE or TCP?
@sridhargaddam it won't be based on config; it would be a lack of iptables rules in the pod netns. @jaellio can correct me if I'm wrong
@sridhargaddam it won't be based on config; it would be a lack of iptables rules in the pod netns. @jaellio can correct me if I'm wrong
It’d be useful to have a command that shows pods marked for the mesh but bypassing it (due to missing iptables rules). Maybe istioctl analyze... could be extended with an option to catch and report this situation?
Hmm that could work if the person running the command had kubectl debug permission
it is possible that a pod that is labeled for mesh enrollment may come up before the CNI's traffic redirection rules are applied, meaning that policies won't be enforced until after the CNI comes up and that pod is restarted.
I don’t expect this issue to occur in sidecar mode with istio-cni (since the istio-validation container checks that traffic redirection rules are in place). Can someone please confirm?
Correct, the istio-validation init container prevents this from happening in sidecar mode
Correct, the istio-validation init container prevents this from happening in sidecar mode
Cool, thanks for confirming, Keith.