istio
Add ambient mode caveats
Sidecar, ServiceEntry.exportTo and VirtualService.*.source_* are not used at all. While ServiceEntry wildcard hostnames also aren't supported.
😊 Welcome @Stevenjin8! This is either your first contribution to the Istio api repo, or it's been a while since you've been here.
You can learn more about the Istio working groups, Code of Conduct, and contribution guidelines by referring to Contributing to Istio.
Thanks for contributing!
Courtesy of your friendly welcome wagon.
https://docs.google.com/document/d/1JjsPzOMJfu_evzgiRp-aJf1KDpa9ImyYrew__y5CTao/edit?tab=t.0#heading=h.8vlgwrna7yow for the broader terminology discussion
The most common issue is the service entry related. @craigbox wdy think of just adding the service entry caveates for now (with more specific terminology)
Ambient does not support exportTo, it seems like a security risk, ztunnek/waypoint can make acccess escalation
@hzxuzhonghu could you speak a bit more? To me exportto is about discoverability, not security, so I'm having trouble seeing the connection
Think about a SE reside in test1 namespace, and exported to only test1, iiuc, then a caller resides in test2 can access it via a ztunnel now
I agree with Steven: lack of service discovery config sent to a sidecar is NOT a security boundary. exportTo on its own doesn't even limit calling the service from a different namespace; it has to be paired with REGISTRY_ONLY in meshconfig which is also not a security boundary.
