Add request mutation fields (authority, headers) to HTTPMirrorPolicy

[aburan28]

Summary

Expose Envoy's mirror-request mutation surface on HTTPMirrorPolicy by adding two fields:

• authority — rewrites the Host (:authority) header on the mirrored request. Maps to Envoy's host_rewrite_literal. When set, Envoy implicitly disables the default -shadow suffix append.
• headers — request header manipulation rules applied to the mirrored request. Maps to Envoy's request_headers_mutations. This uses Headers.HeaderOperations directly so mirror config exposes only request mutations (set, add, remove) and does not expose a meaningless response-mutation branch.

message HTTPMirrorPolicy {
  Destination destination = 1 [(google.api.field_behavior) = REQUIRED];
  Percent percentage = 2;
  string authority = 3;                     // NEW
  Headers.HeaderOperations headers = 4;     // NEW
}

Motivation

Today, mirrored traffic always carries either the primary destination's Host header or that host with -shadow appended (toggled by the DISABLE_SHADOW_HOST_SUFFIX pilot env). That's restrictive in several real-world cases:

• vhost-routed mirror targets. Sending shadow traffic to a SaaS analytics endpoint or a different namespace where the target performs Host-based routing requires a specific authority, not the primary one.
• Differentiating shadow traffic. Adding markers like x-shadow: true so downstream systems can ignore mirror requests in metrics/billing.
• Stripping internal headers. Removing auth tokens or PII from mirror requests before they leave the trusted boundary.

Today users reach for EnvoyFilter patches for these — direct API support is cleaner and easier to validate.

authority mirrors the naming of the existing HTTPRewrite.authority field (which does the equivalent thing on the primary request), so the API stays internally consistent.

Changes

• networking/v1alpha3/virtual_service.proto: added authority (string, fieldnum 3) and request-only headers (Headers.HeaderOperations, fieldnum 4) to HTTPMirrorPolicy.
• Regenerated networking/v1alpha3/virtual_service.pb.go with protoc-gen-go v1.36.11.
• Regenerated networking/v1alpha3/virtual_service.pb.html so API docs include the new fields.
• Regenerated kubernetes/customresourcedefinitions.gen.yaml; mirrors[].headers now exposes only set, add, and remove in all three VirtualService CRD versions.

Notes for reviewers

The v1/v1beta1 alias files re-export the v1alpha3 type via = and need no change. Deepcopy delegates to proto.Clone and the JSON shim uses proto reflection, so both pick up the new fields automatically.

A companion change in istio/istio wires these through TranslateRequestMirrorPolicy (including a small HeaderOperations → Envoy HeaderMutation translator for the mirror case) and will be sent as a follow-up PR once this lands and a tagged istio.io/api is available.

Test plan

• BUILD_WITH_CONTAINER=0 make gen-proto
• buf lint
• go test ./...
• python3 scripts/validate_crds.py check_equal_schema --kinds VirtualService --versions v1,v1beta1,v1alpha3 --file kubernetes/customresourcedefinitions.gen.yaml
• scripts/breaking.sh master
• git diff --check
• CI builds proto and regenerated artifacts cleanly after /ok-to-test

Note: BUILD_WITH_CONTAINER=0 UPDATE_BRANCH=master make gen-check cannot complete on this macOS host because clean.sh uses shopt -s globstar, which is unsupported by the system Bash 3.2. The generation, lint, CRD schema, breaking, and Go test steps above were run directly.

[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 @aburan28! 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.

[istio-testing]

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