Chapter 8. Configuring certificates

Procedure

1. Create a ConfigMap that includes only the root CA certificate used to sign the wildcard certificate:

   $ oc create configmap custom-ca \
        --from-file=ca-bundle.crt=</path/to/example-ca.crt> \1
        -n openshift-config

   1

   </path/to/example-ca.crt> is the path to the root CA certificate file on your local file system.

2. Update the cluster-wide proxy configuration with the newly created ConfigMap:

   $ oc patch proxy/cluster \
        --type=merge \
        --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'

3. Create a secret that contains the wildcard certificate chain and key:

   $ oc create secret tls <secret> \1
        --cert=</path/to/cert.crt> \2
        --key=</path/to/cert.key> \3
        -n openshift-ingress

   1

   <secret> is the name of the secret that will contain the certificate chain and private key.

   2

   </path/to/cert.crt> is the path to the certificate chain on your local file system.

   3

   </path/to/cert.key> is the path to the private key associated with this certificate.

4. Update the Ingress Controller configuration with the newly created secret:

   $ oc patch ingresscontroller.operator default \
        --type=merge -p \
        '{"spec":{"defaultCertificate": {"name": "<secret>"}}}' \1
        -n openshift-ingress-operator

   1

   Replace <secret> with the name used for the secret in the previous step.

Procedure

1. Create a secret that contains the certificate chain and private key in the openshift-config namespace.

   $ oc create secret tls <secret> \1
        --cert=</path/to/cert.crt> \2
        --key=</path/to/cert.key> \3
        -n openshift-config

   1

   <secret> is the name of the secret that will contain the certificate chain and private key.

   2

   </path/to/cert.crt> is the path to the certificate chain on your local file system.

   3

   </path/to/cert.key> is the path to the private key associated with this certificate.

2. Update the API server to reference the created secret.

   $ oc patch apiserver cluster \
        --type=merge -p \
        '{"spec":{"servingCerts": {"namedCertificates":
        [{"names": ["<FQDN>"], 1
        "servingCertificate": {"name": "<secret>"}}]}}}' 2

   1

   Replace <FQDN> with the FQDN that the API server should provide the certificate for.

   2

   Replace <secret> with the name used for the secret in the previous step.

3. Examine the apiserver/cluster object and confirm the secret is now referenced.

   $ oc get apiserver cluster -o yaml
   ...
   spec:
     servingCerts:
       namedCertificates:
       - names:
         - <FQDN>
         servingCertificate:
           name: <secret>
   ...

Procedure

1. Annotate the service with service.beta.openshift.io/serving-cert-secret-name.

   $ oc annotate service <service-name> \1
        service.beta.openshift.io/serving-cert-secret-name=<secret-name> 2

   1

   Replace <service-name> with the name of the service to secure.

   2

   <secret-name> will be the name of the generated secret containing the certificate and key pair. For convenience, it is recommended that this be the same as <service-name>.

   For instance, use the following command to annotate the service foo:

   $ oc annotate service foo service.beta.openshift.io/serving-cert-secret-name=foo

2. Examine the service to confirm the annotations are present.

   $ oc describe service <service-name>
   ...
   Annotations:              service.beta.openshift.io/serving-cert-secret-name: <service-name>
                             service.beta.openshift.io/serving-cert-signed-by: openshift-service-serving-signer@1556850837
   ...

3. After the cluster generates a secret for your service, your PodSpec can mount it, and the Pod will run after it becomes available.

Procedure

1. Annotate the ConfigMap with service.beta.openshift.io/inject-cabundle=true.

   $ oc annotate configmap <configmap-name> \1
        service.beta.openshift.io/inject-cabundle=true

   1

   Replace <configmap-name> with the name of the ConfigMap to annotate.

   Note

   Explicitly referencing the service-ca.crt key in a volumeMount will prevent a Pod from starting until the ConfigMap has been injected with the CA bundle.

   For instance, to annotate the ConfigMap foo the following command would be used:

   $ oc annotate configmap foo service.beta.openshift.io/inject-cabundle=true

2. View the ConfigMap to ensure the certificate has been generated. This appears as a service-ca.crt in the YAML output.

   $ oc get configmap <configmap-name> -o yaml
   apiVersion: v1
   data:
     service-ca.crt: |
       -----BEGIN CERTIFICATE-----
   ...

Procedure

1. Examine the service to determine the secret containing the certificate. This is found in the serving-cert-secret-name annotation, as seen below.

   $ oc describe service <service-name>
   ...
   service.beta.openshift.io/serving-cert-secret-name: <secret>
   ...

2. Delete the generated secret for the service. This process will automatically recreate the secret.

   $ oc delete secret <secret> 1

   1

   Replace <secret> with the name of the secret from the previous step.

3. Confirm that the certificate has been recreated by obtaining the new secret and examining the AGE.

   $ oc get secret <service-name>
   
   NAME              TYPE                DATA   AGE
   <service.name>    kubernetes.io/tls   2      1s

Procedure

1. View the expiration date of the current service CA certificate by using the following command.

   $ oc get secrets/signing-key -n openshift-service-ca \
        -o template='{{index .data "tls.crt"}}' \
        | base64 -d \
        | openssl x509 -noout -enddate

2. Manually rotate the service CA. This process generates a new service CA which will be used to sign the new service certificates.

   $ oc delete secret/signing-key -n openshift-service-ca

3. To apply the new certificates to all services, restart all the Pods in your cluster. This command ensures that all services use the updated certificates.

   $ for I in $(oc get ns -o jsonpath='{range .items[*]} {.metadata.name}{"\n"} {end}'); \
         do oc delete pods --all -n $I; \
         sleep 1; \
         done

   Warning

   This command will cause a service interruption, as it goes through and deletes every running pod in every namespace. These pods will automatically restart after they are deleted.