Troubleshooting
Problem
It is recommended to change the Gateway peering password alias for security reasons described in the Security Bulletin: IBM DataPower Gateway does not force a Gateway Peering password change
Clarification is needed about the best practices for changing this configuration for a running API Connect configuration.
Clarification is needed about the best practices for changing this configuration for a running API Connect configuration.
Symptom
On DataPower fix packs containing APAR IT41462, users might see a banner at the top of their DataPower UI which states a message like:
"The {gateway_peering_object) gateway peering instance in the {domain_name} domain is configured to use the system default for its password alias. This configuration is classified as a security vulnerability"
"The {gateway_peering_object) gateway peering instance in the {domain_name} domain is configured to use the system default for its password alias. This configuration is classified as a security vulnerability"
Cause
APAR IT41462: APIC GATEWAY PEERING USES DEFAULT PASSWORD (CVE-2022-31776) introduced a warning if the Gateway peering object is using the default password. The warning was created to address the issue reported in Security Bulletin: IBM DataPower Gateway does not force a Gateway Peering password change
Resolving The Problem
The password (alias) set in gateway peering configuration is used for the communication 1) among gateway peering nodes in the group and 2) between gateway peering clients and gateway peering servers.
Changing the password for an existing gateway peering group actually means to re-establish the peer group, which will unavoidably introduce some service down time. Thus, it's recommended to do this one-time change in production during a scheduled maintenance window.
Changing the password for an existing gateway peering group actually means to re-establish the peer group, which will unavoidably introduce some service down time. Thus, it's recommended to do this one-time change in production during a scheduled maintenance window.
The implementation of the solution varies depending on the form factor that DataPower is running on.
For DataPower running on Kubernetes, Openshift, and Cloud Pak for Integration:
For DataPower running on Kubernetes, Openshift, and Cloud Pak for Integration:
After upgrading to API Connect 10.0.5.5 or later, you can choose to secure the gateway-peering sessions by running the following command to delete the DataPowerService CR that was created by the GatewayCluster:
- Kubernetes:
kubectl delete dp <gateway_cluster_name>
- OpenShift:
oc delete dp <gateway_cluster_name>
This action prompts the API Connect Operator to recreate the DataPowerService CR with the unique, randomly generated password. This is a one-time change and does not need to be repeated for subsequent upgrades.
Note: This operation results in an API outage until the new GatewayCluster pods start up and are configured by API Connect. If you did not regenerate the CRs during the upgrade procedure, you can schedule this task for a planned downtime.
Linux, OVA, and Physical DataPower
If you would like to preserve the data stored in the gateway peering database after applying this change of password, it can be done by following the steps below:
Assume we have three gateway peering nodes in the group: gp-a (primary), gp-b (secondary), gp-c (secondary).
1. Enable the persistence feature of one of the secondary nodes, say gp-b, by setting the Persistence location in the gateway peering configuration (from memory) to local or raid.
2. Manually switch primary to the secondary node with persistence enabled, say gp-b. So now the new primary is gp-b and gp-a and gp-c are now the secondaries.
3. Set a valid Password alias and remove all entries in the Peers list (so that it can come up again as the primary more quickly without trying to reach out to other peers in the group) in the gateway peering configuration of the new primary gp-b and then apply the changes to restart the gateway peering process. Note that the service would be down after the password change is applied in this step.
4. One by one, set the same valid Password alias in the gateway peering configuration of the two secondaries (gp-a and gp-c) and apply the changes. Make sure the Peers list of gp-a and gp-c at least contains the IP of the new primary (gp-b).
If you would like to preserve the data stored in the gateway peering database after applying this change of password, it can be done by following the steps below:
Assume we have three gateway peering nodes in the group: gp-a (primary), gp-b (secondary), gp-c (secondary).
1. Enable the persistence feature of one of the secondary nodes, say gp-b, by setting the Persistence location in the gateway peering configuration (from memory) to local or raid.
2. Manually switch primary to the secondary node with persistence enabled, say gp-b. So now the new primary is gp-b and gp-a and gp-c are now the secondaries.
3. Set a valid Password alias and remove all entries in the Peers list (so that it can come up again as the primary more quickly without trying to reach out to other peers in the group) in the gateway peering configuration of the new primary gp-b and then apply the changes to restart the gateway peering process. Note that the service would be down after the password change is applied in this step.
4. One by one, set the same valid Password alias in the gateway peering configuration of the two secondaries (gp-a and gp-c) and apply the changes. Make sure the Peers list of gp-a and gp-c at least contains the IP of the new primary (gp-b).
The password alias objects should have identical configuration on each appliance.
5. Check the result of "show gateway-peering-status" to make sure the status of the new peer group with the new password is good. If the gateway peering status looks good, then service should be up and running again at this point of time.
6. Optionally, manually switch primary back to the original primary (gp-a) and disable the persistence feature of gp-b (now the secondary) by setting the Persistence location in the gateway peering configuration back to memory and add gp-a and gp-c back to the Peers list of gp-b.
You can then clean up the data that was created from the Gateway peering object. (For example if you had configured persistence location Local file with local directory local:// the data will be in local://gateway-peering/)
Related Information
Document Location
Worldwide
[{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSMNED","label":"IBM API Connect"},"ARM Category":[{"code":"a8m0z0000001it3AAA","label":"API Connect-\u003EManagement and Monitoring (MM)-\u003EGateway Service"}],"ARM Case Number":"TS015289848","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"10.0.5;and future releases"},{"Type":"MASTER","Line of Business":{"code":"LOB67","label":"IT Automation \u0026 App Modernization"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SS9H2Y","label":"IBM DataPower Gateway"},"ARM Category":[{"code":"a8m3p000000GoOyAAK","label":"DataPower-\u003EMGMT (MM)-\u003EGateway peering"}],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]
Was this topic helpful?
Document Information
Modified date:
09 April 2024
UID
ibm17137559