This is a cache of https://docs.openshift.com/container-platform/4.1/authentication/certificates/service-serving-certificate.html. It is a snapshot of the page at 2024-11-21T02:21:27.303+0000.
Securing service traffic using service serving certificates - Configuring certificates | Authentication | OpenShift Container Platform 4.1
    Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history
×

Securing service traffic using service serving certificate secrets

Understanding service serving certificates

Service serving certificates are intended to support complex middleware applications that require encryption. These certificates are issued as TLS web server certificates.

The service-ca controller uses the x509.SHA256WithRSA signature algorithm to generate service certificates.

The generated certificate and key are in PEM format, stored in tls.crt and tls.key respectively, within a created secret. The certificate and key are automatically replaced when they get close to expiration. The service CA certificate, which signs the service certificates, is only valid for one year after OpenShift Container Platform is installed.

Add a service certificate

To secure communication to your service, generate a signed serving certificate and key pair into a secret in the same namespace as the service.

The generated certificate is only valid for the internal service DNS name <service.name>.<service.namespace>.svc, and are only valid for internal communications.
Prerequisites:

  • You must have a service defined.

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.

Add a service certificate to a configmap

A Pod can access the service CA certificate by mounting a configmap that is annotated with service.beta.openshift.io/inject-cabundle=true. Once annotated, the cluster automatically injects the service CA certificate into the service-ca.crt key on the configmap. Access to this CA certificate allows TLS clients to verify connections to services using service serving certificates.

After adding this annotation to a configmap all existing data in it is deleted. It is recommended to use a separate configmap to contain the service-ca.crt, instead of using the same configmap that stores your Pod’s configuration.
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.

    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-----
...

Manually rotate the generated service certificate

You can rotate the service certificate by deleting the associated secret. Deleting the secret results in a new one being automatically created, resulting in a new certificate.

Prerequisites

  • A secret containing the certificate and key pair must have been generated for the service.

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

Manually rotate the service CA certificate

The service CA is valid for one year after OpenShift Container Platform is installed. Follow these steps to manually refresh the service CA before the expiration date.

Prerequisites

  • You must be logged in as a cluster admin.

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

    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.