Add parallel frontend + MISE v2 stack with header-based routing

[tony-schndr]

https://redhat.atlassian.net/browse/ARO-23709

What

Deploy a parallel frontend + MISE v2 stack alongside the existing v1 stack, with Istio header-based traffic splitting and e2e tests validating the routing.

Why

MISE v2 has a different configuration format and auth flow. Deploying it as a parallel stack behind a header-based route allows us to validate v2 behavior in-place without disrupting existing v1 traffic. Once validated, cutover can be done by changing the default route.

How routing works

A Kubernetes Deployment can only reference a single ext-authz AuthorizationPolicy, so the VirtualService must handle routing to the correct frontend — it cannot route directly to MISE because Envoy ignores that path. Therefore:

• The original aro-hcp-frontend deployment has an AuthorizationPolicy binding it to ext-authz (MISE v1)
• The new aro-hcp-frontend-v2 deployment has an AuthorizationPolicy binding it to ext-authz-misev2 (MISE v2)
• The VirtualService inspects the x-ms-mise-version request header: if set to v2, traffic routes to aro-hcp-frontend-v2; otherwise traffic routes to aro-hcp-frontend (v1 default)

By splitting at the VirtualService level, each frontend instance is guaranteed to use its corresponding MISE version.

Testing

E2e tests (test/e2e/mise_routing.go) validate routing by asserting on a response header:

• The VirtualService adds an x-ms-served-by: v2 response header only for v2-routed requests. The default route adds no response header.
• Tests use Azure SDK per-call policies to inject (or omit) the x-ms-mise-version: v2 request header, then assert the x-ms-served-by response header value
• Two table-driven test entries cover both paths:
  • With x-ms-mise-version: v2 header → expects x-ms-served-by: v2 (confirms routing to v2 frontend)
  • Without the header → expects no x-ms-served-by header (confirms default routing to v1 frontend)

Environment-specific behavior:

• In dev/prow environments, MISE is not available, so the tests validate VirtualService routing only. This gives confidence that header-based traffic splitting works correctly.
• In INT/stage/prod, the same routing is exercised with real MISE instances, validating the full auth flow end-to-end.

Special notes for your reviewer

This is the routing/deployment plumbing only. The actual cutover from v1 to v2 as the default will be a separate change once e2e validation in INT is complete.

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[tony-schndr]

/test all

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tony-schndr
Once this PR has been reviewed and has the lgtm label, please assign stevekuznetsov for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tony-schndr]

/test all

[tony-schndr]

/test all

[tony-schndr]

/test all

[tony-schndr]

/test all

[openshift-ci]

@tony-schndr: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/verify	0662ec4	link	true	/test verify
ci/prow/test-unit	0662ec4	link	true	/test test-unit
ci/prow/config-change-detection	0662ec4	link	true	/test config-change-detection
ci/prow/cspr	0662ec4	link	true	/test cspr

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.