-
Epic
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
Stop generating self-signed certificates
-
To Do
-
None
-
False
-
-
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)
- As cluster admin, I can rotate TLS key + certificate used by storage operators using the same procedure as other certificates.
- 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"