[release-4.16] OCPBUGS-86713: Add configuration override for X-SSL strip

[MrSanketkumar]

Router strips X-SSL headers from HTTP listeners. In some cases a Load Balancer may be doing TLS termination and sending traffic to router with these headers. While this topology is not supported, there is a need for a knob to allow these users to rollback this validation assuming the risks of allowing the router to accept the X-SSL headers on the HTTP listener

[openshift-ci-robot]

@MrSanketkumar: This pull request references Jira Issue OCPBUGS-86713, which is invalid:

• expected dependent Jira Issue OCPBUGS-86714 to be in one of the following states: VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA), but it is ASSIGNED instead

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

Details

In response to this:

Router strips X-SSL headers from HTTP listeners. In some cases a Load Balancer may be doing TLS termination and sending traffic to router with these headers. While this topology is not supported, there is a need for a knob to allow these users to rollback this validation assuming the risks of allowing the router to accept the X-SSL headers on the HTTP listener

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 openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: d9b053ad-2402-4455-a345-a4a5e2dd4d8b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[MrSanketkumar]

/hold

This PR should be merged first : openshift/router#805

[MrSanketkumar]

/retest-required

[MrSanketkumar]

/test e2e-hypershift

[UdayYendva]

I created a cluster using the build that contains the merged fix from PR #1487.

ClusterVersion:

oc get clusterversion
NAME      VERSION                                                AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.16.0-0-2026-07-01-054303-test-ci-ln-fkghk7t-latest   True        False         4m47s   Cluster version is 4.16.0-0-2026-07-01-054303-test-ci-ln-fkghk7t-latest

Validation of ROUTER_MUTUAL_TLS_HEADER_FILTER

1. Verify default behavior

Initially, I checked whether the ROUTER_MUTUAL_TLS_HEADER_FILTER environment variable was present in the router deployment:

oc describe deployment/router-default | grep ROUTER_MUTUAL_TLS_HEADER_FILTER

Result: No output.

This is expected because the default value is not explicitly rendered in the deployment.

I then checked the running router pods:

oc get pods
NAME                              READY   STATUS    RESTARTS      AGE
router-default-7f5b5796bc-6shgt   1/1     Running   0             15m
router-default-7f5b5796bc-zpb9n   1/1     Running   1 (17m ago)   24m

Inspecting one of the newly created router pods:

oc get pod/router-default-7f5b5796bc-6shgt -o yaml | grep ROUTER_MUTUAL_TLS_HEADER_FILTER -A 1

Result: No output.

This is also expected because the environment variable is omitted when using the default value.

2. Set ROUTER_MUTUAL_TLS_HEADER_FILTER=false

After explicitly configuring:

oc patch ingresscontroller default -n openshift-ingress-operator --type=merge -p '{"spec":{"unsupportedConfigOverrides":{"mutualTLSHeaderFilter":"false"}}}'
ingresscontroller.operator.openshift.io/default patched

I verified that the deployment was updated accordingly:

oc describe deployment/router-default | grep ROUTER_MUTUAL_TLS_HEADER_FILTER
      ROUTER_MUTUAL_TLS_HEADER_FILTER:           false

The router deployment then rolled out updated pods.

Checking the router pod configuration:

oc get pod/router-default-7f5b5796bc-6shgt -o yaml | grep ROUTER_MUTUAL_TLS_HEADER_FILTER -A 1

- name: ROUTER_MUTUAL_TLS_HEADER_FILTER
  value: "false"

With the default value set to true, the router filters the mutual TLS headers, preventing users from leveraging the HTTP request header stripping functionality introduced in PR openshift/router#805.

When ROUTER_MUTUAL_TLS_HEADER_FILTER is explicitly set to false, the filtering behavior is disabled, allowing users to access and utilize the HTTP request header stripping functionality that was implemented in PR #openshift/router#805.

The validation confirmed that:

By default, the environment variable is configured with a value of true.
When the value is changed to false, the updated configuration is propagated to the router deployment and router pods.
/verified by ci

[openshift-ci-robot]

@UdayYendva: This PR has been marked as verified by ci.

Details

In response to this:

I created a cluster using the build that contains the merged fix from PR #1487.

ClusterVersion:

oc get clusterversion
NAME      VERSION                                                AVAILABLE   PROGRESSING   SINCE   STATUS
version   4.16.0-0-2026-07-01-054303-test-ci-ln-fkghk7t-latest   True        False         4m47s   Cluster version is 4.16.0-0-2026-07-01-054303-test-ci-ln-fkghk7t-latest

Validation of ROUTER_MUTUAL_TLS_HEADER_FILTER

1. Verify default behavior

Initially, I checked whether the ROUTER_MUTUAL_TLS_HEADER_FILTER environment variable was present in the router deployment:

oc describe deployment/router-default | grep ROUTER_MUTUAL_TLS_HEADER_FILTER

Result: No output.

This is expected because the default value is not explicitly rendered in the deployment.

I then checked the running router pods:

oc get pods
NAME                              READY   STATUS    RESTARTS      AGE
router-default-7f5b5796bc-6shgt   1/1     Running   0             15m
router-default-7f5b5796bc-zpb9n   1/1     Running   1 (17m ago)   24m

Inspecting one of the newly created router pods:

oc get pod/router-default-7f5b5796bc-6shgt -o yaml | grep ROUTER_MUTUAL_TLS_HEADER_FILTER -A 1

Result: No output.

This is also expected because the environment variable is omitted when using the default value.

2. Set ROUTER_MUTUAL_TLS_HEADER_FILTER=false

After explicitly configuring:

oc patch ingresscontroller default -n openshift-ingress-operator --type=merge -p '{"spec":{"unsupportedConfigOverrides":{"mutualTLSHeaderFilter":"false"}}}'
ingresscontroller.operator.openshift.io/default patched

I verified that the deployment was updated accordingly:

oc describe deployment/router-default | grep ROUTER_MUTUAL_TLS_HEADER_FILTER
     ROUTER_MUTUAL_TLS_HEADER_FILTER:           false

The router deployment then rolled out updated pods.

Checking the router pod configuration:

oc get pod/router-default-7f5b5796bc-6shgt -o yaml | grep ROUTER_MUTUAL_TLS_HEADER_FILTER -A 1

- name: ROUTER_MUTUAL_TLS_HEADER_FILTER
 value: "false"

With the default value set to true, the router filters the mutual TLS headers, preventing users from leveraging the HTTP request header stripping functionality introduced in PR openshift/router#805.

When ROUTER_MUTUAL_TLS_HEADER_FILTER is explicitly set to false, the filtering behavior is disabled, allowing users to access and utilize the HTTP request header stripping functionality that was implemented in PR #openshift/router#805.

The validation confirmed that:

By default, the environment variable is configured with a value of true.
When the value is changed to false, the updated configuration is propagated to the router deployment and router pods.
/verified by ci

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 openshift-eng/jira-lifecycle-plugin repository.

[MrSanketkumar]

/test e2e-hypershift

[openshift-ci]

@MrSanketkumar: all tests passed!

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.

[Miciah]

This is a clean cherry-pick of #1486.

/approve
/lgtm

This is a low-risk backport PR. The assessment for the release-4.21 backport #1471 (comment) applies equally to the release-4.16 backport.

/label backport-risk-assessed

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Miciah

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

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [Miciah]

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

[MrSanketkumar]

/jira refresh

[openshift-ci-robot]

@MrSanketkumar: This pull request references Jira Issue OCPBUGS-86713, which is valid.

7 validation(s) were run on this bug

• bug is open, matching expected state (open)
• bug target version (4.16.z) matches configured target version for branch (4.16.z)
• bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)
• release note type set to "Release Note Not Required"
• dependent bug Jira Issue OCPBUGS-86714 is in the state Verified, which is one of the valid states (VERIFIED, RELEASE PENDING, CLOSED (ERRATA), CLOSED (CURRENT RELEASE), CLOSED (DONE), CLOSED (DONE-ERRATA))
• dependent Jira Issue OCPBUGS-86714 targets the "4.17.z" version, which is one of the valid target versions: 4.17.0, 4.17.z
• bug has dependents

No GitHub users were found matching the public email listed for the QA contact in Jira (uyendava@redhat.com), skipping review request.

Details

In response to this:

/jira refresh

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 openshift-eng/jira-lifecycle-plugin repository.

[MrSanketkumar]

/unhold

[openshift-ci-robot]

@MrSanketkumar: Jira Issue Verification Checks: Jira Issue OCPBUGS-86713
✔️ This pull request was pre-merge verified.
✔️ All associated pull requests have merged.
✔️ All associated, merged pull requests were pre-merge verified.

Jira Issue OCPBUGS-86713 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓

Details

In response to this:

Router strips X-SSL headers from HTTP listeners. In some cases a Load Balancer may be doing TLS termination and sending traffic to router with these headers. While this topology is not supported, there is a need for a knob to allow these users to rollback this validation assuming the risks of allowing the router to accept the X-SSL headers on the HTTP listener

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 openshift-eng/jira-lifecycle-plugin repository.

[openshift-merge-robot]

Fix included in release 4.16.0-0.nightly-2026-07-09-201356