Changing the secret for Gateway peering

Update the secret that protects gateway-peering communications within a Gateway cluster in your API Connect deployment.

About this task

You can update the secret for an appliance-based gateway or a Kubernetes-based gateway. This task causes a disruption in API transactions because the secret must be changed on all gateways at the same time, and all gateways must be restarted.

Procedure

Appliance only: Manually update the Gateway Peering Identification Credential and Validation Credential objects.

Attention: If your Gateway is not deployed on an appliance, skip to step 2.

As soon as you begin this process, nodes will be out of sync. The nodes will remain out of sync until the entire process is complete. If the nodes do not recover from the out-of-sync condition, you might need to perform a DRR. For information about dynamic reregistration and reconfiguration and (DRR), see Dynamically re-registering and reconfiguring a Gateway service in a Kubernetes deployment.
Kubernetes only: If your Gateway is deployed on Kubernetes, update the secret by completing the following steps.
1. Determine the name of your Gateway cluster by running the following command:
```
kubectl -n namespace get gatewayCluster
```
  where namespace is the namespace where the Gateway subsystem is deployed.
2. Determine the name of the secret currently being used for gateway peering by running the following command:
```
kubectl -n namespace describe gatewayCluster gateway-cluster
```
  where:
  - namespace is the namespace where the Gateway subsystem is deployed.
  - gateway-cluster is the name that you obtained in step 2a.
  In the response, the name of the secret currently being used displays after the heading Apic Gateway Peering TLS as shown in the following example:
```
Spec:
  Admin User:
    Secret Name:                       datapower-admin-credentials
  API Debug Probe:                     true
  API Debug Probe Expiration Minutes:  60
  API Debug Probe Max Records:         1000
  Apic Gateway Peering TLS:
    Secret Name:  gateway-peering
```
3. Show the age of the secret currently being used by running the following command:
```
kubectl -n namespace get secret gateway-peering-secret
```
  where:
  - namespace is the namespace where the Gateway subsystem is deployed.
  - gateway-peering-secret is the secret name that you obtained in step 2b.
4. Delete the secret and then immediately delete all of the Gateway pods in the Gateway cluster by running the following two commands:
```
kubectl -n namespace delete secret gateway-peering-secret
kubectl -n namespace delete pod gw-pod1 gw-pod2 gw-pod3
```
  where:
  - namespace is the namespace where the Gateway subsystem is deployed.
  - gateway-peering-secret is the secret name that you obtained in step 2b.
  When you delete the secret and the pods, the following events occur automatically:
  1. The cert-manager recreates the secret.
  2. The DataPower operator recreates the gateway pods.
  3. Dynamic reconfiguration re-installs the API metadata onto the gateways.
    For information about dynamic reregistration and reconfiguration and (DRR), see Dynamically re-registering and reconfiguring a Gateway service in a Kubernetes deployment.
5. To verify the update, show the age of the new gateway peering secret by running the following command:
```
kubectl -n namespace get secret gateway-peering-secret
```
  where:
  - namespace is the namespace where the Gateway subsystem is deployed.
  - gateway-peering-secret is the secret name that you obtained in step 2b.
  Make sure that the secret is new and does not show the same age as previously.