Uploaded image for project: 'OpenShift Storage'
  1. OpenShift Storage
  2. STOR-2770

Stop generating self-signed certificates

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Undefined Undefined
    • None
    • None
    • Stop generating self-signed certificates
    • To Do
    • None
    • False
    • Hide

      None

      Show
      None
    • False
    • Not Selected
    • None
    • None
    • None

      Epic Goal

      Some of our library-go based operators generate their own self-signed TLS certificates for their metrics endpoint. We should use certificates generated by service-ca-operator.

       List of the operators:

      • aws-ebs-csi-driver-operator
      • azure-disk-csi-driver-operator
      • azure-file-csi-driver-operator
      • manila-csi-driver-operator
      • gcp-pd-csi-driver-operator
      • vmware-vsphere-csi-driver-operator
      • openstack-cinder-csi-driver-operator
      • all storage operators in HyperShift control plane

      Why is this important? (mandatory)

      service-ca-operator ensures the certificates have the same quality and lifetime as rest of the OCP. And they are rotated automatically, with the rest of OCP certificates.

      Details about the current self-signed certificates:

      • Lifetime of CA cert is 5 years.
      • Lifetime of TLS server cert + key is 2 years.
      • The're re-generated every time the operator pod restarts. E.g. during every z-stream update or node reboot.
      • They're used only in metrics server  exposed by corresponding operator.

      Scenarios (mandatory) 

      1. As cluster admin, I can rotate TLS key + certificate used by storage operators using the same procedure as other certificates.
      2. As a curious customer, I can audit all TLS keys + certificates used in a cluster (e.g. using this script).

       
      Dependencies (internal and external) (mandatory)

       

      Contributing Teams(and contacts) (mandatory) 

      • Development - 
      • QE - 

      Acceptance Criteria (optional)

      Provide some (testable) examples of how we will know if we have achieved the epic goal.  

      Drawbacks or Risk (optional)

      Reasons we should consider NOT doing this such as: limited audience for the feature, feature will be superseded by other work that is planned, resulting feature will introduce substantial administrative complexity or user confusion, etc.

      Done - Checklist (mandatory)

      The following points apply to all epics and are what the OpenShift team believes are the minimum set of criteria that epics should meet for us to consider them potentially shippable. We request that epic owners modify this list to reflect the work to be completed in order to produce something that is potentially shippable.

      • CI Testing -  Basic e2e automationTests are merged and completing successfully
      • Documentation - Content development is complete.
      • QE - Test scenarios are written and executed successfully.
      • Technical Enablement - Slides are complete (if requested by PLM)
      • Engineering Stories Merged
      • All associated work items with the Epic are closed
      • Epic status should be "Release Pending" 

              Unassigned Unassigned
              rhn-engineering-jsafrane Jan Safranek
              None
              None
              None
              None
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated: