RFC: Add label selector support to exportTo field

[hbhasker]

Summary

This PR adds label selector support to the exportTo field for networking resources in the Istio API.

Implements support for: istio/istio#50661

Changes

1. Add exportToSelectors field to networking resources

• networking/v1alpha3/virtual_service.proto: Added export_to_selectors field (field number 7)
• networking/v1alpha3/destination_rule.proto: Added export_to_selectors field (field number 6)
• networking/v1alpha3/service_entry.proto: Added export_to_selectors field (field number 10)

2. LabelSelector type definition

• Added LabelSelector and LabelSelectorRequirement messages to type/v1beta1/selector.proto
• Kept LabelSelector in mesh/v1alpha1/config.proto for backward compatibility
• New networking resources use istio.type.v1beta1.LabelSelector
• Existing MeshConfig fields continue using mesh.v1alpha1.LabelSelector

Backward Compatibility

This PR maintains backward compatibility:

• LabelSelector exists in both mesh/v1alpha1 and type/v1beta1
• Existing code using meshconfig.LabelSelector continues to work
• New code can use typev1beta1.LabelSelector for networking resources

Example Usage

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
  namespace: bookinfo
spec:
  hosts:
  - reviews
  exportTo:
  - "."  # Static: current namespace
  exportToSelectors:
  - matchLabels:
      env: production  # Dynamic: all namespaces with env=production
  - matchExpressions:
    - key: team
      operator: In
      values: [platform, infrastructure]
  http:
  - route:
    - destination:
        host: reviews

When both exportTo and exportToSelectors are specified, the resource is exported to the union of all matched namespaces.

Protobuf Field Numbers

Carefully chosen to avoid conflicts:

• VirtualService: field 7 (unused)
• DestinationRule: field 6 (unused)
• ServiceEntry: field 10 (unused)

Related

• Issue: exportTo needs to support label selectors istio#50661
• Implementation PR: Add label selector support to exportTo field airbnb/istio#35

🤖 Generated with Claude Code

[istio-policy-bot]

😊 Welcome @hbhasker! 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.

[linux-foundation-easycla]

• ❌ The email address for the commit (00761d3, 173051f, 26e8f08, 8b8693e) is not linked to the GitHub account, preventing the EasyCLA check. Consult this Help Article and GitHub Help to resolve. (To view the commit's email address, add .patch at the end of this PR page's URL.) For further assistance with EasyCLA, please submit a support request ticket.

[istio-testing]

Hi @hbhasker. 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.

[howardjohn]

I don't think this is tenable to implement realistically

…

On Wed, Jan 14, 2026, 12:24 PM Istio Automation ***@***.***> wrote: *istio-testing* left a comment (istio/api#3636) <#3636 (comment)> Hi @hbhasker <https://github.com/hbhasker>. Thanks for your PR. I'm waiting for a istio <https://github.com/orgs/istio/people> 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 <https://github.com/orgs/istio/people> 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 <https://go.k8s.io/bot-commands?repo=istio%2Fapi>. Details Instructions for interacting with me using PR comments are available here <https://git.k8s.io/community/contributors/guide/pull-requests.md>. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow <https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:> repository. — Reply to this email directly, view it on GitHub <#3636 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXPZDNEQQNMUDKWIRD34G2QXHAVCNFSM6AAAAACRW27F2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJRGU3TIOBRGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[hbhasker]

@howardjohn could you elaborate on why? btw sorry I explicitly marked this as draft for now because I didn't think it was ready for review. But since I have your attention :)

[hbhasker]

ping @howardjohn , I have an WIP implementation(untested) for this but I would like to understand why you think its untenable before I spend more time on the implementation.

[devogopan]

+1

Can we give life to this PR ? This reduces a lot of overhead on platform teams.

If this is technically difficult, how about regular expression ? say all namespaces starting with product. Or say all namespaces ending with internal

[zirain]

ping @howardjohn , I have an WIP implementation(untested) for this but I would like to understand why you think its untenable before I spend more time on the implementation.

Since both @howardjohn and @ramaraochavali believe that it's hard to implement.
can you kindly send out you draft PR to help us understand this FR better.

[howardjohn]

Its not just about 1 time PR complexity, its the long term. When we later realize we missed some edge case and it bloats, when we realize we need to implement it in some other places (ambient, etc), when we realize it doesn't scale and causes unfixable performance issues. A small PR showing it is "simple" would not make me in favor of this API.

…

On Tue, Mar 17, 2026 at 3:48 AM zirain ***@***.***> wrote: *zirain* left a comment (istio/api#3636) <#3636 (comment)> ping @howardjohn <https://github.com/howardjohn> , I have an WIP implementation(untested) for this but I would like to understand why you think its untenable before I spend more time on the implementation. Since both @howardjohn <https://github.com/howardjohn> and @ramaraochavali <https://github.com/ramaraochavali> believe that it's hard to implement. can you kindly send out you draft PR to help us understand this FR better. — Reply to this email directly, view it on GitHub <#3636 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEYGXL7KLCJL7ANK6K6MF34REUPHAVCNFSM6AAAAACRW27F2CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DANZUGAZTQMZYGM> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[keithmattix]

I'm also a -1 to this API; exportTo only exists because of sidecar scaling issues and lack of proper namespace tenancy semantics in the v1alpha3 networking APIs. I don't see a reason to extend usage of this pattern; we should instead be moving users over to Gateway API