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

Service-Serving-Certificates for Headless Statefulset

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Normal Normal
    • openshift-4.8
    • None
    • API, Auth

      Goal
      Provide automatic certificate generation and rotation for direct pod-to-pod communication similar to the service-serving-certificates operator.

      Problem
      There are different types of applications or databases deployed in OCP. All the applications or Databases work in different way and each need different types of OCP service endpoint based on the needs to work as expected. A certificate is generated when an annotation service.beta.openshift.io/serving-cert-secret-name is set. The certificate generated doesn't contain all the DNS that are needed to be in Subject Alternative Names section for all types of application or databases.

      For eg: The Minio or Etcd StatefulSet needs a Headless service to communicate between the pods of the same StatefulSet. This will require the podname.servicename to be mentioned in the subjectAltNames of the certificate generated to allow that communication to happen. As the Databases or applications are expected to be scaled, we will need a wildcard to be supported for headless type service *.servicename.
      Also, there are some situations where we need more than one type of service to support for the same application/Database/StatefulSet.
      For eg. Etcd and Minio needs both headless type service to communicate between the pods and normal ClusterIP service to support incoming requests from a different application. In that case, the two different service names need to be included in the subject alternative names list within the same certificate.
      In some cases, we might need both ClusterIP service and NodePort type service for the same Deployment/StatefulSet type resource. We need a way to include both the service names(name of ClusterIP type service and name of NodePort type service) in the list of subject alternative names of the same certificate.

      Why is this important?
      The service itself requires direct, pod-to-pod communication for replication and availability purposes. These features are integral to the product design.

      Dependencies (internal and external)
      None

      Acceptance Criteria
      Story 1:

      Given a user deploys a database that runs as a StatefulSet type resource, also creates two service endpoint: one is ClusterIP type service(servicename1) and another is Headless type Service(servicename2).

      There should be a way to generate a certificate that is auto renewed and includes the following DNS names in the list of subject alternative names

      localhost
      127.0.0.1
      servicename1
      *.servicename2

      Story 2:

      Given a user deploys an application that runs as a Deployment type resource, also creates two service endpoints: one is ClusterIP type service(servicename1) and another is NodePort type service(servicename2)

      There should be a way to generate a certificate that is auto renewed and includes the following DNS names in the list of subjert alternative names

      localhost
      127.0.0.1
      servicename1
      servicename2

      Additional Notes
      We would like to be able to use the Service Serving Certificates feature, but this does not generate wildcard certificates, nor pod-specific certificates:
      https://docs.openshift.com/container-platform/4.3/authentication/certificates/service-serving-certificate.html

      There is an Issue open, that seems reasonable:
      https://github.com/openshift/service-ca-operator/issues/25

              anachand Anandnatraj Chandramohan (Inactive)
              karena_angell Karena Angell
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: