Enforce ServiceEntry exportTo visibility in ztunnel

[syn-zhu]

Summary

Enforce exportTo namespace visibility for ServiceEntries in ztunnel, preventing cross-namespace DNS resolution and VIP routing leakage in multi-tenant ambient deployments.

Changes

• workload.proto: Added export_to field to Service message (matches companion istiod PR)
• service.rs: Added export_to field to Service struct, is_visible_to(client_ns) method, namespace-scoped get_by_vip, and unscoped get_by_vip_unscoped for inbound paths
• dns/server.rs: find_server filters services by is_visible_to(client.namespace) before find_best_match
• state.rs: find_upstream passes source_workload.namespace to get_by_vip

How it works

istiod populates the export_to field on each workloadapi.Service from the ServiceEntry's spec.exportTo (with DefaultServiceExportTo mesh config fallback). ztunnel checks this field at two critical lookup points:

1. DNS resolution: services not visible to the source pod's namespace are filtered out, preventing cross-namespace hostname resolution
2. VIP routing: get_by_vip checks visibility against the source workload's namespace, preventing cross-namespace VIP traffic routing

The check is O(1) for the common case (empty export_to = visible to all).

Companion PR

istiod-side changes (proto + population): istio/istio#59653

Fixes istio/istio#59652

🤖 Generated with Claude Code

[istio-policy-bot]

😊 Welcome @syn-zhu! This is either your first contribution to the Istio ztunnel 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.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: syn-zhu / name: Simon Zhu (ab2d79c)

[istio-testing]

Hi @syn-zhu. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.