networking: add pathTemplate match type to StringMatch

[AntonioMorales97]

Description

Add a new pathTemplate oneof variant to StringMatch to support URI template path matching in VirtualService HTTPMatchRequest.uri.

This allows matching patterns like /users/{*}/orders without resorting to regex:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: example
spec:
  hosts:
  - example.com
  http:
  - match:
    - uri:
        pathTemplate: "/users/{*}/orders"
    route:
    - destination:
        host: orders-service

• {*} matches exactly one path segment
• {**} matches one or more path segments (must be the last operator)

Backed by Envoy's UriTemplateMatchConfig extension, the same mechanism already used for AuthorizationPolicy path matching.

Motivation

• Consistency: AuthorizationPolicy already supports {*}/{**} path templates (#47306); VirtualService should too
• Simplicity: more readable and less error-prone than equivalent regex for REST API patterns
• Performance: avoids regex evaluation overhead

Related

• Fixes Support {*} / {**} path template operators in VirtualService URI matching istio#59533
• #47306 — added {*}/{**} to AuthorizationPolicy

The implementation in istio/istio is submitted as a dependent PR and will be linked once this merges.

[istio-policy-bot]

🤔 🐛 You appear to be fixing a bug in Go code, yet your PR doesn't include updates to any test files. Did you forget to add a test?

Courtesy of your friendly test nag.

[istio-policy-bot]

😊 Welcome @AntonioMorales97! 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 committers listed above are authorized under a signed CLA.

• ✅ login: AntonioMorales97 / name: Antonio Morales (fbdb857)

[istio-testing]

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

[Stevenjin8]

You might get more comments if you come to one of our weekly meeintgs https://github.com/istio/community/blob/master/WORKING-GROUPS.md#working-group-meetings

[AntonioMorales97]

You might get more comments if you come to one of our weekly meeintgs https://github.com/istio/community/blob/master/WORKING-GROUPS.md#working-group-meetings

@Stevenjin8 Hi! Is it possible to leave it as a point on the agenda of the meeting? 9:00 PST is 18:00 CEST so it's a bit hard for me to participate. The original issue is here (also linked in the PR description): istio/istio#59533

[jaellio]

You might get more comments if you come to one of our weekly meeintgs https://github.com/istio/community/blob/master/WORKING-GROUPS.md#working-group-meetings

@Stevenjin8 Hi! Is it possible to leave it as a point on the agenda of the meeting? 9:00 PST is 18:00 CEST so it's a bit hard for me to participate. The original issue is here (also linked in the PR description): istio/istio#59533

@AntonioMorales97 I'll present this on your behalf in next week's working group meeting! Added it to the agenda https://docs.google.com/document/d/1wsa06GGiq1LEGwhkiPP0FKIZJqdAiue-VeBonWAzAyk/edit?tab=t.0

[keithmattix]

Hey so sorry for the delay. I don't think this is something we want to do. Most core routing API evolutions are happening in gateway api, so it makes sense for something like this to become a standard there

[keithmattix]

@AntonioMorales97 forgot to mention in my previous response: to get started with that process in Gateway API, open up an issue here or attend the community meeting to present the enhancement request

[gustavovnicius]

Thanks @keithmattix, that direction makes sense. As the author of the original issue (istio/istio#59533), I've opened the enhancement in Gateway API here: kubernetes-sigs/gateway-api#5101. I can write the initial GEP draft and do the dataplane research; since I can't make the community meeting slot (CEST), I'm looking for a co-author or sponsor there to help carry it through.

One ask while that runs: would you reconsider this PR as an interim addition until Gateway API reaches parity? The reasoning:

• These exact {*} / {**} operators already ship in Istio's AuthorizationPolicy via the same Envoy uri_template extension, so it's a proven mechanism, not a new one.
• Until the Gateway API standard exists, there's no way to express segment-scoped routing without regex, which means AuthorizationPolicy templates and VirtualService regexes describe the same path two ways and can drift apart.

Glad to mark and document it as interim if that helps, and to remove or redirect once Gateway API ships the equivalent.

@jaellio thank you for offering to present. I can't make the slot (CEST). Would you be able to represent this, and do you know anyone in the WG who'd be up for co-sponsoring the enhancement? I'll do the drafting and research behind it.