Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-7920

[Samsung Core/KDDI] Support for the automatic renewal of loopback certificates used by apiserver pods

XMLWordPrintable

    • None
    • Product / Portfolio Work
    • None
    • False
    • Hide

      None

      Show
      None
    • None
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      1. Proposed title of this feature request

      Automatic renewal of loopback certificates used by apiserver pods in openshift-oauth-apiserver and openshift-apiserver namespaces without requiring pod restarts. 

      2. What is the nature and description of the request?

      The customer is requesting a feature that enables automatic renewal of loopback certificates used by the apiserver pods in the openshift-oauth-apiserver and openshift-apiserver namespaces, without requiring manual pod restarts.

      Currently, the apiserver pods in these namespaces continue running with loopback certificates that are valid for one year (as per OpenShift 4.12). When these certificates expire, critical operations such as oc login fail, resulting in operational disruptions. The only known workaround is to manually restart the apiserver pods prior to certificate expiration to trigger regeneration of the loopback certificates.

      The requested enhancement is to ensure that loopback certificates are automatically rotated and reloaded within the running pods, similar to other certificate management mechanisms in OpenShift.

      This RFE is related to the case(https://access.redhat.com/support/cases/#/case/03989408

      3. Why does the customer need this? (List the business requirements here)

      KDDI, a major telecom customer of Samsung, operates OpenShift environments where the openshift-apiserver and openshift-oauth-apiserver pods have been running continuously for over a year. Due to the use of loopback certificates with a 1-year validity, there is a risk that these certificates will expire, which would prevent administrative actions such as oc login, potentially resulting in significant service outages.

      The customer requires a solution that ensures continuous and reliable access to the cluster without the need for manual intervention. This feature would help minimize operational risks, improve cluster availability, and align with telecom-grade reliability expectations.

      4. List any affected packages or components.

      • openshift-apiserver
      • openshift-oauth-apiserver
      • Loopback certificates issued and used by these components
      • Certificate rotation and renewal mechanism in OpenShift control plane

       

              racedoro@redhat.com Ramon Acedo
              bylee@redhat.com ByoungHee Lee
              None
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                None
                None