In what area(s)?

/area API
/area networking

Describe the feature

The Request

We request the ability to customize HTTP Request Headers in the VirtualService generated and managed by the operator.

The Use Case

We utilize a shared Istio External Authorizer (ExtAuthz) to handle authentication (e.g., SSO/JWT) for multiple distinct services.

Because our External Authorizer is a centralized service shared across the different services, it is generic by design. It does not inherently know which authentication policy to apply to a specific incoming request. To bridge this gap, we rely on passing context via headers.

We need the specific Service route to inject metadata headers (e.g., x-accept-auth) into the request before it is handed off to the External Authorizer. The Authorizer reads these headers to dynamically determine the correct security flow for that specific service.

The Problem

Currently, the VirtualService is fully managed by the operator. There is no mechanism to define these headers in the source CRD, and manual patches to the VirtualService are reverted by the operator's reconciliation loop.

This prevents us from using a dynamic External Authorizer, forcing us to maintain low level envoy filter as a workaround.

Example of Desired Output

Regardless of the specific implementation path, we need the final VirtualService to include the headers section as shown below:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
spec:
  http:
  - route:
    - destination:
        host: my-service
        port:
          number: 80
    # WE NEED THIS SECTION:
    headers:
      request:
        set:
          # Context used by the External Authorizer to decide Auth flow:
          x-accept-auth: "SAML"