Intranet VIP installed with ssp-ext.example.com
Article ID: 373761
Updated On:
Products
Issue/Introduction
Shared DataBase with our extranet VIP installed with ssp-ext.example.com.
Upgraded intra to 3.2 -> working ok;
Upgraded extranet to 3.2 all pods end up in crash loop-back with error:
{"timestamp":"2024-07-29T12:50:03.586524Z","type":"log","level":"fatal","thread":"main","msg":"Deployment's ssp.ingress.host property (SSP_SERVICE_PROVIDER_FQDN=ssp-ext.example.com) does not match the value stated in DB (ssp-int.example.net)."}
This DR feature broke the use case (1).
Introduced a new deployment parameter, "ssp.global.drSite=true" to be used when performing a DR deployment of Authentication Hub.
[...omitted for brevity...]
When connecting to an existing Authentication Hub deployment database, Authentication Hub validates that the "ssp.ingress.host" helm parameter value matches with the one saved in the Authentication Hub deployment database. Changing the "ssp.ingress.host" Helm parameter value must be done by passing the helm parameter,
"ssp.global.forceIngressHostOverride=true"
from a non-DR deployment (where "ssp.global.drSite=false")
Cause
The network setup is lacking the proper way to handle this by having 2 distinct ingress classes, therefore making it possible to use the same ingress host.
Please check with the network team to see if the ingress controllers have insufficient/legacy config preventing them from handling host config the right way to address this topology (2).
In the meantime, to counter the possibility such network adjustment might take ages, we addressed this in 3.2.1 by exposing a flag to skip validation of SSP-FQDN in order to meet some topology realities.
Skipping such validation opens up the possibility of routing-related issues in the future, so please have the discussion with the network team to address this going forward.
The flag will ensure SSP_FQDN check can function in the deployment that requires having 2 *separate* SSP deployments with one shared physical DB Helm parameter:
--set ssp.global.skipIngressHostValidation=true|false"(default is false)
controls the check for SSP_FQDN by the dataseed and mid-tier services.
Also, if the check is skipped, the overwrite (controlled by helm parameter "--set ssp.global.forceIngressHostOverride=true") will not take place.
Resolution
Upgrade VIP Authentication Hub to 3.2.1 once this one will be available to get access to the flag
--set ssp.global.skipIngressHostValidation=
Additional Information
Feedback
