Preparing your warm-standby data center

Create the secrets, certificates, and issuers that are needed for your warm-standby data center to replicate with the active.

About this task

All operations are done on the CLI, in the 2dcdr-ws-yamls directory you created in Planning and initial preparation.

In the yaml files and commands that are shown here, replace <namespace> with the name of the corresponding subsystem namespace.

Procedure

  1. Import the ingress-ca issuer secret.
    This secret was created on your active data center here: Preparing your active data center
    1. If you did not do it as part of Preparing your active data center, copy the ca-issuer-secret.yaml file to your warm-standby data center.
    2. Create the secret with: 
      oc apply -f ca-issuer-secret.yaml -n <namespace>
    3. Verify that the secret was created with: 
      oc get secret -n <namespace>

NAME                            TYPE                                  DATA   AGE
ingress-ca                      kubernetes.io/tls                     3      19h
    4. If your Portal subsystem is in a different namespace in your warm-standby data center, then repeat the oc apply operation against the portal namespace.
  2. Create a file that is called warm-standby-certs.yaml and paste in: 
    #
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

---

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigning-issuer
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "selfsigning-issuer"
  }
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ingress-issuer
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "ingress-issuer"
  }
spec:
  ca:
    secretName: ingress-ca
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: portal-admin-client
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "portal-admin-client"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: portal-admin-client
  secretName: portal-admin-client
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  privateKey:
    rotationPolicy: Always
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "management"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "portal-admin-client"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gateway-client-client
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "gateway-client-client"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: gateway-client-client
  secretName: gateway-client-client
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  privateKey:
    rotationPolicy: Always
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "management"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "gateway-client-client"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: analytics-ingestion-client
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "analytics-ingestion-client"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: analytics-ingestion-client
  secretName: analytics-ingestion-client
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  privateKey:
    rotationPolicy: Always
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "management"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "analytics-ingestion-client"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gateway-service
  labels: {
    app.kubernetes.io/instance: "gatewaycluster",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "gateway-service"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: gateway-service
  secretName: gateway-service
  issuerRef:
    name: ingress-issuer
  usages:
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  privateKey:
    rotationPolicy: Always
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "gatewaycluster"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "gateway-service"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: gateway-peering
  labels: {
    app.kubernetes.io/instance: "gatewaycluster",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "gateway-peering"
  }
spec:
  subject:
    organizations:
    - cert-manager
  commonName: gateway-peering
  secretName: gateway-peering
  issuerRef:
    name: ingress-issuer
  usages:
  - "server auth"
  - "client auth"
  - "signing"
  - "key encipherment"
  duration: 17520h # 2 years
  renewBefore: 720h # 30 days
  privateKey:
    rotationPolicy: Always
  secretTemplate:
    labels:
      app.kubernetes.io/instance: "gatewaycluster"
      app.kubernetes.io/managed-by: "ibm-apiconnect"
      app.kubernetes.io/name: "gateway-peering"
  3. Apply this file by running against your Management subsystem namespace: 
    oc apply -f warm-standby-certs.yaml -n <namespace>
  4. Verify that the certificates, secrets, and issuers were created with: 
    oc get secrets -n <namespace>
NAME                         TYPE                                  DATA   AGE
analytics-ingestion-client   kubernetes.io/tls                     3      12s
gateway-client-client        kubernetes.io/tls                     3      21s
gateway-peering              kubernetes.io/tls                     3      11s
gateway-service              kubernetes.io/tls                     3      21s
ingress-ca                   kubernetes.io/tls                     3      18m
portal-admin-client          kubernetes.io/tls                     3      17s

oc get certificates -n <namespace>
NAME                         READY   SECRET                       AGE     EXPIRATION
analytics-ingestion-client   True    analytics-ingestion-client   2m18s   2024-09-04T12:27:38Z
gateway-client-client        True    gateway-client-client        2m19s   2024-09-04T12:27:28Z
gateway-peering              True    gateway-peering              2m17s   2024-09-04T12:27:39Z
gateway-service              True    gateway-service              2m18s   2024-09-04T12:27:28Z
portal-admin-client          True    portal-admin-client          2m19s   2024-09-04T12:27:33Z

oc get issuers -n <namespace>
NAME                 READY   AGE
ingress-issuer       True    18m
selfsigning-issuer   True    2m42s
  5. If your Portal subsystem is in a different namespace in your warm-standby data center, then to create your certificates, issuers, and secrets in the Portal subsystem namespace:
    1. Create a file that is called warm-standby-ptl-certs.yaml and paste in: 
      #
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
# 
#     http://www.apache.org/licenses/LICENSE-2.0
# 
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#

---

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigning-issuer
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "selfsigning-issuer"
  }
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: ingress-issuer
  labels: {
    app.kubernetes.io/instance: "management",
    app.kubernetes.io/managed-by: "ibm-apiconnect",
    app.kubernetes.io/name: "ingress-issuer"
  }
spec:
  ca:
    secretName: ingress-ca
    2. Apply this file to your Portal subsystem namespace: 
      oc apply -f warm-standby-certs.yaml -n <namespace>
    3. Verify that your issuers and secrets were created successfully: 
      oc get issuers -n <portal namespace>
NAME                 READY   AGE
ingress-issuer       True    43s
selfsigning-issuer   True    43s

oc get secrets -n <portal namespace>
NAME                       TYPE                                  DATA   AGE
ingress-ca                 kubernetes.io/tls                     3      4m18s
  6. Create the encryption key secrets for the Management and Portal subsystems, by using the random string generated on the active data center.
    Use the mgmt-enc-key.txt and ptl-enc-key.txt files that were copied to your warm-standby data center when you followed Preparing your active data center.
    1. Run the following command to create the management encryption key secret: 
      oc create secret generic mgmt-encryption-key --from-file=encryption_secret.bin=mgmt-enc-key.txt -n <management namespace>
    2. Confirm that the secret was created successfully by running: 
      oc get secrets -n <management namespace> | grep mgmt-encryption-key

mgmt-encryption-key        Opaque                                1      83s
    3. Run the following command to create the portal encryption key secret: 
      oc create secret generic ptl-encryption-key --from-file=encryption_secret=ptl-enc-key.txt -n <portal namespace>
    4. Confirm that the secret was created successfully by running: 
      oc get secrets -n <portal namespace> | grep ptl-encryption-key

ptl-encryption-key         Opaque                                1      15s
  7. Create the TLS client replication certificates for Management and Portal.
    1. Create a yaml file that is called mgmt-tls-client-cert.yaml and paste in the following contents: 
      apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: mgmt-replication-client
spec:
  commonName: mgmt-replication-client
  duration: 17520h0m0s
  issuerRef:
    kind: Issuer
    name: ingress-issuer
  renewBefore: 720h0m0s
  privateKey:
    rotationPolicy: Always
  secretName: mgmt-replication-client
    2. Apply this yaml file with: 
      oc apply -f mgmt-tls-client-cert.yaml -n <management namespace>
    3. Verify that the certificate was created with: 
      oc get certs -n <management namespace>

NAME                      READY   SECRET                    AGE     EXPIRATION
...
mgmt-replication-client   True    mgmt-replication-client   16m     2024-08-17T13:04:27Z
    4. Create a file ptl-tls-client-cert.yaml and paste in the following contents: 
      apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: ptl-replication-client
spec:
  commonName: ptl-replication-client
  duration: 17520h0m0s
  issuerRef:
    kind: Issuer
    name: ingress-issuer
  renewBefore: 720h0m0s
  privateKey:
    rotationPolicy: Always
  secretName: ptl-replication-client
    5. Apply this yaml file with: 
      oc apply -f ptl-tls-client-cert.yaml -n <portal namespace>
    6. Verify that the certificate was created with: 
      oc get certs -n <portal namespace>

NAME                     READY   SECRET                   AGE     EXPIRATION
...
ptl-replication-client   True    ptl-replication-client   16m     2024-08-17T13:04:27Z

What to do next

Install API Connect on your active data center Installing API Connect on the active data center.