This is a cache of https://docs.openshift.com/container-platform/4.12/security/certificate_types_descriptions/service-ca-certificates.html. It is a snapshot of the page at 2024-11-25T11:23:51.802+0000.
<strong>service</strong> CA certificates - Certificate types and descriptions | Security and compliance | OpenShift Container Platform 4.12
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history bug_report picture_as_pdf
×

service CA certificates

Purpose

service-ca is an Operator that creates a self-signed CA when an OpenShift Container Platform cluster is deployed.

Expiration

A custom expiration term is not supported. The self-signed CA is stored in a secret with qualified name service-ca/signing-key in fields tls.crt (certificate(s)), tls.key (private key), and ca-bundle.crt (CA bundle).

Other services can request a service serving certificate by annotating a service resource with service.beta.openshift.io/serving-cert-secret-name: <secret name>. In response, the Operator generates a new certificate, as tls.crt, and private key, as tls.key to the named secret. The certificate is valid for two years.

Other services can request that the CA bundle for the service CA be injected into API service or config map resources by annotating with service.beta.openshift.io/inject-cabundle: true to support validating certificates generated from the service CA. In response, the Operator writes its current CA bundle to the CABundle field of an API service or as service-ca.crt to a config map.

As of OpenShift Container Platform 4.3.5, automated rotation is supported and is backported to some 4.2.z and 4.3.z releases. For any release supporting automated rotation, the service CA is valid for 26 months and is automatically refreshed when there is less than 13 months validity left. If necessary, you can manually refresh the service CA.

The service CA expiration of 26 months is longer than the expected upgrade interval for a supported OpenShift Container Platform cluster, such that non-control plane consumers of service CA certificates will be refreshed after CA rotation and prior to the expiration of the pre-rotation CA.

A manually-rotated service CA does not maintain trust with the previous service CA. You might experience a temporary service disruption until the pods in the cluster are restarted, which ensures that pods are using service serving certificates issued by the new service CA.

Applications using the service-ca certificate must be capable of dynamically reloading CA certificates. Otherwise, when automated rotation occurs, the application pods might require a restart in order to rebuild certificate trust.

Management

These certificates are managed by the system and not the user.

services

services that use service CA certificates include:

  • cluster-autoscaler-operator

  • cluster-monitoring-operator

  • cluster-authentication-operator

  • cluster-image-registry-operator

  • cluster-ingress-operator

  • cluster-kube-apiserver-operator

  • cluster-kube-controller-manager-operator

  • cluster-kube-scheduler-operator

  • cluster-networking-operator

  • cluster-openshift-apiserver-operator

  • cluster-openshift-controller-manager-operator

  • cluster-samples-operator

  • machine-config-operator

  • console-operator

  • insights-operator

  • machine-api-operator

  • operator-lifecycle-manager

This is not a comprehensive list.

Additional resources